AN0656: Analytic 0656
Phishing attachments executed on Linux systems are detected by linking email logs to file creation in mail directories and subsequent suspicious process execution. Look for unexpected binaries or scripts spawned from user mail directories and anomalous outbound network activity.
Analyst context for executives and security teams
This analytic matters because Linux workstations or servers that handle email can become execution points for phishing attachments, not just Windows endpoints. The practical value is correlation: email evidence alone may show delivery, and endpoint evidence alone may show execution, but linking email logs, file creation in mail directories, suspicious child processes, and unusual outbound network activity helps defenders decide whether a user opened a malicious attachment and whether response escalation is needed.
Executive priority
Security leaders should treat this as a validation item for phishing resilience and Linux endpoint visibility. The key business question is whether the organization can prove, during an incident or audit, that it can connect email delivery to file creation, execution, and network activity on Linux systems. If Linux endpoints, mail clients, or server-side mail directories are under-monitored, phishing investigations may depend on incomplete evidence, slowing containment and increasing uncertainty.
Technical view
For SOC and detection engineering teams, the analytic is Linux-focused and depends on joining multiple evidence sources: email logs, file creation in user mail directories, process execution from those locations, and anomalous outbound network activity. Because no official detection logic is provided, teams should validate their own correlation rules against local mail storage paths, Linux audit or EDR process telemetry, file creation events, and network logs. Tactics are not specified in the supplied object, so implementation should stay tied to the described behavior rather than assuming a specific ATT&CK tactic mapping.
Likely telemetry
- Email gateway or mail server logs showing message delivery and attachment metadata
- Linux file creation events in user mail directories
- Linux process execution telemetry, including parent-child process context and executable/script paths
- Outbound network connection logs from the Linux host after attachment-related execution
- User and host identifiers needed to correlate email activity to endpoint activity
Detection direction
- Validate that mail directory paths used in the local Linux environment are covered; default or assumed paths may miss nonstandard clients or configurations.
- Correlate email delivery time, attachment-related file creation, and process execution from user mail directories rather than alerting on any one signal alone.
- Tune for unexpected binaries or scripts spawned from mail directories, while accounting for legitimate mail client helper processes and user workflows.
- Review outbound network activity following suspicious execution, but treat it as supporting context rather than a standalone confirmation.
- Document visibility gaps where email logs, file events, process telemetry, or network telemetry cannot be joined reliably.
Mitigation priorities
- Prioritize collection and retention of email, Linux endpoint, and network telemetry needed for phishing attachment investigations.
- Harden Linux endpoint execution controls and user mail handling where local policy supports it, especially around scripts or binaries launched from mail storage locations.
- Use phishing response playbooks that explicitly include Linux systems and define when correlated execution evidence triggers containment.
- Maintain asset and identity mapping so SOC teams can quickly connect mailbox activity to Linux host activity.
- Use detection validation exercises to confirm that attachment delivery, file creation, execution, and outbound activity are visible end to end.
Analyst notes and limits
This object is a detection analytic, not a technique or group profile. It provides a concise behavioral description for Linux phishing attachment execution but does not include official detection logic, tactics, labels, aliases, or relationship context. The strongest use is as a coverage validation prompt for SOC, IR, and detection engineering teams.
The supplied ATT&CK fields do not provide relationships, specific data sources, detailed detection pseudocode, mitigations, affected software, or evidence of active exploitation. Local environment details are required to determine mail directory locations, legitimate process behavior, telemetry availability, and tuning thresholds.
Analytic 0656
Phishing attachments executed on Linux systems are detected by linking email logs to file creation in mail directories and subsequent suspicious process execution. Look for unexpected binaries or scripts spawned from user mail directories and anomalous outbound network activity.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | f2d75b7489d0… |
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 AN0656Open 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.