Overview

Spearphishing Attachment (T1566.001) is a targeted email-based attack where an adversary sends a crafted email to a specific individual, company, or industry with a malicious file attached — commonly an Office document, PDF, executable, or archive. The goal is to trick the recipient into opening the attachment, which either exploits a vulnerability or directly executes a payload, giving the attacker an initial foothold on the victim’s system.

This technique is one of the most common entry points in both targeted intrusions and widespread campaigns, used by threat actors ranging from nation-state groups to ransomware operators. Every security team needs reliable detection coverage here because a single successful click can be the difference between a contained phishing attempt and a full enterprise compromise.

Attacker Perspective

Attackers use spearphishing attachments to bypass perimeter defenses by exploiting the most reliable vulnerability in any environment — human trust.

• Macro-enabled Office documents: Adversaries send a .docm or .xlsm file with an embedded VBA macro that executes a payload on open; a common pattern is cmd.exe /c powershell -enc [base64] spawned from winword.exe or excel.exe.
• LNK files inside password-protected ZIPs: Groups like Emotet and QakBot deliver .zip archives with a .lnk shortcut that runs mshta.exe or wscript.exe against a remote HTA or JS payload, bypassing attachment scanning that cannot open encrypted archives.
• ISO/IMG disk images containing executables: Attackers package a disguised .exe inside an .iso file (e.g., Invoice_2024.iso containing Invoice.exe) to bypass Mark-of-the-Web propagation, since files inside a mounted ISO do not inherit the MOTW Zone.Identifier ADS that Office and Windows SmartScreen check.
• PDF with embedded link to staged payload: A PDF is sent containing a hyperlink or embedded JavaScript that redirects the user to download a second-stage payload (e.g., Cobalt Strike beacon, IcedID dropper), using tools like msfvenom or evilpdf to craft the lure document.

This technique is deeply attractive to attackers because it requires no pre-existing access, scales from highly targeted to broad campaigns, and is reliably effective against organizations that have not invested in user training and robust email security controls.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Process Creation (Event ID 4688): Enable via GPO Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation → Success. Also enable command-line logging via GPO: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Without command-line capture, process creation events are nearly useless for this technique.
• Sysmon (Windows) — Event IDs 1, 3, 7, 11, 15, 22, 23: Deploy Sysmon with a community config (e.g., SwiftOnSecurity or Olaf Hartong’s modular config). Event ID 1 captures process creation with full command line and hashes; Event ID 3 captures network connections with process context; Event ID 11 captures file creation; Event ID 15 captures file stream creation (MOTW/Zone.Identifier ADS writes); Event ID 22 captures DNS queries per process.
• PowerShell Script Block Logging (Event ID 4104): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Also enable Module Logging: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1. These events capture the full deobfuscated script content before execution.
• PowerShell Operational Log (Event ID 4103, 4105, 4106): Captured alongside 4104 when module logging is enabled. Provides pipeline execution detail that complements script block logging.
• Windows Security Log — File System Auditing (Event ID 4663): Enable object access auditing on high-risk directories (%TEMP%, %APPDATA%, C:\Users\Public) via SACL. Required to confirm payload drop locations.
• Email gateway logs (Proofpoint, Mimecast, Microsoft Defender for Office 365, or equivalent): Must log sender address, recipient, subject, attachment name, attachment hash (SHA256), delivery verdict, and click-through events. These are your ground truth for confirming the phishing vector.
• Endpoint Detection and Response (EDR) telemetry: Tools like Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne, or Carbon Black provide process trees, file writes, registry changes, and network connections with parent-child relationships that correlate everything above in a single timeline.
• DNS logs (Windows DNS Debug Logging or DNS Firewall/RPZ logs): Enable DNS debug logging on Windows DNS servers or collect from DNS security appliances (Cisco Umbrella, Infoblox, Palo Alto DNS Security). Required to catch beacon callback and C2 resolution patterns tied to the executing process.
• Linux — auditd rules: Add rules to /etc/audit/rules.d/audit.rules: -a always,exit -F arch=b64 -S execve -k exec_monitor and -w /tmp -p wxa -k tmp_access. Forward via auditbeat or rsyslog to your SIEM.
• macOS — Endpoint Security Framework / Unified Log: Use an EDR that leverages the Apple Endpoint Security Framework (ESF), or enable OpenBSM audit rules targeting execve and file operations. Without ESF-based telemetry, macOS detection coverage for this technique is severely limited.

