Understanding VBA Stomping and Purging: Why High-Fidelity Decompilation is Critical

VBA Stomping and VBA Purging are advanced obfuscation techniques that attackers use to bypass detection in Microsoft Office documents. These techniques exploit how macros are stored and executed, creating significant challenges for traditional static analysis tools. Malva․RE, powered by vbaDNA, offers a high-fidelity decompilation process essential for detecting these evasion techniques. Let’s explore both VBA Stomping and VBA Purging in technical detail and explain why accurate detection of these methods requires advanced capabilities.

VBA Macros: Source Code vs. P-Code

In an Office document, a macro is stored in two forms:

Malicious VBA Source Code, decompiled with vbaDNA / Malva.RE

Exemple of P-Code

Internal structure of Module Stream with PerformanceCache and CompressedSourceCode

VBA Stomping: Manipulating the Source Code to Evade Detection

VBA Stomping is an evasion technique where attackers remove or alter the VBA source code while keeping the P-Code intact. This allows the macro to continue functioning, but renders static analysis tools that rely on inspecting the source code ineffective.

Exemple of malicious document exploiting VBA Stomping, where compressed VBA Source Code was altered.

  1. Remove or Corrupt VBA Source Code: Attackers overwrite the VBA source code with harmless-looking content or random data, or delete it entirely. This way, when an analyst opens the document in the VBA editor, the code either appears benign or does not appear at all.

  2. Retain Malicious P-Code: The P-Code (compiled version of the macro) remains untouched and continues to execute when the document is opened. Microsoft Office uses the P-Code to run the macro, bypassing the need for the source code.

  3. Execution via P-Code: Since Microsoft Office prioritizes P-Code execution when it’s available, the missing or harmless-looking source code is irrelevant during macro execution. This creates a blind spot for security tools focused only on the source code, allowing malicious payloads to run undetected.

VBA Purging: Removing the P-Code to Exploit Office’s Fallback Mechanism

VBA Purging is a technique where attackers remove the P-Code from the document entirely, leaving only the compressed VBA source code. This exploits Microsoft Office’s fallback mechanism, where if the P-Code is missing, the application regenerates it from the VBA source code at runtime.

Exemple of malicious document exploiting VBA Purging technic, where the P-Code was removed

  1. P-Code Deletion: Attackers modify the document’s internal structure (particularly the MODULEOFFSET) to effectively remove the P-Code from the VBA project. This forces Office to rely solely on the VBA source code.

  2. Compressed Source Code: The VBA source code is typically stored in a compressed format, which complicates analysis. Detection tools that depend on scanning the P-Code for malicious behavior will fail because the P-Code no longer exists.

  3. Recompilation at Runtime: When Office opens a purged document, it decompresses the source code and recompiles it into P-Code before executing the macro. The malicious macro executes as intended, but static analysis tools relying on pre-execution analysis miss the threat because there is no P-Code to inspect.

Why High-Fidelity Decompilation is Crucial for Detecting Both VBA Stomping and VBA Purging

Accurate detection of VBA Stomping and VBA Purging requires more than just basic source code scanning. A high-fidelity decompiler like vbaDNA in Malva․RE is essential because it can thoroughly analyze both the P-Code and the VBA source code. Here’s why:

Detecting VBA Stomping:

  1. Full Decompilation of P-Code: vbaDNA fully decompiles the P-Code into readable VBA code. This is critical because most traditional tools either don’t inspect the P-Code or can’t accurately decompile it. By exposing the P-Code, vbaDNA ensures that the true logic of the macro is revealed.

  2. Comprehensive Comparison: vbaDNA compares the P-Code and VBA source code at an extremely granular level, detecting any discrepancies between the two. Unlike basic tools that focus on detecting differences in function names or symbols (like VBA Seismograph), vbaDNA detects any change, even something as trivial as extra spaces or line breaks. For example, if an attacker overwrites the source code but leaves the P-Code intact, vbaDNA will detect the inconsistency, no matter how small.

  3. Byte-Level Precision: vbaDNA doesn’t just focus on superficial differences like symbol names—it analyzes the structure of the entire macro, down to the byte level. This allows it to detect both logic changes and seemingly insignificant formatting differences, such as extra spaces or altered indentation, which could indicate tampering.

Detecting VBA Purging:

  1. Focus on the Compressed Source Code: When P-Code is removed via VBA Purging, Malva․RE focuses on the remaining compressed VBA source code. vbaDNA can decompress this code, ensuring that it can be fully inspected for malicious logic. This is crucial because purging the P-Code renders most detection tools ineffective if they rely on the P-Code for signature-based detection.

  2. Detection of Runtime Threats: Since VBA Purging forces Office to regenerate the P-Code at runtime, it evades pre-execution analysis tools. Malva․RE overcomes this by deeply analyzing the VBA source code itself, ensuring that the macro’s malicious behavior is exposed even before it is recompiled and executed.

  3. Handling P-Code Absence: While traditional tools may flag the absence of P-Code as a benign anomaly, Malva․RE understands that the absence of P-Code in combination with suspicious logic in the VBA source code is a sign of VBA Purging. This enables it to catch threats that rely on this evasion technique.

Malva․RE’s Workflow: Why It Excels at Detecting VBA Stomping and Purging

Malva․RE excels at detecting both VBA Stomping and VBA Purging because of its advanced decompilation and analysis capabilities. Here’s how it works:

  1. vbaDNA Decompilation:

  2. Automated Detection of Discrepancies:

  3. Deobfuscation with vbSparkle:

  4. Real-Time Reporting:

Conclusion: Why High-Fidelity Detection is a Must for VBA Stomping and Purging

Detecting VBA Stomping and VBA Purging requires advanced, high-fidelity decompilation and deep analysis capabilities. Malva․RE provides this through its vbaDNA engine, which analyzes both the P-Code and VBA source code with precision. By detecting any discrepancies—whether they are changes in logic, formatting, or missing code—Malva․RE ensures that no malicious macro goes undetected.

With Malva․RE, you gain a powerful defense against these advanced obfuscation techniques, ensuring that both VBA Stomping and VBA Purging are effectively neutralized before they can cause harm.

References: