AN0067: Analytic 0067
Correlates ELF file execution with high-entropy writable memory segments and self-modifying code patterns.
Analyst context for executives and security teams
AN0067 is a Linux-focused detection analytic for suspicious ELF execution where the process shows high-entropy writable memory and self-modifying code patterns. For leaders, the value is not a single alert name; it is a way to test whether endpoint and runtime telemetry can see malware-like memory behavior that may not be obvious from command lines or file hashes alone.
Executive priority
Prioritize this analytic where Linux systems support critical services, production workloads, or regulated business processes. It helps answer whether the organization can detect suspicious runtime behavior after an ELF binary runs, which is relevant to SOC readiness, incident response triage, and evidence of control coverage. Because ATT&CK provides no tactic mapping or official detection logic here, leadership should treat it as a validation target rather than proof of existing coverage.
Technical view
SOC and detection engineering teams should validate whether Linux telemetry can correlate ELF execution with memory characteristics such as writable high-entropy regions and self-modifying code indicators. The practical focus is correlation quality: tying process execution evidence to runtime memory observations without relying only on static file reputation. Since no official detection implementation is supplied, teams need local engineering, baselining, and tuning before operational use.
Likely telemetry
- Linux process execution events for ELF binaries
- Endpoint or runtime memory telemetry showing writable memory segments
- Signals or traces indicating high-entropy memory regions
- Evidence of self-modifying code behavior
- Process metadata needed for correlation, such as path, user, parent process, host, and timestamps
Detection direction
- Confirm that telemetry exists for both ELF execution and runtime memory behavior; many environments collect process starts but not memory-segment characteristics.
- Correlate memory indicators to the executing process and host to avoid orphaned low-context alerts.
- Baseline legitimate Linux software that may use just-in-time compilation, packing, compression, or dynamic code generation to reduce false positives.
- Treat this as a behavior-focused analytic requiring local thresholds for entropy and writable memory observations.
- Because no tactic or relationship context is supplied, do not assume intent; use surrounding host, process, and user activity for triage.
Mitigation priorities
- Inventory Linux systems where this visibility is required, especially critical servers and workloads.
- Ensure endpoint/runtime monitoring can capture process execution and memory behavior at sufficient fidelity.
- Harden alert triage workflows so memory-behavior alerts include process lineage, user context, host role, and file metadata.
- Use baselining to separate expected dynamic code behavior from unusual execution patterns.
- Document coverage gaps for compliance and risk discussions where memory telemetry is unavailable.
Analyst notes and limits
This object is a detection analytic, not an ATT&CK technique. The supplied description is narrow and useful: ELF execution correlated with high-entropy writable memory and self-modifying code patterns on Linux. No relationships, tactic mappings, aliases, labels, or official detection text were provided, so analysis should remain centered on visibility validation and correlation engineering.
ATT&CK supplied no official detection logic, no relationship context, and no tactic mapping for this object. This take cannot determine adversary intent, prevalence, impact, or actual customer coverage. Local telemetry, endpoint capabilities, and baseline behavior are required before this analytic can be operationalized.
Analytic 0067
Correlates ELF file execution with high-entropy writable memory segments and self-modifying code patterns.
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 | dd65e051663f… |
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 AN0067Open 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.