Key Indicators

• Suspicious parent-child process relationships (Sysmon Event ID 1 / EDR process tree): Check parent_process_name for winword.exe, excel.exe, powerpnt.exe, outlook.exe, acrord32.exe, foxit reader.exe spawning any of: cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, certutil.exe, bitsadmin.exe, wmic.exe.
• Encoded or obfuscated PowerShell (Event ID 4104 / Sysmon Event ID 1): In command_line, look for: -enc or -EncodedCommand, -w hidden or -WindowStyle Hidden, IEX or Invoke-Expression, DownloadString, DownloadFile, Net.WebClient, or System.Reflection.Assembly::Load. Any combination of these in a child process of an Office application should be treated as high-confidence malicious.
• MOTW bypass — ISO/IMG mount followed by execution (Sysmon Event ID 11 + 1): Look for file_extension of .iso or .img written to disk in user-accessible paths, followed within minutes by process creation where current_directory contains a drive letter associated with a virtual drive mount (e.g., D:\ or E:\ when no physical drive is expected).
• File creation in suspicious locations (Sysmon Event ID 11 / audit Event ID 4663): Watch for executable files (file_extension in .exe, .dll, .bat, .ps1, .vbs, .js, .hta) written to %TEMP%, %APPDATA%, %LOCALAPPDATA%, C:\Users\Public, or C:\ProgramData by an Office or mail client process.
• Zone.Identifier ADS absent on executed file (Sysmon Event ID 15): Files delivered via ISO or other MOTW-bypass containers will have contents of Zone.Identifier either absent or set to ZoneId=0. A file executed from a recently mounted virtual drive with no MOTW or with ZoneId=0 is suspicious when the host recently received email.
• Network connection from Office application or script interpreter (Sysmon Event ID 3): Alert when process_name in (winword.exe, excel.exe, mshta.exe, wscript.exe, powershell.exe) establishes an outbound connection to a non-internal destination_ip, especially on ports 80, 443, 4444, 8080, or 8443.
• Certutil or BITS abuse for payload download (Sysmon Event ID 1 / Event ID 4688): In command_line, look for: certutil -urlcache -split -f http, certutil -decode, or bitsadmin /transfer initiated by any process whose parent_process_name is an Office app or email client.
• Email gateway — delivery of high-risk attachment types: In email gateway logs, check attachment_extension for .iso, .img, .lnk, .vbs, .js, .hta, .chm, .wsf, or .docm/.xlsm/.pptm (macro-enabled Office) delivered to internal recipients. Cross-reference with the recipient’s subsequent endpoint activity.

Detection Logic

Rule 1 — Broad: Office Application Spawning Shell or Script Interpreter
IF process_name IN ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe") AND parent_process_name IN ("winword.exe","excel.exe","powerpnt.exe","outlook.exe","acrord32.exe") THEN alert HIGH

This catches the most common post-attachment-open execution pattern: an Office app or PDF reader spawning a command interpreter. Expected alert volume is low-to-moderate in most environments; the most common false positives are IT-managed Office add-ins or macros used for legitimate automation — these should be baselined and excluded by process hash or specific command-line pattern rather than broadly by parent process.

Rule 2 — Medium: Encoded or Download-Cradle PowerShell Spawned Under Suspicious Parent
IF process_name = "powershell.exe" AND parent_process_name IN ("winword.exe","excel.exe","outlook.exe","wscript.exe","mshta.exe") AND command_line MATCHES ("-enc|-EncodedCommand|IEX|Invoke-Expression|DownloadString|DownloadFile|Net\.WebClient|WebRequest") THEN alert CRITICAL

