Visual Basic for Applications and the dangers of allowing Office macros

Visual Basic for Applications (VBA) is one of the easiest methods to deliver a payload nowadays, namely by dropping it into an Office doc as a macro and attaching to an email . This is usually easier than sending executables by email, as those are blocked by Outlook and/or may require local admin rights to install.

The victim opens an Office file attachment delivered to them by email. It’ll often have ‘lure’ content that looks plausible, convincing the user to click the ‘enable macros’ alert, the macro runs, then we have lovely reverse shell and back door on their desktop.

This method has been highly effective as the initial stage in the series of ‘RocketKitten‘ attacks presented at this years 31C3 event, though it’s been around for years.

The fix is easy, but hardly any organisations do it: simply block macros in Group Policy. Granted, some departments need macros for spreadsheet and other operations, but at the very least restrict macro use to only those who explicitly need it. Give special training on phishing attacks to those who do have macros enabled, ensure they are particularly careful with Office files from external sources.

It’s often the finance department that relies on macros; ah yes, the department that has access to the company bank accounts and makes the ideal target for banking credential theft.

The technique has been around for a few years, there’s a great write up from 2010 by Didier Stevens here

that explains how to inject shellcode in to the Excel process. It takes advantage of VBA macros and Windows APIs using VirtualAlloc, WriteProcessMemory and CreateThread. That’s quite handy, as the injection process occurs in memory without writing to disc, so is less likely to be detected by anti-virus software.

It got a whole lot easier when similar techniques emerged in Metasploit: creating an HTTPS reverse shell as an Office macro requires just one more step – ‘generate –t vba’ would do it. That gives you the required VBA code to copy/paste in to your dodgy Office file.

Now, if you load that ‘infected’ Office file to VirusTotal you’re going to get lots of hits; many decent anti-virus products will detect the file as being dodgy. That said, a sample we loaded on Xmas Eve Eve was only picked up by two vendors:

However, it’s easy to change the signature of the file by splitting up the offending VBA. This is done by simply moving the API calls into separate modules and creating aliases for the functions. This is just one of many ways of evading detection though. Here you can see the calls split into separate modules:

Uploaded and scanned again at Virus Total gives us the following results, avoiding detection:

There are other workarounds to the problem, though these are general good practice anyway. For example, endpoint protection should catch more, multiple layers of anti-virus increase the chance of detection, whitelisting of internet sites may cripple the connect-back and of course evaluating files in a micro VM, watching for suspicious activity may also help.

Digitally signing macros required for genuine business requirements would also be wise, again GPO can be configured to only allow signed macros to be run. Only signed code should run, so malicious code should be blocked.

Group Policy can also be used to allow macros to run without security alerts to the user, sometimes used to reduce support calls from cautious users. Clearly that’s not wise!

Permitting Office macros needs serious consideration. It’s an awesome delivery mechanism for nasties, so the default position should be to block.

“Office macro payloads are one of the few cool uses for VBA,”