T1564.007: VBA Stomping
Adversaries may hide malicious Visual Basic for Applications (VBA) payloads embedded within MS Office documents by replacing the VBA source code with benign data.[1]
MS Office documents with embedded VBA content store source code inside of module streams. Each module stream has a PerformanceCache that stores a separate compiled version of the VBA source code known as p-code. The p-code is executed when the MS Office version specified in the _VBA_PROJECT stream (which contains the version-dependent description of the VBA project) matches the version of the host MS Office application.[2][3]
An adversary may hide malicious VBA code by overwriting the VBA source code location with zero’s, benign code, or random bytes while leaving the previously compiled malicious p-code. Tools that scan for malicious VBA source code may be bypassed as the unwanted code is hidden in the compiled p-code. If the VBA source code is removed, some tools might even think that there are no macros present. If there is a version match between the _VBA_PROJECT stream and host MS Office application, the p-code will be executed, otherwise the benign VBA source code will be decompressed and recompiled to p-code, thus removing malicious p-code and potentially bypassing dynamic analysis.[4][1][5]
Analyst context for executives and security teams
VBA Stomping matters because a malicious Office document can appear to have harmless or missing macro source while still retaining compiled VBA p-code that may execute under matching Office version conditions. For leaders, the issue is not just “macro malware”; it is whether document inspection, sandboxing, and email/SOC workflows can see beyond visible VBA source code.
Executive priority
Treat this as a validation point for macro-risk controls and incident readiness. If the organization relies on source-code macro scanning alone, this technique can create a blind spot in email security, malware triage, and audit evidence around document handling. Priority should be on confirming that unnecessary Office macro capability is disabled or removed where feasible, and that security teams can analyze compiled VBA artifacts when business processes still require macro-enabled documents.
Technical view
ATT&CK places VBA Stomping under stealth as a sub-technique of Hide Artifacts. SOC and detection engineering teams should validate handling of MS Office documents containing VBA module streams, PerformanceCache p-code, and _VBA_PROJECT version metadata. Because ATT&CK provides no official detection text for this object, coverage should be assessed against the related detection strategy DET0012 and by testing whether tooling flags inconsistencies between benign or absent VBA source and remaining compiled p-code. IR teams should avoid clearing a document only because visible macro source appears benign or missing.
Likely telemetry
- Email gateway and attachment-analysis results for macro-enabled Office documents
- Endpoint file telemetry for Office documents opened or saved on Windows, macOS, and Linux environments where applicable
- Office document static-analysis output, including VBA module streams, source code presence, p-code or PerformanceCache indicators, and _VBA_PROJECT metadata
- Sandbox or detonation results that account for Office version-dependent execution behavior
- Malware triage notes and extracted document-structure artifacts
Detection direction
- Validate that macro scanning does not depend only on decompressed VBA source code.
- Tune document-analysis workflows to identify mismatches between VBA source and compiled p-code indicators.
- Account for possible false negatives in dynamic analysis when the Office version in _VBA_PROJECT does not match the analysis host and benign source is recompiled.
- Use relationship context from DET0012 as the starting point for a formal detection strategy, since the ATT&CK object itself does not include official detection guidance.
- Review benign business macro documents to understand normal VBA structures before alerting on stomping-like inconsistencies.
Mitigation priorities
- Apply M1042 principles: disable or remove unnecessary Office macro capability, vulnerable features, or software where business processes do not require them.
- Reduce reliance on macro-enabled documents by replacing them with safer business workflows where practical.
- For required macro use cases, enforce controlled handling and review processes rather than broad user enablement.
- Ensure document-analysis tools used by email security, SOC, and IR can inspect compiled VBA artifacts, not only visible source.
Analyst notes and limits
This technique is especially relevant to managed detection, incident response, and security consulting because it tests whether document malware controls inspect the real executable macro artifacts. The supplied ATT&CK relationship to Hide Artifacts reinforces that the defensive question is visibility: can teams prove what was hidden, where it was inspected, and why a document was allowed or blocked?
The ATT&CK object does not provide official detection text, procedure examples, or attributed threat activity. Local validation is required to determine whether specific Office versions, document-processing systems, email controls, and endpoint tools expose the necessary p-code and VBA project evidence.
VBA Stomping
Adversaries may hide malicious Visual Basic for Applications (VBA) payloads embedded within MS Office documents by replacing the VBA source code with benign data.[1]
MS Office documents with embedded VBA content store source code inside of module streams. Each module stream has a PerformanceCache that stores a separate compiled version of the VBA source code known as p-code. The p-code is executed when the MS Office version specified in the _VBA_PROJECT stream (which contains the version-dependent description of the VBA project) matches the version of the host MS Office application.[2][3]
An adversary may hide malicious VBA code by overwriting the VBA source code location with zero’s, benign code, or random bytes while leaving the previously compiled malicious p-code. Tools that scan for malicious VBA source code may be bypassed as the unwanted code is hidden in the compiled p-code. If the VBA source code is removed, some tools might even think that there are no macros present. If there is a version match between the _VBA_PROJECT stream and host MS Office application, the p-code will be executed, otherwise the benign VBA source code will be decompressed and recompiled to p-code, thus removing malicious p-code and potentially bypassing dynamic analysis.[4][1][5]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1564 | Hide Artifacts | This object subtechnique of Hide Artifacts. |
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 041c16c30cc6… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
FireEye VBA stomp Feb 2020
Cole, R., Moore, A., Stark, G., Stancill, B. (2020, February 5). STOMP 2 DIS: Brilliance in the (Visual) Basics. Retrieved September 17, 2020.
Open source URL -
[2]
Evil Clippy May 2019
Hegt, S. (2019, May 5). Evil Clippy: MS Office maldoc assistant. Retrieved September 17, 2020.
Open source URL -
[3]
Microsoft _VBA_PROJECT Stream
Microsoft. (2020, February 19). 2.3.4.1 _VBA_PROJECT Stream: Version Dependent Project Information. Retrieved September 18, 2020.
Open source URL -
[4]
Walmart Roberts Oct 2018
Sayre, K., Ogden, H., Roberts, C. (2018, October 10). VBA Stomping — Advanced Maldoc Techniques. Retrieved September 17, 2020.
Open source URL -
[5]
pcodedmp Bontchev
Bontchev, V. (2019, July 30). pcodedmp.py - A VBA p-code disassembler. Retrieved September 17, 2020.
Open source URL -
[6]
mitre-attack T1564.007Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.