This narrows Rule 1 to execution patterns that almost always indicate malicious intent. An Office application spawning encoded or download-cradle PowerShell is a near-definitive indicator of a malicious macro or script execution. Expected alert volume is very low; treat every hit as a confirmed incident until proven otherwise.

Rule 3 — Medium: Script Interpreter or Office App Making Outbound Network Connection
IF process_name IN ("winword.exe","excel.exe","powerpnt.exe","mshta.exe","wscript.exe","cscript.exe") AND event_type = "network_connection" AND destination_ip NOT IN (internal_subnets) AND destination_ip NOT IN (known_microsoft_update_ranges) THEN alert HIGH

This catches template injection, remote OLE object loading, and macro-initiated C2 beaconing where the Office process itself makes the network call rather than spawning a child. Alert volume depends on how well Microsoft update IPs are excluded; build an up-to-date allowlist from Microsoft’s published IP ranges and your proxy logs before deploying.

Rule 4 — Narrow/High-Precision: High-Risk Attachment Delivered Followed by Child Process on Same Host Within 30 Minutes
IF email_gateway_log: attachment_extension IN (".iso",".lnk",".docm",".xlsm",".hta",".vbs",".js") AND recipient_email = user_email AND WITHIN 30 MINUTES: endpoint_log: process_creation WHERE parent_process_name IN ("winword.exe","excel.exe","outlook.exe") AND host = user_workstation THEN alert CRITICAL

This correlation rule ties email delivery directly to execution on the recipient’s endpoint, dramatically reducing false positives and providing an automatic chain-of-evidence link between the phishing email and the post-execution behavior. It requires your SIEM to join email gateway logs and endpoint logs on a common user or host identifier — ensure your data model normalizes these fields. Expected volume is very low and precision is high.

Tuning Guidance

• Legitimate Office macros used by the business (e.g., finance team automation): These will trigger Rule 1. Identify the specific macro-enabled file hashes and the exact child process and command-line pattern they produce. Exclude by adding AND NOT (process_hash IN [approved_macro_hashes] AND command_line MATCHES [known_safe_pattern]) rather than excluding the entire parent process.
• PDF readers launching browser for hyperlinks: acrord32.exe or foxit.exe spawning iexplore.exe, chrome.exe, or msedge.exe is normal behavior when a user clicks a link in a PDF. Exclude by adding AND NOT process_name IN ("chrome.exe","msedge.exe","iexplore.exe","firefox.exe") to Rule 1, or scope the rule to only non-browser child processes.
• IT admin or developer activity with PowerShell: Administrators running encoded PowerShell for legitimate scripting will trigger Rule 2. Exclude by adding AND NOT user IN [privileged_admin_accounts] only after validating that those accounts are enrolled in PAM and their sessions are separately monitored — do not broadly exclude all admin users.
• Software deployment tools (SCCM, Tanium, PDQ Deploy): These tools frequently spawn powershell.exe, cmd.exe, and msiexec.exe as child processes. Identify the specific agent processes used in your environment and exclude by AND NOT parent_process_name IN ("ccmexec.exe","taniumclient.exe","pdqdeploy.exe").
• Outlook spawning Teams or browser for meeting links: outlook.exe launching teams.exe, chrome.exe, or msedge.exe when a user clicks a calendar invite link is normal. Exclude these specific child process names but leave all other Outlook child processes in scope.
• Security tooling with self-update mechanisms: Some EDR or AV products update via certutil.exe or PowerShell. Identify those exact command patterns and process hashes and add them to a dedicated exclusion list, documented and reviewed quarterly.

When the Alert Fires: Investigation Steps

