AN1314: Analytic 1314
Cause→effect chain: (1) User-facing app (Office/PDF/archiver/browser) records an open/click or abnormal event, then (2) a downloaded file is created in a user-writable path and/or decompressed, (3) the parent user app spawns a living-off-the-land binary (e.g., powershell/cmd/mshta/rundll32/msiexec/wscript/expand/zip) or installer, and (4) immediate outbound HTTP(S)/DNS/SMB from the same lineage.
Analyst context for executives and security teams
This analytic describes a high-value Windows detection pattern for suspicious activity that starts with a user-facing application, such as an Office document, PDF reader, archive tool, or browser, and quickly turns into file creation, decompression, living-off-the-land process execution, and outbound network activity. For leaders, the practical value is that this chain can help distinguish routine user file handling from activity that may represent initial execution or follow-on staging, especially where attackers rely on trusted built-in tools rather than obvious malware.
Executive priority
Prioritize this as a validation point for endpoint and SOC readiness on Windows systems. The business question is whether the organization can connect user application activity, downloaded or extracted files, child process creation, and immediate outbound HTTP(S), DNS, or SMB activity into one investigation timeline. If those evidence sources are fragmented or missing, incident responders may struggle to determine whether a user click became a broader security event.
Technical view
SOC and detection engineering teams should validate correlation across the described cause-and-effect chain: a user-facing application records an open, click, or abnormal event; a file appears in a user-writable location or is decompressed; that same application lineage launches a living-off-the-land binary or installer such as powershell, cmd, mshta, rundll32, msiexec, wscript, expand, or zip; and the lineage then initiates outbound HTTP(S), DNS, or SMB. Because no ATT&CK tactic or relationship context is supplied, this should be treated as a detection analytic pattern rather than mapped to a specific adversary objective without local evidence.
Likely telemetry
- Windows endpoint process creation telemetry with parent-child lineage
- File creation events in user-writable paths
- Archive/decompression or file extraction events where available
- Application logs or endpoint events from Office, PDF readers, archive tools, and browsers indicating opens, clicks, or abnormal behavior
- Command-line telemetry for living-off-the-land binaries and installers
Detection direction
- Validate whether endpoint tooling preserves parent-child process lineage from user-facing applications through spawned binaries and network activity.
- Tune for chained behavior rather than single events, because browsers, document readers, archive utilities, installers, and Windows utilities can all be legitimate in isolation.
- Review false positives from software installation, helpdesk activity, document workflows, browser downloads, and archive extraction by normal users.
- Pay particular attention to execution from user-writable paths followed by immediate outbound network activity from the same process lineage.
- Confirm whether network telemetry can be joined back to the originating Windows process; without that join, the analytic may lose much of its decision value.
Mitigation priorities
- Ensure Windows endpoint logging and EDR policies capture process creation, command line, parent process, file creation, and network connection context.
- Reduce unnecessary execution paths from user-writable directories where operationally feasible.
- Review controls around script interpreters, installers, and living-off-the-land binaries that are commonly spawned by user-facing applications.
- Harden handling of downloaded files and archives, including user workflow controls and monitoring around decompression followed by execution.
- Use incident response playbooks that preserve the full user-click-to-network timeline for triage and containment decisions.
Analyst notes and limits
This is a detection analytic object for Windows with an official description but no official detection text and no supplied relationships. The most useful interpretation is as a correlation pattern for suspicious execution chains after user interaction, not as proof of compromise by itself.
The supplied ATT&CK fields do not specify tactics, techniques, adversary groups, campaigns, mitigations, or concrete detection logic. Local baselining is required to separate legitimate user-driven downloads, extraction, installation, and administrative activity from suspicious chains.
Analytic 1314
Cause→effect chain: (1) User-facing app (Office/PDF/archiver/browser) records an open/click or abnormal event, then (2) a downloaded file is created in a user-writable path and/or decompressed, (3) the parent user app spawns a living-off-the-land binary (e.g., powershell/cmd/mshta/rundll32/msiexec/wscript/expand/zip) or installer, and (4) immediate outbound HTTP(S)/DNS/SMB from the same lineage.
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 | d6969e82f9e7… |
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 AN1314Open 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.