Press "Enter" to skip to content

Playing with malicious Office macros

In this post we will see how using several simple tricks it is possible to create a malicious macro undetectable by most conventional antivirus. At the end of this post you may find how to prevent these attacks using AV Access protection rules.

IMPORTANT: This post is for educational purposes only

Let’s create a simple macro that is executed automatically when you open a Word document (using the “Autopen()” subroutine). So, we open a Word document go to “View” tab and select “Macros”. Select View macros and Create a new one:

We will add the following code to the function AutoOpen():

This simple subroutine will download a Windows PE binary version for the well known tool “Netcat” ncat.exe (you can find this tool on this link) and will use that binary to open a reverse shell against server which is listening on port 8888.

NOTE: In this demo I used my own server for educational purposes. Binary resources are no longer available on that location

We will save the document as macro enabled Word document. After that, if we try to open the document we will see that Windows Defender is blocking the macro because the downloaded “ncat.exe” is being detected as hacking tool. I recorded the detection on the following video:

This is what we will see in the alert:

Now we need to avoid that the downloaded binary is detected by the antivirus. There are several techniques from saving the file into some commonly AV excluded folder to modifying the binary.

In this case, it seems Windows Defender has already an AV signature for this binary because the name of the threat is quite accurate, so it is probably matching the hash of the file. The only thing we need will be to modify the binary so that it generates a different hash.

We can use IDA Pro software for example to decompile the binary and patch some bytes, in that way we will be able to modify the hash. You have to be careful when choosing the bytes to modify. One technique is usually to modify the binary strings because they are irrelevant to the execution of the binary.

Before modifying the binary, we can take a look to its current hash. We can use Windows native tool FCIV:

Let’s open the binary with IDA Pro, go to the Strings tab and search for all strings containing “ncat” in order to alter those bytes and this way avoid any reference to Ncat tool on the strings:

Double click on the String and it will take us to the memory address where it begins. We can then expand the string into single bytes for each character:

Let’s change for example the byte corresponding to the character “n:

Now the byte has changed and the character is now a “m”:

We can do the previous steps for all String containing “Ncat” word and after that we have to apply the byte patching to the original binary:

Now, if we take a look to the hash, we can see that the hash has actually been modified.

So now, the patched binary is no longer detected by Windows Defender as we will see in the following video.

We proceed to upload the patched binary to the same location on our server and start listening on port 8888 and finally we open again the Word document. This time, there is not any AV detection and the reverse shell is established. Now the attacker is able to execute commands on our computer from the remote server:

We can see that Windows Defender doesn’t detect the binary as malicious and now macro is executed properly. A reverse shell is opened against the remote server and the attacker can list directories as well as prompt a message on victim’s machine.

Now, we can go one step further and obfuscate the malicious code of our macro. There are hundreds of obfuscation tools, in this case I used this Python tool:

Let’s execute the following command:

The obfuscated code will be saved on the output.txt and as we can see, the code of the macro is completely unreadable:

How to prevent these attacks?

To prevent this kind of threats we can use custom access protection rules that most enterprise endpoint AV solutions include. We will need to create custom rules to avoid that Word, Excel, Adobe, Outlool, etc processes execute scripts like .bat, .vb, .exe, etc.

Here are some examples of custom access protection rules:

Symantec ->

McAfee ->


I hope this post is useful to you.


Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.