hamburger

BitDam Blog

Macro Obfuscation in Office Files
Alex Livshiz
Alex Livshiz
5 minutes & 33 seconds read · July 8, 2019

Macro Obfuscation in Office Files

In the world of cyber-security, some patterns never change. However, that doesn’t mean that they’re easy to detect. One of them is code obfuscation.

The typical reasons attackers use code obfuscation include:

  1. Evasion techniques – hiding their code from static analysis solutions
  2. Making their code harder to reverse engineer

At BitDam, we have encountered various types of obfuscated code, ranging from obfuscated strings in a malicious DLL dropped to the machine, all the way to obfuscated JavaScript in a pdf file. In this blog post, I’m going to focus on obfuscated macros in Office files.

Why Office Macros?

To understand why this is one of the most interesting issues, in my opinion, I’ll have to take you back to BitDam’s approach towards detecting malicious files. Generally speaking, there are three steps that take place in the process of malicious file exploitation:

    1. Identifying a vulnerability
    2. Exploiting that vulnerability
    3. Running the malicious code

Today, most security solutions focus on detecting the malicious code / Advanced Persistent Threat (APT). Why is that? Because it’s relatively easy to create static and dynamic signatures that would catch known APTs.

Why isn’t that good enough? Because this method works well for known APTs, but it is useless against zero-day exploits and unknown APTs.

How does BitDam do things differently? Unlike many other solutions, BitDam focuses on the most interesting phase – the exploitation – that leads to code execution.

Now that we have this in mind, we can move on to “why are Office macro interesting?”

Many Office macro attacks do not include the vulnerability and exploitation phases and start straight out running the malicious code. This way, attackers can do pretty much whatever they want. For example, an attacker can simply drop an EXE file to the %TEMP% folder and execute it. This in turn causes current cyber solutions to focus on static analysis to detect malicious macros. To deal with that, attackers obfuscate their macros and make them harder to find using a static scan.

They Get More and More Sophisticated

Macros were first introduced way before the concept of cyber-security existed, and were mainly used for running functions on Excel sheets. That changed when attackers started exploiting macros to their own advantage. According to the Microsoft Defender ATP Research Team, 98% of the Office-targeted threats in 2016 used macros, which is a crazy number! And to be honest, I don’t see a reason for this number to decrease.

The reason hackers to use this attack vector is that it allows them to do whatever they want in a scope of a macro. They can achieve code execution and persistency on the attacked machine, by using macro features such as:

  • Writing to the file system
  • Writing to the registry
  • Using Windows Management Instrumentation (WMI)

Some of today’s macro attacks are also known as fileless attacks – attacks that do not require the installation of a malicious program or writing a file to the file system. Instead, they inject their code into other processes so that the malware exists only in memory.

Obviously, Microsoft had to deal with this attack vector. As with every problematic feature the easiest solution is to disable it by default. Today, Office integrates mitigations to prevent macros from running by default. For example:


This may help in some cases, but attackers use social engineering to trick the user to approve the macro (which actually works):


In other cases, organizations with older Office versions are more in danger of being attacked by such files.

Diving into Macro Obfuscation

Let’s start with a basic example, which is also a very popular one. An attacker can simply create a WScript.Shell object and execute a powershell / cmd script. This can be used to fetch a payload from a remote server and execute it.

Have look at the following macro:

Sub Document_Open()
FileName = Environ("temp") & "\malicious.exe"
fileNo = FreeFile 'Get first free file number
textData = "My malicious content"
Open FileName For Output As #fileNo
Write #fileNo, textData
Close #fileNo
Set WshShell = CreateObject("WScript.Shell")
Set WshShellExec = WshShell.Exec(FileName)
End Sub

This code basically creates an EXE file and runs it. Note that the EXE can’t actually run, since its content is a simple text string. And yet, by uploading a .docx file that contains this macro to VirusTotalhalf of the vendors marked it as malicious.


If I were an attacker, I would not be happy, as that is a very miserable result. I definitely don’t want my malware to be detected by 50% of the end points. Luckily for attackers, there are ways to bypass security solutions and get under their radar. Not surprisingly, this drives attackers to become very creative with their string obfuscations.

Let’s explore another example, this time it’s something that we’ve recently seen in the wild (SHA-256 f5c51cff409b074e9aeb97d999a3e78bbd99a3b3b8ee3821018a4759670e845a). It demonstrates how sneaky attackers can be. Here’s how the file works:

First, there’s a creation of a powershell command. You can see the letters of the “powershell” marked in red.


Then, the macro runs the command line generated using WMI. It uses the winmgmts object to create a process, and does it differently from my sample earlier:


This obfuscated macro got a much lower VirusTotal score:


Obfuscation Detection: Why, Challenges and How

Now that we understand why attackers use obfuscation, and we have seen a real-life example, it’s pretty clear why BitDam, as a cyber-security vendor, would like to automatically detect obfuscated macros:

  • For our customers – by labeling obfuscated macros, we provide our users (SOC teams) with data that would help them further investigate malware blocked by BitDam
  • Internally for product enhancements – our detection engine utilizes this data as part of its file scoring mechanism.

While obfuscated code is quite simple to identify with the human eye (any developer or researcher who sees the code can immediately tell that it’s obfuscated), it isn’t that straightforward for machines to detect. Looking for suspicious keywords in a macro is not an option. As you can see in the example above, even detecting the keyword “powershell” is not simple. And let’s not forget that attackers get more and more creative as time goes on.

To overcome this, and automatically determine if a macro is obfuscated or not, we at BitDam came up with a unique technique, that uses dynamic scanning (and a bit of static) of the file. This helps our customers’ SOC teams investigate such attacks, and it helps our solution to detect sneaky attacks.

Want to check if we detect your obfuscated macro? Scan it now for free and let us know the result.