1. Verify the alert is real and pull the raw event. Navigate directly to the source log in your SIEM (Sysmon Event ID 1, EDR process tree, or email gateway log) and confirm the raw event exists with the original field values — do not rely solely on the parsed SIEM alert, as normalization errors can introduce false data. Confirm the timestamp, hostname, username, and process details match exactly.
2. Identify the affected host and user, and flag privilege level. Query your identity directory (Active Directory, Azure AD, Okta) for the user account associated with the alert — note whether they are a member of privileged groups (Domain Admins, IT Admins, finance, HR, or executive staff), as these dramatically increase the severity of the incident. Record the hostname, IP address, OS version, and patch level from your asset inventory or CMDB.
3. Pull the full command-line and parent process chain. In your EDR or Sysmon logs, query for all process creation events on the affected host within 30 minutes of the alert, filtered by the initiating process’s PID and its parent PID — build the full process tree from the email client or Office application down to every child and grandchild process. Pay special attention to command_line fields for encoded strings, download cradles, or LOLBin usage (e.g., certutil, regsvr32, mshta).
4. Correlate with email gateway logs to confirm the phishing vector. Query your email gateway (Proofpoint, Mimecast, Microsoft Defender for Office 365) for emails delivered to the affected user in the 2 hours before the alert, filtering on attachment_present = true — record the sender address, sender domain, subject, attachment filename, and SHA256 hash. Submit the attachment hash to VirusTotal, MalwareBazaar, and your threat intelligence platform to check for known malicious associations.
5. Check for files written to disk and network connections made. Query Sysmon Event ID 11 (FileCreate) and Event ID 3 (NetworkConnect) for the affected host and the malicious process’s PID tree. Identify any dropped payloads in %TEMP%, %APPDATA%, or C:\Users\Public, and note any outbound connections — record destination IPs, domains, ports, and bytes transferred. Check those destination IPs and domains against your threat intelligence feeds and passive DNS to assess whether they are known C2 infrastructure.
6. Search for lateral movement from the affected host. In your SIEM, query Windows Security Event ID 4624 (logon) and 4648 (explicit credential use) for authentication events originating from the affected host’s IP to other internal systems in the 4 hours following the initial alert. Also check Sysmon Event ID 3 for SMB (port 445), WMI (port 135), or RDP (port 3389) outbound connections from the host — any successful remote logon from a compromised workstation should immediately escalate the incident severity.
7. Make the escalation decision based on confirmed evidence. Escalate to a confirmed incident if any of the following are true: a dropped payload was executed and made an outbound network connection; credentials were harvested or used for lateral movement; persistence mechanisms (scheduled tasks, registry run keys, new services) were identified in the process tree or file system; or the affected user is a privileged account. If the attachment was opened but no child process executed, no files were dropped, and no network connection was made, document as a near-miss phishing event and proceed with user notification and email gateway rule updates rather than full incident response.

Response Playbook

Containment

• Isolate the host immediately — but leave it powered on. Use your EDR’s network isolation feature (CrowdStrike “Contain Host,” Microsoft Defender for Endpoint “Isolate Device,” SentinelOne “Network Quarantine”) to cut off all network access while preserving the running process list, memory, and open file handles for forensics. Do not shut down or reimage the host until forensic triage is complete.
• Disable the affected user account. In Active Directory, use Disable-ADAccount -Identity [username] or disable via the AD Users and Computers console. In Azure AD, disable via the portal or with Set-AzureADUser -ObjectId [UPN] -AccountEnabled $false. If the account has associated service accounts or shared credentials, disable those as well pending review.
• Block identified C2 IPs and domains at the perimeter. Submit identified destination IPs and domains to your firewall team for immediate block at the egress firewall and DNS filtering layer (Cisco Umbrella, Infoblox, Palo Alto DNS Security). If you have a web proxy, add the domains to the block list there as well. Document every IOC blocked with timestamp and analyst name.
• Kill the malicious process if still running. If your EDR’s isolation does not terminate the process, use the EDR’s remote kill-process capability or connect via your out-of-band management channel to terminate the identified malicious PID. Do this only after capturing a memory dump of the process if your forensic process requires it.
• Revoke active sessions and tokens. If the user authenticates via Azure AD or Okta, revoke all active sessions immediately using Revoke-AzureADUserAllRefreshToken or the equivalent Okta admin action. If the user has active VPN sessions, terminate them via your VPN management console. If any OAuth tokens or API keys may have been exposed (e.g., stored in browser or credential manager), rotate those immediately.

Eradication

• Remove identified persistence mechanisms. Query the affected host (via EDR or remote PowerShell through your management channel) for scheduled tasks (Get-ScheduledTask), registry run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\Software\Microsoft\Windows\CurrentVersion\Run), new services (Get-Service), and startup folder entries. Remove any items not present in your known-good baseline and document each removal with the full registry path or task XML.
• Search for and delete all dropped payloads and tools. Based on the file paths identified during investigation, delete all malicious files from %TEMP%, %APPDATA%, C:\Users\Public, and any other identified drop locations. Run a hash-based scan across the enterprise using your EDR’s threat hunting capability to find the same file hashes on any other endpoints — this identifies lateral spread even if lateral movement was not confirmed in logs.
• Reset credentials for the affected account and any accounts it touched. Force a password reset for the affected user account and any accounts that were used or potentially accessed during the incident (e.g., accounts seen in Event ID 4648 explicit logon events from the compromised host). If the host had cached credentials for service accounts or other users (retrievable via Mimikatz-style tools), rotate all of those as well.
• Check lateral movement targets for additional backdoors. For every system the compromised host authenticated to during the incident window, run a targeted EDR sweep for the same IOCs (file hashes, persistence registry keys, scheduled task names, known C2 domains in DNS cache) — do not assume that because lateral movement was observed as a single hop, only one additional system is affected.
• Rotate any exposed secrets, API keys, or certificates. Check the affected user’s workstation for stored credentials in the Windows Credential Manager, browser password stores, and any developer tools (.aws\credentials, .ssh\ private keys, .git-credentials). Rotate every credential found, notify the relevant service owners, and review access logs for those services for signs of unauthorized use.

Recovery

• Verify the host is clean before reconnecting — reimage if in doubt. Run a full EDR scan and compare the current host state against your known-good image baseline. If you cannot achieve high confidence that all persistence mechanisms have been removed (e.g., the initial access was confirmed but the full scope of post-exploitation is unclear), reimage from a trusted gold image rather than attempting in-place cleanup — the cost of reimaging is always lower than the cost of a recurring breach.
• Re-enable the user account only after confirming clean state. Before re-enabling the account in AD or Azure AD, confirm with the investigating analyst that no persistence tied to that account remains, the password has been reset, and MFA has been re-enrolled or verified. Brief the user on what happened and what to watch for before restoring access.
• Monitor the previously affected host and user for 72 hours post-remediation. Create a temporary watchlist in your SIEM for the affected hostname and username, and set up enhanced alerting on all process creation, network connections, and authentication events from those entities for a minimum of 72 hours. Assign a specific analyst to review these alerts daily during the monitoring window.
• Document the full incident timeline and close with lessons learned. Write a complete incident report covering the initial phishing email details, timeline from delivery to detection, all affected systems, all actions taken, and all IOCs discovered. Distribute to relevant stakeholders and hold a brief post-incident review to identify what controls failed and what worked — specifically review whether email gateway rules, EDR policies, or user training gaps contributed to the success of the initial phishing attempt.
• Update detection rules with new IOCs and refine alert thresholds. Add any newly discovered C2 IPs, domains, file hashes, and malicious command-line patterns to your SIEM detection rules, threat intelligence platform, and email gateway block lists. Review whether any of the four detection rules above produced false negatives during this incident and adjust logic accordingly — treat every incident as an opportunity to close a detection gap.