AN0974: Analytic 0974
Detects usage of shared memory directories (/dev/shm, /run/shm) for temporary storage of obfuscated, encoded, or executable data without persistence to disk.
Analyst context for executives and security teams
This analytic matters because it focuses on a Linux blind spot: activity staged in shared memory locations such as /dev/shm and /run/shm, where data may be temporary and may not leave durable files on disk. For leaders, the practical issue is whether SOC and incident response teams can see short-lived executable, encoded, or obfuscated content in memory-backed directories before evidence disappears.
Executive priority
Prioritize this as a visibility and response-readiness question for Linux estates. It can affect business resilience because temporary storage in shared memory may reduce the usefulness of traditional file-based monitoring and post-incident forensic evidence. Security leaders should ask whether Linux endpoint telemetry, logging retention, and IR procedures can capture short-lived activity in these paths, and whether audit evidence shows those controls are operating.
Technical view
Validate monitoring on Linux systems for creation, modification, execution, or deletion activity involving /dev/shm and /run/shm, especially where content appears executable, encoded, or obfuscated and does not persist to disk. Because the ATT&CK object provides no official detection logic, teams should treat AN0974 as a coverage objective rather than a ready-to-run rule. Detection engineering should define local baselines for legitimate shared-memory use before alerting on suspicious patterns.
Likely telemetry
- Linux file creation, modification, execution, and deletion events for /dev/shm and /run/shm
- Process execution telemetry with command line, parent process, user, working directory, and executable path
- File metadata for temporary objects, including permissions, ownership, size, timestamps, and executable bits
- Endpoint detection or audit telemetry capable of observing short-lived files or memory-backed filesystem activity
- Incident response collection that preserves volatile or short-lived artifacts when available
Detection direction
- Confirm whether current Linux telemetry covers /dev/shm and /run/shm; many file monitoring approaches may miss short-lived activity.
- Tune detections around executable or script-like content, unusual permissions, encoded or obfuscated data indicators, and rapid create-execute-delete sequences in shared memory directories.
- Baseline legitimate use of shared memory directories by applications and services to reduce false positives.
- Correlate file activity with process lineage and user context rather than relying only on path matching.
- Document gaps where telemetry is absent, delayed, or unable to capture non-persistent artifacts.
Mitigation priorities
- Improve Linux endpoint visibility for shared memory directories before relying on alerting outcomes.
- Restrict unnecessary execution from temporary or memory-backed locations where operationally feasible and validated.
- Apply least privilege and service hardening so routine users and services have only the access they require.
- Ensure IR playbooks include rapid collection of volatile and short-lived Linux artifacts.
- Use compliance and readiness reviews to verify that logging, retention, and response procedures cover this class of temporary activity.
Analyst notes and limits
AN0974 is a detection analytic for Linux shared memory directory usage involving temporary obfuscated, encoded, or executable data. No ATT&CK tactics, relationships, aliases, labels, or official detection logic were supplied, so this take frames the object as a defensive validation target rather than a complete detection rule.
The source fields do not provide specific detection logic, data sources, false-positive examples, related techniques, threat groups, software, or mitigations. Local environment telemetry and baselining are required to determine practical coverage and alert quality.
Analytic 0974
Detects usage of shared memory directories (/dev/shm, /run/shm) for temporary storage of obfuscated, encoded, or executable data without persistence to disk.
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 | f7d2ee93d82a… |
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 AN0974Open 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.