T1566.001: Spearphishing Attachment
Adversaries may send spearphishing emails with a malicious attachment in an attempt to gain access to victim systems. Spearphishing attachment is a specific variant of spearphishing. Spearphishing attachment is different from other forms of spearphishing in that it employs the use of malware attached to an email. All forms of spearphishing are electronically delivered social engineering targeted at a specific individual, company, or industry. In this scenario, adversaries attach a file to the spearphishing email and usually rely upon User Execution to gain execution.CitationUnit 42 DarkHydrus July 2018 Spearphishing may also involve social engineering techniques, such as posing as a trusted source.
There are many options for the attachment such as Microsoft Office documents, executables, PDFs, or archived files. Upon opening the attachment (and potentially clicking past protections), the adversary's payload exploits a vulnerability or directly executes on the user's system. The text of the spearphishing email usually tries to give a plausible reason why the file should be opened, and may explain how to bypass system protections in order to do so. The email may also contain instructions on how to decrypt an attachment, such as a zip file password, in order to evade email boundary defenses. Adversaries frequently manipulate file extensions and icons in order to make attached executables appear to be document files, or files exploiting one application appear to be a file for a different one.
Security context for executives and security teams
Spearphishing Attachment matters because it is an initial-access path that turns a normal business workflow—opening emailed files—into a potential entry point on Windows, macOS, or Linux systems. The decision issue is not simply whether users receive phishing email; it is whether the organization can prevent, inspect, detonate, log, and respond when a targeted attachment reaches a user and relies on User Execution.
Executive priority
Treat this as a resilience and evidence question: can the organization prove that email controls, endpoint malware defenses, user reporting, account privilege limits, and incident response workflows work together before a malicious attachment becomes broader access? The ATT&CK relationships show this technique is used across multiple campaigns and groups, including espionage, ransomware-related, and critical-infrastructure-relevant campaign context, so leaders should prioritize coverage where business operations, regulated data, or safety-critical environments depend on ordinary email workflows.
Technical view
For SOC, detection engineering, and IR teams, validate the full chain from email delivery to endpoint execution. ATT&CK does not provide official detection text for this object, but the related DET0236 detection strategy indicates detection should be considered across OS platforms. Focus on attachments such as Office documents, executables, PDFs, and archives; user interaction; attempts to bypass protections; password-protected archives; misleading file extensions or icons; and endpoint execution or exploit behavior after opening. Tie email evidence to endpoint, account, network boundary, antimalware, and audit logs so analysts can distinguish blocked delivery, user-reported phishing, attachment detonation, and confirmed host execution.
Likely telemetry
- Email security gateway or mail platform logs showing sender, recipient, subject, attachment name/type/hash, delivery disposition, spoofing results, and quarantine actions
- Attachment analysis or sandbox results for Office documents, PDFs, executables, and archives, including password-protected archive handling where available
- Endpoint telemetry on Windows, macOS, and Linux for file creation, process execution, child processes launched from document/PDF/archive handlers, and security control prompts bypassed by users
- Antivirus/antimalware alerts, remediation records, and update status across endpoints
- Network intrusion prevention or boundary logs for malicious payload retrieval, callback attempts, or blocked traffic following attachment execution
Detection direction
- Do not measure coverage only at the email gateway; validate whether telemetry links delivered attachments to endpoint execution and account activity after user interaction.
- Tune for common attachment abuse patterns described by ATT&CK: Office documents, executables, PDFs, archives, password-protected attachments, deceptive extensions, and icons that make executables appear to be documents.
- Use relationship context from T1566 Phishing and User Execution to test whether alerts are correlated across initial access and execution rather than handled as isolated email events.
- Account for false positives from legitimate business attachments and encrypted archives by combining sender context, attachment properties, user behavior, endpoint execution, and antimalware results.
- Confirm DET0236 or equivalent detection logic is operational across Windows, macOS, and Linux where those platforms are in scope, and document gaps where endpoint visibility is absent.
Mitigation priorities
- Start with user training focused on recognizing, reporting, and avoiding social engineering that asks users to open files or bypass protections, aligning with M1017 User Training.
- Reduce blast radius with M1018 User Account Management by enforcing least privilege and appropriate account lifecycle controls so successful user execution does not automatically become high-value access.
- Harden software configuration under M1054 for applications that open common attachment types, especially settings that limit risky content execution and unsafe default behavior.
- Use M1049 Antivirus/Antimalware on endpoints and keep protections current so malicious payloads attached to email can be blocked or remediated after delivery.
- Apply M1021 Restrict Web-Based Content and M1031 Network Intrusion Prevention to limit follow-on downloads, unsafe web access, and malicious network traffic associated with payload execution.
Additional notes and limits
T1566.001 is a sub-technique of T1566 Phishing and replaces revoked T1193. The supplied relationships include multiple campaigns and groups using this behavior, which supports treating it as broadly relevant, but they do not prove current activity against any specific organization. External references include anti-spoofing/SPF material and detection research context, but the official ATT&CK detection field for this object is not provided.
This take is limited to the supplied ATT&CK STIX fields, references, and relationships. It does not assert active exploitation, specific adversary targeting, customer exposure, or guaranteed detection. Local mail architecture, endpoint logging, attachment handling, user privileges, and response procedures are required to determine actual risk and coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Spearphishing Attachment
Adversaries may send spearphishing emails with a malicious attachment in an attempt to gain access to victim systems. Spearphishing attachment is a specific variant of spearphishing. Spearphishing attachment is different from other forms of spearphishing in that it employs the use of malware attached to an email. All forms of spearphishing are electronically delivered social engineering targeted at a specific individual, company, or industry. In this scenario, adversaries attach a file to the spearphishing email and usually rely upon User Execution to gain execution.CitationUnit 42 DarkHydrus July 2018 Spearphishing may also involve social engineering techniques, such as posing as a trusted source.
There are many options for the attachment such as Microsoft Office documents, executables, PDFs, or archived files. Upon opening the attachment (and potentially clicking past protections), the adversary's payload exploits a vulnerability or directly executes on the user's system. The text of the spearphishing email usually tries to give a plausible reason why the file should be opened, and may explain how to bypass system protections in order to do so. The email may also contain instructions on how to decrypt an attachment, such as a zip file password, in order to evade email boundary defenses. Adversaries frequently manipulate file extensions and icons in order to make attached executables appear to be document files, or files exploiting one application appear to be a file for a different one.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.
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.
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.