Skip to content
December 3, 2015 / Vadim Kotov

A Micro-view of Macro Malware

Dridex is a botnet with multiple features, it is most known for stealing people’s credentials on finance-related web sites. Despite the arrest of the gang behind the Dridex malware campaigns, the samples keep popping up on our customers’ machines. And other research groups noticed that as well.

Most of the Dridex attacks we see were triggered by malicious Microsoft Word or Excel in the result of spam disseminations.  Microsoft Office allows its users to create macros – scripts in Visual Basic for Applications (VBA). This feature is used by many companies as a quick and easy way to automate certain parts of their business workflow. Naturally, malware writers take advantage of it. They can create a macro that downloads and executes malware on the victim’s machine, trick a user into opening the document, and trick them into allowing the macro to run. This part of the attack is more in the field of social engineering as attackers must convince a user to open a malicious email attachment and convince them to allow macros (macros won’t run by default).

Microsoft tried to raise awareness earlier this year, but little seems to have been done since then as the spam campaigns featuring macro malware have increased and evolved to become more effective.

About a year ago when macro malware became so prevalent that everybody started taking it seriously again, a typical piece of malicious VBA would look like this:

2015-12-01-vk-01-old_macro

Detecting this type of code seems to be relatively easy; there are certain patterns that give away the malicious intent of that script.

As far as the functionality goes, the workflow of this script would be something like this:

  1. Create three hidden files:
  • a batch file <random_name>.bat
  • a VBS file <random_name>.vbs
  • a PowerShell file <random_name>.ps1
  1. Execute them one after another:
  2. bat
    1. call exe 1.1.2.2 –n 2
    2. run <rando_ name>.vbs using exe
  3. vbs
    1. run <random_name>.ps1 using PowerShell
  4. ps1
    1. download the malicious URL hardcode into the macro to file <random_name_2>.exe
    2. run exe /c crsss2.exe
    3. Delete batch, VBS and PowerShell files

Aside from being easy to fingerprint, this macro was dependent on PowerShell and not everybody had one.

From there it kept changing somewhat, gradually, and by Spring/Summer of 2015, it became much better obfuscated. Below is the example of the download function:

2015-12-01-vk-02-avg_macro_obf

And here is its clean version:

2015-12-01-vk-03-avg_macro_DEobf

So this time, extracting the malware artifacts or heuristics (at least statically) is not quite straightforward and code redundancy is pretty big. However, the obfuscation scheme itself can be used as a detection parameter. Names of the variables do not correlate to any Latin based language characteristics.

Functionally, this script is similar to the previous one, except the hardcoded URL points at an encrypted list of malware URLs instead of directly at the malware executable. This allows attackers to change the malware URLs (as they tend to die faster than those supplying download targets) without re-packing the macro and re-setting the spam campaign.

One of the latest cases we’ve seen is much more straightforward. It downloads and executes an instance of Dridex from a hardcoded URL. The malicious macro has a lot of redundant code and tries to disguise itself as a business automation script:

2015-12-01-vk-06-balancing_idx

The figure above shows references to “Vouchers” (@fullVoucher) and “Balancing Indices” (SelectDailyBalancingIdx) – all in order to appear a legitimate program. However, upon careful examination, suspicious elements can be found, such as obfuscated URL of the malicious server:

2015-12-01-vk-07-obfuscated_url

After decoding the number array on the image resolves to the following URL:

  • hxxp://kdojinyhb.wz.cz/87yte55/6t45eyv.exe

The script then downloads this executable, saves it as %temp%\\damedig.exe and launches it. In this example, less than 10 percent of the code had to do with malicious functions.

This scheme seems to be particularly popular in Excel files. This one, for example contains lots of junk code as well, furthermore we were even able to trace back the source of that junk code. It was a game engine written in Visual Basic.

2015-12-01-vk-04-banks_players

This is interesting because the “junk” was taken from a legitimate code repository. “Obfuscating” malcode this way requires little effort, but apparently pays off, as it becomes harder to notice in a bloated up macro.

So contents of the macros mimic some legitimate data, but what about the names of those files? Let’s look at a free dynamic analysis platform Malwr, where people regularly submit all kinds of files to run it against Cuckoo sandbox. If we search for “type:xls” and select the entries with one or more VirusTotal alerts here’s what we’ll find:

2015-12-01-vk-05-names

The names are in fact easy to confuse with the names of legitimate documents routinely flowing through any organization’s network.

The corporate sector might be a preferred attack vector for the macro malware spammers and Dridex in particular. With enormous volumes of emails and documents a corporate environment seems to be more prone to spam campaigns like this.

As exploitation and drive-by-download attacks get harder to pull off, cybercriminals seem to look back into classic tried and true techniques, such as MS Office macro.

 

%d bloggers like this: