T1204.002: Malicious File
An adversary may rely upon a user opening a malicious file in order to gain execution. Users may be subjected to social engineering to get them to open a file that will lead to code execution. This user action will typically be observed as follow-on behavior from Spearphishing Attachment. Adversaries may use several types of files that require a user to execute them, including .doc, .pdf, .xls, .rtf, .scr, .exe, .lnk, .pif, .cpl, .reg, and .iso.CitationMandiant Trojanized Windows 10
Adversaries may employ various forms of Masquerading and Obfuscated Files or Information to increase the likelihood that a user will open and successfully execute a malicious file. These methods may include using a familiar naming convention and/or password protecting the file and supplying instructions to a user on how to open it.CitationPassword Protected Word Docs
While Malicious File frequently occurs shortly after Initial Access it may occur at other phases of an intrusion, such as when an adversary places a file in a shared directory or on a user's desktop hoping that a user will click on it. This activity may also be seen shortly after Internal Spearphishing.
Security context for executives and security teams
Malicious File is the user-execution moment where a person opens a document, installer, shortcut, image/container, or executable that gives an adversary code execution on Linux, macOS, or Windows. Its business importance is that a control program can look strong on paper while still failing at the point where phishing, trusted file names, password-protected attachments, shared folders, or desktop-placed files persuade users to launch the payload.
Executive priority
Treat this as a resilience and audit-evidence issue, not only a phishing-awareness issue. Leaders should ask whether the organization can prove it collects endpoint and email/download evidence from file receipt through file open and child-process execution, and whether execution prevention and endpoint behavior controls are enforced consistently across major desktop/server platforms. Because ATT&CK links this behavior to many campaigns and groups, it is a common enough execution pattern to justify prioritized investment in user training, execution prevention, and endpoint behavior prevention.
Technical view
This is an execution sub-technique of User Execution for Linux, macOS, and Windows. ATT&CK does not provide native detection text for T1204.002, but the related detection strategy DET0294 points defenders toward a download/open-to-spawn-chain analytic. SOC and detection teams should validate visibility from initial file delivery or placement, to user open action, to process creation and suspicious child processes. Particular attention should be given to file types named by ATT&CK, including .doc, .pdf, .xls, .rtf, .scr, .exe, .lnk, .pif, .cpl, .reg, and .iso, and to files using masquerading, obfuscation, familiar naming, or password protection.
Likely telemetry
- Email security and attachment metadata, especially spearphishing attachment context where available
- Web/download telemetry showing file acquisition and source URL or referrer when collected
- Endpoint file creation, modification, quarantine, and reputation events
- Process creation telemetry showing the opened file’s handler and child-process chain
- Command-line, parent/child process, and script execution events
Detection direction
- Implement or validate analytics aligned to DET0294: user downloads or opens a file, then the associated application spawns unusual or risky child processes.
- Tune by file type and parent application so common business workflows do not overwhelm detections, but preserve scrutiny for Office, PDF, archive/container, shortcut, registry, control panel, screensaver, and executable launch patterns.
- Look for context from related ATT&CK behaviors: Spearphishing Attachment and Internal Spearphishing before execution, and Masquerading or Obfuscated Files or Information around the file itself.
- Test visibility for password-protected files and files with familiar or misleading names, because these may bypass content inspection or reduce user suspicion.
- Confirm coverage across Linux, macOS, and Windows where those platforms are in scope; do not assume Windows-focused controls cover the whole estate.
Mitigation priorities
- Prioritize M1038 Execution Prevention so unauthorized or untrusted code and risky file types cannot execute freely.
- Use M1040 Behavior Prevention on Endpoint to block or contain suspicious process behavior after a user opens a file.
- Maintain M1017 User Training focused on recognizing, reporting, and not opening suspicious or password-protected files, especially those delivered through phishing or placed in shared locations.
- Back mitigations with measurable evidence: blocked executions, user reports, attachment handling outcomes, and endpoint response actions.
- Review business exceptions regularly so allowlists, script permissions, and file-handler policies do not silently become the main bypass path.
Additional notes and limits
The relationship set shows this technique is used across numerous named campaigns and groups, including espionage, ransomware-related, and sector-targeting campaign descriptions. That breadth supports prioritizing defensive validation, but it should not be read as evidence of current activity against any specific organization. The strongest local assessment will come from testing whether a realistic malicious-file open produces correlated email/download, file, process, and endpoint-control telemetry.
Official ATT&CK detection guidance for this object is not provided, so detection recommendations are derived from the supplied description, platforms, tactics, mitigations, and the related DET0294 detection strategy. The supplied fields do not establish organization-specific exposure, active exploitation, or guaranteed control coverage. Local platform mix, endpoint tooling, email controls, file-sharing practices, and logging retention are required to assess actual risk.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Malicious File
An adversary may rely upon a user opening a malicious file in order to gain execution. Users may be subjected to social engineering to get them to open a file that will lead to code execution. This user action will typically be observed as follow-on behavior from Spearphishing Attachment. Adversaries may use several types of files that require a user to execute them, including .doc, .pdf, .xls, .rtf, .scr, .exe, .lnk, .pif, .cpl, .reg, and .iso.CitationMandiant Trojanized Windows 10
Adversaries may employ various forms of Masquerading and Obfuscated Files or Information to increase the likelihood that a user will open and successfully execute a malicious file. These methods may include using a familiar naming convention and/or password protecting the file and supplying instructions to a user on how to open it.CitationPassword Protected Word Docs
While Malicious File frequently occurs shortly after Initial Access it may occur at other phases of an intrusion, such as when an adversary places a file in a shared directory or on a user's desktop hoping that a user will click on it. This activity may also be seen shortly after Internal Spearphishing.
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.