According to the IBM X-Force Thread Intelligence Index 2025, the Instylizers ranked first among all categories of malwarmers for 2024 - 32% of the samples found. The main delivery channel has not changed: a phishing email with an attachment of .docm or .pdf. And according to CrowdStrike Global Threat Report 2025, the malicious use of GenAI for phishing has doubled over the year - the attackers rivet convincing baits faster than analysts have time to disassemble them. In practice, this means one thing: the analyst has more and more suspicious investments on the table, and there is less and less time for each. Next is the step-by-step workflow analysis of malicious documents: from the definition of the type of threat to the extraction of payload and C2 addresses.
The place of malicious document in the attack chain
The malicious document is not an independent threat, but the entry point into the victim’s infrastructure. If you stop at the extraction of the macro and do not reach the real impact - consider, the work did not.
Typical kill chain for document-based attack on MITRE ATT&CK:
1. Initial Access - delivery of the document through Spearphishing Attachment (T1566.001). The victim receives an attachment letter.
2. Execution- The victim opens the file. Options for triggering:
◦ Malicious File (T1204.002): the user includes macros on request
◦ Visual Basic (T1059.005): VBA matcro runs malicious code
◦ Exploitation for Client Execution (T1203): exploit is triggered without user actions other than opening (e.g. CVE-2021-40444)
◦ PowerShell (T1059.001): Macro calls powershell.exeto download the next stage
◦ Windows Command Shell (T1059.003): macro use cmd.exeto execute commands, upload files T1105(T1105) or to hide data in NTFS flows (T1564.004)
3. Defense Evasion - payload is hidden inside the document via Embedded Payloads (T1027.009) and requires Deobfusctation/Decode (T1140) when executed.
4. Command and Control - loading the main implant via Ingress Tool Transfer (T1105).
The task of the analyst is to go through this chain in the opposite direction: from document to macro, from macro to payload, from payload to C2 infrastructure, from C2 to compromise indicators.
Business Logic: the attacker uses the document as a cheap scalable vector of initial access. According to Verizon DBIR 2025, 68% of leaks include the human factor – social engineering through the document exploits just this. The ultimate goal varies: from installing an infoseller for the sale of credentials on marketplaces to the deployment of ransomware (media ransom - $46,000 according to the same report).
Adjustments to the environment for maldoc analysis
Before touching the file - prepare the workplace:
• OS: REMnux 7.0 (Ubuntu-based distribution for reverse engineering, actively supported) or any Linux with Python 3.8+
• RAM: minimum 4 GB for VM analysis, 8 GB is recommended at parallel launch of sandbox
• Network: strictly isolated - host-only or internal network in VirtualBox/VMware. NAT is prohibited: a malicious document during detonation can turn to a real C2, and then instead of analysis you will get an incident
• oletools (version 0.60.2, project is actively supported on GitHub): pip3 install oletools- gives olevba, oleid, olemeta, oleobj, mraptor
• PDF-tools: pdfidand pdf-parser(Didier Stevens, actively updated), peepdf
• Additionally: CyberChef (GCHQ, offline version), YARA, xorsearch, Wireshark
In EMNux, all this is preset from the box. On other distributions will have to be put with your hands.
Static analysis of malicious Office files with oletools
Static analysis of malicious files is the first stage, and often it gives enough IoC without starting a sample. For Office documents, the main working tool is the oletools package.
Formats and what is dangerous in them
Before consideration is a key difference in formats. Binary files (.doc, .xls) use the OLE2 format (Stroctured Storage). OOXML files (.docx, .xlsx) - ZIP archives. VBA macrosses in OOXML are stored inside the nested OLE2 file, which lies in this ZIP archive. Macro-enabled files have suffix extension m: .docm, .xlsm, .pptm. Files .docx and .xlsx cannot contain VBA macros according to the OOXML specification, but may contain Excel 4.0 (XLM) macros in the formulas of sheets - without OLE2-container. RTF files do not support macros, but can contain malicious built-in OLE objects and parser exploits.
Workflow: oleid, olemeta, mortar, olevba
Sequence of actions on a real sample:
Step 1. oleid suspicious.docm - determines the file format, the presence of VBA macros, encrypted data, XLM-macros and external relationships (External Relationships).
Step 2. olemeta suspicious.docm - extracts metadata: author, date of creation and modification, company, path to the template. Metadata can contain the attacker artifacts - the real user name, the name of the organization, the path to the file on the developer's machine. It happens that in the field Author sticks out Иван Петров with the way C:\Users\ivan.petrov\Desktop\payload_builder\ - and it's half-easy. Time of creation through oletimes Clarifies the chronology.
Step 3. mraptor suspicious.docm - fast triage: checks for auto-triggers (AutoOpen, AutoExec, Document_Open, Workbook_Open). If you find an automatic start + record in the file system + execution of external commands - mark the file as SUSPICIOSUS. Convenient for sorting large volumes of samples, when there is 50 investments from morning phishing on the table.
Step 4. olevba -a suspicious.docm - central tool. Flag -a launches the analysis and displays a table of suspicious keywords. Typical conclusion:
Code:
+----------+--------------------+---------------------------------------------+
| Type | Keyword | Description |
+----------+--------------------+---------------------------------------------+
| AutoExec | AutoOpen | Runs when the Word document is opened |
| Suspicious | Shell | May run an executable or system command |
| Suspicious | powershell | May run PowerShell commands |
| Suspicious | CreateObject | May create an OLE object |
| Suspicious | MSXML2.XMLHTTP | May download files from the Internet |
| IOC | http://evil[.]com | URL (potential C2 or download) |
+----------+--------------------+---------------------------------------------+
For a full VBA-code dump: olevba -c suspicious.docm > macro_dump.vba. This gives raw code for manual obtoscia.
Analysis of VBA malicious macros: obfuscation and debfusion
Malvar in the Macrox Office almost never comes in its pure form. The analysis of malicious VBA macros is 80% debfusion and 20% tracing of the execution flow. The remaining 0% is the hope that the author of the malwar forgot to ombos (it happens, but rarely).
Model Obfuscation Techniques
Chr() and ChrW() chains Each line symbol is replaced by a function call. Line "powershell" becomes Chr(112) & Chr(111) & Chr(119) & Chr(101) & Chr(114) & Chr(115) & Chr(104) & Chr(101) & Chr(108) & Chr(108). De-fusing in CyberChef: Recipe From Charcode (Decimal).
Concatenation of the lines - partition into fragments: "pow" & "er" & "she" & "ll". It is often combined with Chr() for complication.
Base64-encoding - the payload is encoded in Base64 and decoded in rent. Characteristic marker in OLevba: call powershell -enc [base64_blob] or the FromBase64String function. For manual decoding: echo "[base64]" | base64 -d in the terminal. The nuance on which stumbling: PowerShell -EncodedCommand uses UTF-16LE, so for such lines you need printf '%s' '[base64]' | base64 -d | iconv -f UTF-16LE -t UTF-8.
XOR-encryption of lines - macros contains an XOR function and an array of encrypted bytes. Example of debfusion:
Python:
data = b'\x82\x85\x8c\x8c\x8f'
key = 0xED
result = bytes([b ^ key for b in data])
print(result.decode()) # "Hello"
The XOR key can be picked up through xorsearch from the EMNux set, substituting the known lines: http://, .exe, cmd.
Storage of payload in the properties of the document - the attacker records malicious code in the Author, Comments or Custom Properties field, and the macro extracts data from there through ActiveDocument.BuiltInDocumentProperties. Through olemeta This can be seen, but OLELBA does not always associate the property with the macro - you have to dig manually. One of the real cases: Base64-encoded PowerShell was hiding in the Author field, and the macro did decode it and launched it through msbuild.exe - classic Living off the Land to bypass monitoring powershell.exe.
Renaming of variables - Meaningful names are replaced by random: Sub AutoOpen() calls xQ3kL(), which calls pR9mN(). Here helps only manual analysis - you sit down and trace the flow of execution, renaming the functions as you understand.
When static analysis of the VBA is insufficient
Modern campaigns use multi-stage load: the first stage is only a downloader that pulls the second stage from the network. Static analysis will show the URL of the upload, but not the final payload. In such cases, without a dynamic analysis of malicious documents in sandbox can not do.
PDF exploit analysis: keywords and retrieval of scripts
PDF files are the second most common document-based attack vector. Unlike Office, PDF does not use VBA. The attackers work through the built-in JavaScript, PDF-reader parser exploits and built-in objects.
Primary assessment with pdfid
pdfid (Didier Stevens, actively supported) scans PDF and calculates dangerous keywords. Start: pdfid suspicious.pdf.
In-depth analysis with pdf-parser
If pdfid showed suspicious keywords, we move on to retrieval of the content of specific objects: pdf-parser --search javascript suspicious.pdf Finds all objects with JavaScript. Receiving the number of the object: pdf-parser --object 10 --filter --raw suspicious.pdf Removes and decodes its contents.
Inside the JavaScript code PDF is often detected, a lludecode or system command calls through cmd.exe. To analyze the extracted JavaScript - SpiderMonkey or box-js in an isolated environment.
[Restrictions: pdfid and pdf-parser only work with valid PDF structure. Strongly damaged or specially crafted files with non-standard cross-reference tables may require manual hex analysis or an alternative peepdf tool.]
CVE-2021-40444: Exposure analysis without macros in the Office document
CVE-2021-40444 is an example of an attack where a malicious document does not contain macros. Standard checks via OLevba are useless here. The exploit uses a vulnerability in MSHTML to remotely execute code through malicious ActiveX control.
Verified NVD data:
• CVSS: 8.8 (HIGH)
• Vector: CVSS:3.1/AV:N/AV:N/C/C/C/C/C/C/A:L:L - network vector (AV:N):N), low complexity (AC:L), privileges are not needed (PR:N), but user action (UI:R) required
• CWE: CWE-22 (Path Traversal) - NVD classification; according to the analysis of researchers (NC Group, etc.), path traversal is used in the operating chain at the stage of placing an INF file of the CAB archive; root vulnerability - unsafe processing of ActiveX content in MSHTML during OOXML-document
• Thrown products: All supported versions of Windows with vulnerable MSHTML (Windows 10, Windows Server, Windows 11 until September 2021 patch). NVD CPE explicitly lists Windows 10 1507/1607/1809/1909/2004
• Included in the directory of CISA KEV (actively operated in the wild), related to ransomware campaigns
Mechanics: OOXML document contains an external relationship (external relationship) in the file word/_rels/document.xml.rels, which points to a URL with malicious ActiveX-control. When you open a document, the MSHTML engine processes this link and downloads the exploit. The user does not need to include macros - the vulnerability exploits HTML content parsing (T1203) According to Microsoft, MSTIC and Mandiant CVE-2021-40444 used to deliver Cobalt Strike Beacon in targeted campaigns - the opening of a document (UI:R) was required to trigger, but the inclusion of macros was not required. The exploit has bypassed the mechanism of control of access to active content, which is conceptually close to the problem of Broken Access Control (OWASP A01:2021)
Detection via oleobj
For analysis: oleobj -r suspicious.docx - the script extracts all external relationships and displays suspicious URLs. Alternative manual method: unpack OOXML as ZIP (unzip suspicious.docx -d extracted/), find the file word/_rels/document.xml.rels and check the attributes TargetMode="External" - Any external URL here is suspicious.
[Applicable to: DFIR-investigation of incidents on unstoppled Windows 10 legacy systems. On updated systems, the exploit does not work.]
The place of malicious document in the attack chain
The malicious document is not an independent threat, but the entry point into the victim’s infrastructure. If you stop at the extraction of the macro and do not reach the real impact - consider, the work did not.
Typical kill chain for document-based attack on MITRE ATT&CK:
1. Initial Access - delivery of the document through Spearphishing Attachment (T1566.001). The victim receives an attachment letter.
2. Execution- The victim opens the file. Options for triggering:
◦ Malicious File (T1204.002): the user includes macros on request
◦ Visual Basic (T1059.005): VBA matcro runs malicious code
◦ Exploitation for Client Execution (T1203): exploit is triggered without user actions other than opening (e.g. CVE-2021-40444)
◦ PowerShell (T1059.001): Macro calls powershell.exeto download the next stage
◦ Windows Command Shell (T1059.003): macro use cmd.exeto execute commands, upload files T1105(T1105) or to hide data in NTFS flows (T1564.004)
3. Defense Evasion - payload is hidden inside the document via Embedded Payloads (T1027.009) and requires Deobfusctation/Decode (T1140) when executed.
4. Command and Control - loading the main implant via Ingress Tool Transfer (T1105).
The task of the analyst is to go through this chain in the opposite direction: from document to macro, from macro to payload, from payload to C2 infrastructure, from C2 to compromise indicators.
Business Logic: the attacker uses the document as a cheap scalable vector of initial access. According to Verizon DBIR 2025, 68% of leaks include the human factor – social engineering through the document exploits just this. The ultimate goal varies: from installing an infoseller for the sale of credentials on marketplaces to the deployment of ransomware (media ransom - $46,000 according to the same report).
Adjustments to the environment for maldoc analysis
Before touching the file - prepare the workplace:
• OS: REMnux 7.0 (Ubuntu-based distribution for reverse engineering, actively supported) or any Linux with Python 3.8+
• RAM: minimum 4 GB for VM analysis, 8 GB is recommended at parallel launch of sandbox
• Network: strictly isolated - host-only or internal network in VirtualBox/VMware. NAT is prohibited: a malicious document during detonation can turn to a real C2, and then instead of analysis you will get an incident
• oletools (version 0.60.2, project is actively supported on GitHub): pip3 install oletools- gives olevba, oleid, olemeta, oleobj, mraptor
• PDF-tools: pdfidand pdf-parser(Didier Stevens, actively updated), peepdf
• Additionally: CyberChef (GCHQ, offline version), YARA, xorsearch, Wireshark
In EMNux, all this is preset from the box. On other distributions will have to be put with your hands.
Static analysis of malicious Office files with oletools
Static analysis of malicious files is the first stage, and often it gives enough IoC without starting a sample. For Office documents, the main working tool is the oletools package.
Formats and what is dangerous in them
Before consideration is a key difference in formats. Binary files (.doc, .xls) use the OLE2 format (Stroctured Storage). OOXML files (.docx, .xlsx) - ZIP archives. VBA macrosses in OOXML are stored inside the nested OLE2 file, which lies in this ZIP archive. Macro-enabled files have suffix extension m: .docm, .xlsm, .pptm. Files .docx and .xlsx cannot contain VBA macros according to the OOXML specification, but may contain Excel 4.0 (XLM) macros in the formulas of sheets - without OLE2-container. RTF files do not support macros, but can contain malicious built-in OLE objects and parser exploits.
Workflow: oleid, olemeta, mortar, olevba
Sequence of actions on a real sample:
Step 1. oleid suspicious.docm - determines the file format, the presence of VBA macros, encrypted data, XLM-macros and external relationships (External Relationships).
Step 2. olemeta suspicious.docm - extracts metadata: author, date of creation and modification, company, path to the template. Metadata can contain the attacker artifacts - the real user name, the name of the organization, the path to the file on the developer's machine. It happens that in the field Author sticks out Иван Петров with the way C:\Users\ivan.petrov\Desktop\payload_builder\ - and it's half-easy. Time of creation through oletimes Clarifies the chronology.
Step 3. mraptor suspicious.docm - fast triage: checks for auto-triggers (AutoOpen, AutoExec, Document_Open, Workbook_Open). If you find an automatic start + record in the file system + execution of external commands - mark the file as SUSPICIOSUS. Convenient for sorting large volumes of samples, when there is 50 investments from morning phishing on the table.
Step 4. olevba -a suspicious.docm - central tool. Flag -a launches the analysis and displays a table of suspicious keywords. Typical conclusion:
Code:
+----------+--------------------+---------------------------------------------+
| Type | Keyword | Description |
+----------+--------------------+---------------------------------------------+
| AutoExec | AutoOpen | Runs when the Word document is opened |
| Suspicious | Shell | May run an executable or system command |
| Suspicious | powershell | May run PowerShell commands |
| Suspicious | CreateObject | May create an OLE object |
| Suspicious | MSXML2.XMLHTTP | May download files from the Internet |
| IOC | http://evil[.]com | URL (potential C2 or download) |
+----------+--------------------+---------------------------------------------+
For a full VBA-code dump: olevba -c suspicious.docm > macro_dump.vba. This gives raw code for manual obtoscia.
Analysis of VBA malicious macros: obfuscation and debfusion
Malvar in the Macrox Office almost never comes in its pure form. The analysis of malicious VBA macros is 80% debfusion and 20% tracing of the execution flow. The remaining 0% is the hope that the author of the malwar forgot to ombos (it happens, but rarely).
Model Obfuscation Techniques
Chr() and ChrW() chains Each line symbol is replaced by a function call. Line "powershell" becomes Chr(112) & Chr(111) & Chr(119) & Chr(101) & Chr(114) & Chr(115) & Chr(104) & Chr(101) & Chr(108) & Chr(108). De-fusing in CyberChef: Recipe From Charcode (Decimal).
Concatenation of the lines - partition into fragments: "pow" & "er" & "she" & "ll". It is often combined with Chr() for complication.
Base64-encoding - the payload is encoded in Base64 and decoded in rent. Characteristic marker in OLevba: call powershell -enc [base64_blob] or the FromBase64String function. For manual decoding: echo "[base64]" | base64 -d in the terminal. The nuance on which stumbling: PowerShell -EncodedCommand uses UTF-16LE, so for such lines you need printf '%s' '[base64]' | base64 -d | iconv -f UTF-16LE -t UTF-8.
XOR-encryption of lines - macros contains an XOR function and an array of encrypted bytes. Example of debfusion:
Python:
data = b'\x82\x85\x8c\x8c\x8f'
key = 0xED
result = bytes([b ^ key for b in data])
print(result.decode()) # "Hello"
The XOR key can be picked up through xorsearch from the EMNux set, substituting the known lines: http://, .exe, cmd.
Storage of payload in the properties of the document - the attacker records malicious code in the Author, Comments or Custom Properties field, and the macro extracts data from there through ActiveDocument.BuiltInDocumentProperties. Through olemeta This can be seen, but OLELBA does not always associate the property with the macro - you have to dig manually. One of the real cases: Base64-encoded PowerShell was hiding in the Author field, and the macro did decode it and launched it through msbuild.exe - classic Living off the Land to bypass monitoring powershell.exe.
Renaming of variables - Meaningful names are replaced by random: Sub AutoOpen() calls xQ3kL(), which calls pR9mN(). Here helps only manual analysis - you sit down and trace the flow of execution, renaming the functions as you understand.
When static analysis of the VBA is insufficient
Modern campaigns use multi-stage load: the first stage is only a downloader that pulls the second stage from the network. Static analysis will show the URL of the upload, but not the final payload. In such cases, without a dynamic analysis of malicious documents in sandbox can not do.
PDF exploit analysis: keywords and retrieval of scripts
PDF files are the second most common document-based attack vector. Unlike Office, PDF does not use VBA. The attackers work through the built-in JavaScript, PDF-reader parser exploits and built-in objects.
Primary assessment with pdfid
pdfid (Didier Stevens, actively supported) scans PDF and calculates dangerous keywords. Start: pdfid suspicious.pdf.
In-depth analysis with pdf-parser
If pdfid showed suspicious keywords, we move on to retrieval of the content of specific objects: pdf-parser --search javascript suspicious.pdf Finds all objects with JavaScript. Receiving the number of the object: pdf-parser --object 10 --filter --raw suspicious.pdf Removes and decodes its contents.
Inside the JavaScript code PDF is often detected, a lludecode or system command calls through cmd.exe. To analyze the extracted JavaScript - SpiderMonkey or box-js in an isolated environment.
[Restrictions: pdfid and pdf-parser only work with valid PDF structure. Strongly damaged or specially crafted files with non-standard cross-reference tables may require manual hex analysis or an alternative peepdf tool.]
CVE-2021-40444: Exposure analysis without macros in the Office document
CVE-2021-40444 is an example of an attack where a malicious document does not contain macros. Standard checks via OLevba are useless here. The exploit uses a vulnerability in MSHTML to remotely execute code through malicious ActiveX control.
Verified NVD data:
• CVSS: 8.8 (HIGH)
• Vector: CVSS:3.1/AV:N/AV:N/C/C/C/C/C/C/A:L:L - network vector (AV:N):N), low complexity (AC:L), privileges are not needed (PR:N), but user action (UI:R) required
• CWE: CWE-22 (Path Traversal) - NVD classification; according to the analysis of researchers (NC Group, etc.), path traversal is used in the operating chain at the stage of placing an INF file of the CAB archive; root vulnerability - unsafe processing of ActiveX content in MSHTML during OOXML-document
• Thrown products: All supported versions of Windows with vulnerable MSHTML (Windows 10, Windows Server, Windows 11 until September 2021 patch). NVD CPE explicitly lists Windows 10 1507/1607/1809/1909/2004
• Included in the directory of CISA KEV (actively operated in the wild), related to ransomware campaigns
Mechanics: OOXML document contains an external relationship (external relationship) in the file word/_rels/document.xml.rels, which points to a URL with malicious ActiveX-control. When you open a document, the MSHTML engine processes this link and downloads the exploit. The user does not need to include macros - the vulnerability exploits HTML content parsing (T1203) According to Microsoft, MSTIC and Mandiant CVE-2021-40444 used to deliver Cobalt Strike Beacon in targeted campaigns - the opening of a document (UI:R) was required to trigger, but the inclusion of macros was not required. The exploit has bypassed the mechanism of control of access to active content, which is conceptually close to the problem of Broken Access Control (OWASP A01:2021)
Detection via oleobj
For analysis: oleobj -r suspicious.docx - the script extracts all external relationships and displays suspicious URLs. Alternative manual method: unpack OOXML as ZIP (unzip suspicious.docx -d extracted/), find the file word/_rels/document.xml.rels and check the attributes TargetMode="External" - Any external URL here is suspicious.
[Applicable to: DFIR-investigation of incidents on unstoppled Windows 10 legacy systems. On updated systems, the exploit does not work.]
