Macro malware, introduced back in the 90’s, which lives inside Microsoft Office documents, is currently making a somewhat unexpected, but nonetheless frighteningly, successful comeback.
The idea of infecting Internet users through documents is effective and incredibly simple, because all that is needed from a victim user - unfortunately one of the weaker links in enterprise security - is a simple click on a button. Infecting a user via macros in Microsoft Office documents is often combined with social engineering attacks (such as well-crafted emails), convincing the user to enable macro execution (if it’s not already enabled).
Additionally, writing VBA code is easy, and many templates are available for an attacker to start from. Last but not least, the crooks don’t even need to spend any money on obtaining expensive 0-day exploits for spreading their “work”.
The simplicity of this attack comes at a price, however: macro code is typically accessible as plain-text and is easy to identify if no care is taken by the attacker. Thus, with the increasing popularity of macros, malware authors have to find ways to raise the bar for security solutions to understand and detect this malicious macro code. Unfortunately, the range of possible evasion techniques is huge - just to name a few examples:
- Do not execute any malicious functionality upon file-opening (an activity that is triggered by practically every analysis system); instead, execute macros only upon closing of the malicious document.
- Heavily obfuscate macro code and include random, often unused functionality to get around static analysis scanners.
- Use password protection on the code project to prevent analysis systems from looking at the original macro code.
- Use exotic file types/formats such as wsf, dotm, mht that may not have received as much attention from security systems as other well-known formats have.
- Split malicious functionality over multiple components to bypass dynamic anti-malware systems.
In a series of articles, we will shed some light on several recent waves of attacks that make use of the above mechanisms. We have seen malware using these evasion mechanisms and install a wide range of payloads ranging from ransomware (Locky, TeslaCrypt, or Nymaim) to Trojan-Bankers (Dridex), all with the goal of financial gains.
For each mechanism, we will show different tricks used by the attackers, to help the security community understand, and in turn, see through these evasions and enable them to protect users from these attacks. Furthermore, we will provide examples how the Lastline analysis sandbox is able to trigger the behavior and correctly classify the attacks launched by the malicious macro code.
Evasion Techniques: Part 1
In this first post of the series, we focus on evasion techniques that have been seen in binary programs for a while, and we show how they found their way into VBA downloaders. In two follow-up posts, we will dive into how these recent VBA downloaders interact with the system to identify if they are running on a real host that is worth attacking.
Stalling code has long become a well-known evasion technique against dynamic analysis systems in binary programs - and we’re now seeing it also as part of VBA code. The idea is simple: stalling code is executed before any malicious behavior to delay any signs of badness long enough for an analysis system to terminate early, without seeing behavior used to correctly classify a program or file.
This stalling code is usually meaningless to the functionality of the code, such as futile loops, long arithmetical operations, or calls to sleep functions:
Stalling VBA code using futile loops and long arithmetical operations
The analysis overview of the report generated by the Lastline analysis system shows that the system detects and bypasses this stalling code of the VBA-downloader:
Dealing with simple calls to sleep functions is handled successfully by most systems today. However, we also start to see more clever implementation variants of stalling code in macros that are not as straightforward, as we can see in the following examples.
Slow loops: The first example consists of a small loop iterating millions of times to perform a simple arithmetic operation. Since executing VBA code has a non-negligible overhead (when compared to natively executing code), this code can take a significant amount of time, delaying any subsequent malicious behavior just as in the example above:
Note that the outcome of the data computed in the loop is not important for the application to work correctly.
Fast sleeps: The second example also makes use of calls to a sleep function, but differently from the previous basic example, it does so in a loop and using very small amounts of time (milliseconds) to sleep. This can be used to bypass sandboxes that patch long sleep calls with shorter ones (to reduce the impact of these sleeps).
WMI-based System Fingerprinting
By providing access to the Windows Management Instrumentation (WMI), Microsoft offers a very powerful and incredibly easy-to-use interface to find information about the execution environment. VBA code can fingerprint the system with only a few lines of code, for example:
Instances of ("Win32_ComputerSystem")
ExecQuery("Select * from Win32_Process")
Over recent months, we have observed a steep increase in the use of WMI in malicious document files. For example, some variants check for the presence of analysis tools or for virtual machines and refuse to work in such environments.
The VBA snippet shown above, for instance, queries for programs running on the system. Using this information, the evasive code can search for running programs whose names contain strings of analysis tools (such as “Fiddler" or “Wireshark”) or components of virtual machines (such as "KVM", "QEMU", "VIRTUAL", "VMWARE" or "XEN"):
Checking the presence of the analysis tools
Note that these strings are seldomly stored in plain text inside the VBA code to avoid raising suspicion. Instead, they are decrypted as part of the code execution.
Clearly, the use of virtual environments is one of the most essential components of most analysis systems today. As a result, it has become imperative that these systems can either tamper with the outcome of such WMI calls or successfully hide the VM from the code under analysis. The Lastline solution uses a combination of both approaches: using a full-system emulator (FUSE), the analysis system has a powerful arsenal of tricks to avoid being detected. As a result, the Lastline analysis report shows how these evasion mechanisms are bypassed and that the final payload is executed, making correct classification possible ck:
Divide And Conquer: Distributing Malicious Functionality Over Multiple Components
Quite often, the malicious functionality of VBA downloaders is distributed into several components to make the analysis more complicated. For example, in one variant that we analyzed, the sample (consisting of more than 4000 highly obfuscated lines of VBA code) first dynamically generates a (rather long) batch command that is then invoked via CMD.EXE. This command, in turn, spawns a VBS file, which is responsible for downloading and running the payload:
Step 1: Building and spawning a command line using CMD.EXE
Step 2: Building and spawning a VBS script from Batch
Step 3: VBS downloader script
As shown in the figures above, each individual step is highly obfuscated to give an analysis system as little surface as possible for making a detection - making it imperative to fully execute the entire chain of events.
Another interesting variant we want to highlight here spawns a powershell instance for downloading and running a payload:
In this first post in a series on Comeback of VBA Downloaders, we show how evasion techniques that are well-known for binary programs have found their way into VBA. By combining these evasive tricks with code obfuscation, malware authors are provided with a simple, but powerful attack tool.
Using stalling code, system fingerprinting, and multi-step execution, these VBA samples are incredibly tricky to detect using standard analysis techniques. The Lastline analysis engine detects these threats and blocks them successfully, and our analysis environment stays undetected by these malware samples.
Read Part 2 here