Macro Malware: When Old Tricks Still Work, Part 2

In the first part of this series, we discussed about the macro malware we have recently seen in the threat landscape. This second entry will delve deeper into the techniques or routines of macro malware.

Unintended consequences

Let us put things into perspective – by itself, macros are not harmful to the user. Its intended function is to automate frequently used tasks. The problem lies when cybercriminals abuse the functionalities of macro code to execute malicious routines. Microsoft offers macro protection within the Microsoft Office suite, but only to some degree. It will inform the user if a macro exists within the Microsoft office file the user is about to open, but it will not detect if the embedded macro is malicious or not. It isn’t supposed to magically protect the user, but rather make them consciously enable or disable the feature that can be potentially harmful.

That said, we’ll consider the following scenarios of macro files coming into play in a workplace. The first scenario is an environment with end-users who have developed the skill to write small macros to help them with their daily routine. We can assume that the user who receives a document with macro code would breeze through the prompt and enable the feature or even have the setting Enable all macros on– as it is common within that environment to exchange files with macros.

The second scenario, which may be more common, involves end-users who have not heard of macros within the Microsoft Office suite. Unaware of the possible risks, and curious to open the file, these users may ignore the security warning and enable macros to view the document. After all, the file may contain items of interest since there were a lot of things to do before opening the file, and maybe the context of the email that came with had an intriguing message.

Now, in comparison to malicious code that relies on exploits to deliver the final payload, these kinds of malware threats involve a lot of user interaction:

Someone has to open the email and read it.
The reader determines that the content was indeed something the reader can associate with.
Finally, the reader opens the attachment and follows the necessary steps to enable the originally disabled macro feature in Microsoft Word.

This may all sound a little bit too tedious to get one’s computer infected but it’s not far from the truth. We must come to terms with the fact that, while this is an old technique, the fact that most users today are not aware of this type of threat makes it effective. The most activity we’ve had in the past in relation to macro threats was probably the early 2000’s and this sets us back some 14 years ago. The cautious and wary behavior older computer users have with the experience of living in the era of mass-mailers is something that the current generation had no chance to acquire… except, perhaps, currently.

The whole is greater than the sum of the parts

Let’s look at a few examples of what happens in an endpoint that allows macros to run when a malicious Microsoft Word document is opened:

Figure 1. Deep Discovery Analyzer log file of W2KM_DLOADR.WYG downloading TSPY_DRIDEX.WW

The unassuming characteristics of these events may not even stand out if Microsoft Word documents are enabled to enter from the Internet gateway and reach a person’s mailbox, as what all we can see is a download event from one machine. But if we take in the whole picture:

Email comes in with the correct email address domain, with a leading email subject and a believable message content, duping the user into opening the Microsoft Office document.
Upon opening the attachment, the end-user is presented with clear instructions on how to enable the disabled feature, if it has not been done so yet. Instructions are clear, with so many online references.
Nothing seems to happen, and the end-user knows something is wrong and immediately deletes the email.
But this is all too late since the desired malicious activity has already introduced persistence into the system – a resident binary file that monitors your banking activity.

We can see that there’s a lot more going on than just downloading and opening a file. This next BARTALEX example is equally interesting.

Figure 3. W2KM_BARTALEX.SM execution

While this is considerably a long list of activities resulting from just executing a Microsoft Word document, a breakdown of the characteristics gives a different meaning:

Task automation functionality that is commonplace: batch files (.bat), visual basic script (.vbs), PowerShell script (.ps1) and, of course, the visual basic for applications (VBA) macro that started the execution
Built-in command-line utilities to invoke seeming separate events: cmd.exe, ping.exe, and chcp.com
Executing a binary file
an HTTP connection that doesn’t stand out

This breakdown allows us to see what makes the Microsoft Word file malicious in the first place: the misuse of otherwise legitimate components. Similar with targeted attacks, your desktop probably has built-in functionalities an attacker can exploit to make the attack whole.

In summary

While the era of macro malware may seem to be coming back, we can’t really say that history is repeating itself since the underlying functionality as to how macro malware worked before pales in comparison to how they’re done today. Rather, it may be that we just stopped paying close attention to it, and the effect of that has finally caught up with us. Addressing macro malware in enterprise environments requires several measures, summarized into three simple items:

Re-check your security policies. Email security policies could have been in place already, and it’s probably a good time to revisit them – or it may be high time to create one if such does not exist. For example, if it’s common within your company to exchange Microsoft Word files that contain macros via email, then identify if such is required from an external party. That way, you can decide how your company would filter email. A policy would allow such content if the email just travels within your company’s messaging infrastructure, but similar content would be blocked from external sources. Of course, there exists the gray area of wanting documents enabled within the enterprise and received from the Internet. If this predicament applies to your environment, consider having Microsoft Office files go through sandbox execution to determine if these files have malicious intent.
Decrease your surface area of attack. Computing devices of today are much more powerful and technologically advanced compared to those in the early 2000’s.While technological advances are generally intended for good use, the misuse of the same can almost be counted on. Being up to date and abreast with all of these changes may be daunting, but a lot of them are well documented:
- For example, if there is simply no use for PowerShell in your environment, then you may want to consider blocking its execution through the use of Software Restriction Policies or App Locker. If there is no reason for your users to run Windows Scripting Host, then this may optionally be disabled as well.
- One other thing to consider, like in the case of W2KM_DLOADR, is the fact that Internet access is required. It’s time to assess if the endpoint really has to go online, or if it only needs to connect to the company resources and access the company intranet.
Educate your users. Don’t you ever wonder why incidents seldom occur from within your IT staff? That’s because they’re the most knowledgeable about it. That being said, end-user education plays a big role in ensuring that everyone who deals with these types of content is aware of the risks. Remember any policy is only as strong as its implementation, and it is uneducated users who are first to break it.

In relation to checking email security policies, Trend Micro enables enterprises through InterScan Messaging Security and ScanMail, either for Microsoft Exchange or Lotus Domino, to take action of macro-enabled documents. Small to medium size business who uses Worry-Free Business Security Advanced can also take advantage of a similar feature with the use of the Messaging Security Agent.

Enterprises who are interested in implementing an enterprise-wide sandbox solution should consider implementing Deep Discovery – all screenshots above for the analysis of W2KM_BARTALEX.SM and W2KM_DLOADR.WYG used Deep Discovery Analyzer.

With additional insights and analysis from Jamz Yaneza, Jeffrey Bernardino and Renato Geroda

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

Macro Malware: When Old Tricks Still Work, Part 2