In early November, we experienced an influx of Microsoft Word documents that contained malicious macros. Just when the computer security industry was on the verge of forgetting these oldies, they rose to life once again, proving that they’re not allowing themselves to be eliminated that easily.
In June, Ruhai Zhang warned of macro threats that continue to spread, particularly those that use Microsoft Excel. In this blog post, I will go over a family of Microsoft Word macros, detected as WM/Agent!tr, that I have encountered in the past couple of months. Here we will see how simple they are in nature while they strive hard to disguise their destructive parts.
Prior to addressing the purpose of the malware, we will see how the malware author attempts to conceal the malicious commands. Mainly, the code is lost in a pile of junk strings and useless, confusing commands. Also, in all versions of this family of macros, some type of encryption is used to make the reverse engineering as tedious as possible.
As with using junk APIs in executables as an anti-debugging method, we see numerous lines of junk commands in these scripts. These lines are repeated abundantly in order to suggest to the analyst that the code is complicated and possibly discourage the investigation.
Here are some examples of these tricks:
• Opaque predicates and codes to open files and show message boxes which are always jumped over and never get executed (Figure 1)
• Empty loops (Figure 2)
Repetitive jumps (Figure 3)
• Encrypted strings
Code obfuscation is prominent in this context. In many cases among the samples that I have seen, not only the critical strings are distorted but even the garbage strings are also encrypted.
Encryption routines range from a trivial use of Chr() and ChrW() (Figure 4) to a character conversion chain (Figure 5), to a more complex routine such as a custom encryption function using a decryption key and mathematical calculations (Figures 6 and 7).
After having analyzed a handful of these scripts, the analyst would know the exact key words to look for among the bulk of nonsense strings, functions, and commands, in order to whittle it down to the core functions.
The macros that I have looked at are written in Visual Basic for Applications (VBA) and take advantage of some services of the Microsoft XML parser, MSXML version 2.0.
They start with an Auto_Open() procedure, which runs automatically each time an Excel workbook or Word document is opened. The main function, MainSub, is called from inside Auto_Open().
The macros also contain the Microsoft Office event handlers AutoOpen() and Workbook_Open(), which run every time a Word document or an Excel workbook is opened, respectively. We observe the presence of both event handlers in this script since the code is applicable on both Word and Excel. Also, implementing all three macros Auto_Open(), AutoOpen(), and Workbook_Open() in one document minimizes the risk failure of the VBA execution.
In the MainSub function, the encrypted strings are passed to the decryption functions and the outcome is subsequently handed to the main malicious function which implements the payload.
The figure below shows the main structure of these macros.
In the Payload function, we can see that these VBA macros are in fact downloaders. An XMLHTTP object is first instantiated which would enable accessing of data over HTTP. Afterwards, an HTTP request is prepared by calling the Open() method which is used with the three parameters: the GET request, the URL (previously decrypted), and the Boolean false, setting a synchronous request. The Send() method naturally comes right after that to send the request. Since the request is synchronous, the script will then freeze until a response is received.
A Do While loop iterates until the readyState property of the object equals 4, ensuring the GET request is completed before any more action is taken.
If the intended URL is reached and the file is loaded successfully, the content is saved in a variable and then copied to a previously created file under the user's Temporary folder. At this point, an executable file is supposedly loaded and saved into the infected user’s Temporary folder, and the file gets executed by the Shell() command.
The typical contents of the Payload function is shown below.
The following are examples of some of the URLs that we have seen after decryption:
These links are all currently blacklisted by Fortinet.
After retrieving some of these downloaded files, we are not surprised to see that they are variants of the banking trojan Dridex. Dridex, which we first encountered in October, 2014, has been using Microsoft Office macros as a means to spread in the past few months. The Dridex binary files can simply be attached to an email or, in this case, be downloaded and executed by running macros on Microsoft Office applications.
The following are some simple steps that users can do in order to avoid such infections.
• It is strongly suggested not to open unknown attachments. Make sure that users first confirm that the email from the sender is genuine and that the specific attachment is as expected.
• Macros are disabled by default on MS Office 2007 and newer versions. Only enable macros if you are sure that the source of the file is legitimate.
• Do not fall into social engineering traps. Malware authors try to trick the user into enabling macros so that their mission gets accomplished and the user’s system gets infected. Below are examples of some of these social engineering tricks:
As seen in the three figures above, the malware author even instructs the user on how to enable the macros.
• Last, but not least, make sure that your antivirus software is updated and your systems are patched.