DET0781: Detection of Spearphishing Attachment
DET0781 is an ATT&CK for ICS detection strategy for identifying spearphishing attachments. Its practical value is that phishing attachments can be an initi...
Analyst context for executives and security teams
DET0781 is an ATT&CK for ICS detection strategy for identifying spearphishing attachments. Its practical value is that phishing attachments can be an initial path into organizations that operate industrial environments, where a compromised business user, engineering workstation user, or vendor-facing account could become part of a broader incident. Because the ATT&CK object provides no official detection text or platform scope, teams should treat it as a prompt to validate their own email, endpoint, identity, and incident-response evidence rather than as a complete detection recipe.
Executive priority
Security leaders should use this object to ask whether phishing attachment defenses are provable with evidence, not just policy. Priority questions include: are targeted attachment threats monitored before and after delivery; can the SOC trace a suspicious attachment from email receipt to user execution and endpoint activity; and can incident responders quickly determine whether an ICS-adjacent user or system was affected. This matters for operational resilience, audit readiness, and incident decision-making in environments where enterprise IT compromise may create risk to industrial operations.
Technical view
The supplied relationship says DET0781 detects the ICS ATT&CK technique T0865, Spearphishing Attachment. Since no official detection logic, platforms, or tactics are provided, SOC and detection engineering teams should validate coverage around the observable chain implied by the related technique: targeted email delivery with an attachment, user interaction or execution, and any resulting host or identity activity. Detection should be built and tested using local telemetry and business context, especially for personnel, vendors, or workflows connected to industrial operations.
Likely telemetry
- Email security gateway or mail platform logs for inbound messages, attachment metadata, sender/recipient details, and delivery disposition
- Attachment analysis or sandbox results where available
- Endpoint telemetry showing file creation, opening, process execution, script or document child processes, and quarantine events
- Identity and authentication logs for the targeted recipient after suspicious email interaction
- EDR/AV alerts related to attachment malware or suspicious document behavior
Detection direction
- Confirm that detections can correlate email attachment delivery with endpoint execution or attempted execution by the recipient.
- Tune for targeted recipients or business units with industrial operations relevance, while avoiding assumptions that every attachment is malicious.
- Validate visibility for attachments that bypass gateway controls, are delivered through allowed file types, or are opened on unmanaged or poorly monitored systems.
- Review false positives from normal business document exchange, vendor communications, invoices, engineering files, and maintenance workflows.
- Use the related T0865 context to prioritize triage when a suspicious attachment targets personnel or processes connected to ICS operations.
Mitigation priorities
- Prioritize layered email attachment controls, including filtering, malware scanning, and safe handling of suspicious files.
- Harden endpoints used by high-risk users with anti-malware, EDR, least privilege, and application or script execution controls where appropriate.
- Train users in targeted roles to report suspicious attachments, especially where vendor, maintenance, or operational communications are common.
- Ensure incident response playbooks can rapidly preserve email, endpoint, and identity evidence for suspected spearphishing attachment cases.
- Regularly test whether SOC workflows can trace a suspicious attachment from receipt through user action and host impact.
Analyst notes and limits
The ATT&CK object is a detection strategy in the ICS domain and is linked to T0865 Spearphishing Attachment. The object itself does not include an official description, detection procedure, platforms, or tactics, so this take focuses on defensible validation questions and telemetry classes implied by the relationship rather than specific detection logic.
Coverage cannot be assessed from this ATT&CK object alone. Local mail architecture, endpoint visibility, identity logging, user populations, industrial connectivity, and incident response procedures determine whether the organization can detect or investigate this behavior. No active exploitation, actor attribution, platform scope, or guaranteed detection is supported by the supplied fields.
Detection of Spearphishing Attachment
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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 |
|---|---|---|---|
| ICS | T0865 | Spearphishing Attachment | This object detects Spearphishing Attachment. |
All related ATT&CK context
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 | 1.0 | Current bundle | 6376bbd2b084… |
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]
mitre-attack DET0781Open 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.