Easy Office document hacking with VBA Stomping or Purging

Common programming tools can be used to make malicious Office workbooks which bypass both online security checks and Microsoft’s own protections in Word, Excel, PowerPoint or Access.  We’ll explain what’s happening and what Microsoft could do better.

VBA Purging or VBA Stomping are clever tricks to make an Office documents (e.g. .xlsm Excel workbook) with macros but in a special way that can sometimes fool security software.

NVISO found that macro workbooks made with third-party tools like EPPlus .NET are different from .xlsm files made by Excel itself.  That difference is enough to fool some security software into passing malicious files to users as ‘safe’.

At the moment, infected workbooks are designed to steal information (logins, passwords etc) but the technique could be used for other nasties like ransomware.

VBA code is saved twice

Hackers are taking advantage of a little known part of the modern Office document format.  VBA macro code is saved twice in Office documents.

The code is stored in two forms:

  • The original source code in a compressed form: CompressedSourceCode
  • A compiled version of the same code: PerformanceCache or P-code.  The compiled code is what Excel executes.
Source: NVISO

The PerformanceCache is updated whenever the VBA text code it changed.  As the name suggests, Microsoft does this so macros run faster without any delay recompiling from source code.

The two versions are saved within the .xlsm or other macro enabled document but not in the XML format that almost everything else is saved as.

Instead there’s a vbaproject.bin file within the OOXML (modern Office 2007+) format.  That Module Stream contains both the source code and performance cache version.

VBA Purging and Stomping

Having two versions of the same thing with no proper cross-checking is an open invitation to hackers.

Removing either the compiled or VBA source (leaving just one version) helps bypass anti-virus and security checks. 

Deleting the PerformanceCache from an Office document reduces the chances that it will be detected as malicious.  This is called VBA Purging.

Some anti-virus checks rely on strings inside the PerformanceCache. Removing the Cache bypasses those tests.

Another trick is replacing the source code with NUL characters, known as VBA Stomping.  That leaves the malicious PerformanceCache only version that Excel will execute.

Presumably it’s also possible to create a macro document with innocent looking VBA source code but a PerformanceCache that’s other, malicious, code.

You might be surprised that Office will run the compiled VBA PerformanceCache without matching source code? Apparently, that elementary security check hasn’t been included by Microsoft.

Making Office document without compiled VBA

EPPlus and other third party tools can make an Office document with macros but only the VBA source code can be saved.

Making the PerformanceCache version of a macro is proprietary to Microsoft and not available to third-party developers.  If a document is opened with VBA but no PerformanceCache, the Office program will automatically make the cached version.

An Office document with no PerformanceCache is NOT itself the sign of a malicious document. Office docs with macros made by third-party tools can only have VBA source.

Making Office document without VBA source

Creating an Office document without the VBA source (only the PerformanceCache version) is trickier but quite possible.

The VBA Source can’t simply be deleted, it’s replaced with NUL characters to fill the space where the text source should be.  It seems anti-virus software doesn’t always detect the missing VBA source as a problem.

Even stranger, the Office programs (Word, Excel etc) don’t notice the missing source code and run the PerformanceCache version directly.

An Office document without proper VBA source code should be a warning sign of a possibly malicious file.  There’s no good reason for an Office document with macros to have a PerformanceCache only with no source.  Security software should detect source that’s full of NUL characters.

(We’re simplifying a lot.  The PerformanceCache version varies according to the Office software version and platform.  The hacked document needs a PerformanceCache which matches the Office software used by the victim).

Lifting their game

Both security companies and Microsoft need to lift their game in light of these discoveries.

Anti-virus checks need to check for the presence of real VBA source code – not just NUL characters.  They also shouldn’t rely on strings inside the PerformanceCache as part of their checks.

Microsoft should also add an option for customers to protect against a mismatch between the VBA source and the compiled cache.

Perhaps a switch to force recompiling VBA whenever a macro enabled document is opened? This would not only prevent VBA Purging but also stop occasional runtime errors when opening a document created in a different version of Office.

To learn more check out NVISO’s blog posts.
Epic Manchego – atypical maldoc delivery brings flurry of infostealers
Evidence of VBA Purging Found in Malicious Documents

Windows update causes Office VBA to fail
Excel worksheet protection is not encryption
Excel automatic refresh and recalculation tricks