AN1315: Analytic 1315
Cause→effect chain: (1) User app/browser/archiver logs an open/click or abnormal exit, (2) new executable/script/archive extracted into $HOME/Downloads, /tmp, or ~/.cache, (3) parent app spawns shell/interpreter (bash/sh/python/node/curl/wget) or desktop file, and (4) new outbound connection(s) from the child lineage.
Analyst context for executives and security teams
This analytic matters because it describes a high-risk Linux endpoint pattern: a user-facing application such as a browser or archiver is involved in an open/click or crash event, new code appears in common user-writable locations, that application lineage launches a shell or interpreter, and the resulting child process makes outbound network connections. For executives and security leaders, the decision value is whether the organization can reliably connect user activity, file creation, process lineage, and network egress into one investigation-ready story rather than treating each event as isolated noise.
Executive priority
Prioritize this as a coverage validation item for Linux workstations and user-facing Linux systems. It can inform managed detection requirements, incident response readiness, audit evidence for endpoint monitoring, and control prioritization around user-writable execution paths and outbound traffic visibility. Leadership should ask whether SOC teams can prove collection across the full cause-to-effect chain: application activity, extracted or newly created files, child process execution, and network connections from that lineage.
Technical view
For SOC, detection engineering, and IR teams, validate correlation on Linux between: user application or browser/archive activity; creation or extraction of executable, script, or archive content under $HOME/Downloads, /tmp, or ~/.cache; spawning of bash, sh, python, node, curl, wget, or desktop file execution from that parent lineage; and new outbound connections from the resulting child processes. Because ATT&CK provides no separate detection text and no tactic mapping for this analytic, treat the official description as the detection logic to test, tune, and document locally.
Likely telemetry
- Linux process creation events with parent-child lineage
- File creation or extraction events in $HOME/Downloads, /tmp, and ~/.cache
- Application, browser, or archiver logs showing open/click activity or abnormal exit
- Command-line telemetry for shells, interpreters, curl, wget, and desktop file execution
- Network connection telemetry tied to process or process lineage
Detection direction
- Validate that telemetry can join user application events, file writes, process lineage, and outbound connections on the same Linux host within a defensible time window.
- Tune for parent applications spawning shells, interpreters, download tools, or desktop file handlers after new content appears in user-writable paths.
- Review false positives from legitimate downloads, developer workflows, package extraction, browser helper processes, and administrative scripts.
- Identify blind spots where browser or archiver logs are unavailable, file creation lacks path detail, process telemetry loses parent lineage, or network telemetry cannot be tied back to a process.
- Use this analytic as a correlation test rather than a single-event alert, because the official description is explicitly a cause-to-effect chain.
Mitigation priorities
- Ensure Linux endpoint monitoring captures process lineage, file creation paths, and process-associated network connections.
- Limit unnecessary execution from user-writable locations where operationally feasible, especially Downloads, /tmp, and cache directories.
- Harden and monitor user-facing applications and archive handlers that can introduce files into those paths.
- Apply outbound network controls and logging so child-process egress can be reviewed during investigations.
- Document collection and correlation coverage as evidence for SOC readiness, incident response playbooks, and compliance monitoring expectations.
Analyst notes and limits
This is a MITRE ATT&CK detection analytic, not a technique entry. The supplied object has Linux as the only platform, no tactic assignment, no relationships, no aliases, and no official detection section beyond the description. The strongest use is as a practical validation scenario for whether Linux endpoint and network telemetry can preserve the full event chain.
No relationship context, threat actor linkage, active exploitation claim, impact statement, or explicit detection implementation is supplied. Local environment baselining is required to determine alert thresholds, acceptable parent-child process behavior, and which user-writable execution patterns are normal.
Analytic 1315
Cause→effect chain: (1) User app/browser/archiver logs an open/click or abnormal exit, (2) new executable/script/archive extracted into $HOME/Downloads, /tmp, or ~/.cache, (3) parent app spawns shell/interpreter (bash/sh/python/node/curl/wget) or desktop file, and (4) new outbound connection(s) from the child 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 | 9c9ca895d6d2… |
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 AN1315Open 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.