AN0839: Analytic 0839
Monitor for in-process mmap + mprotect + execve/execveat activity where memory permissions are changed from writable to executable inside the same process without a corresponding ELF on disk.
Analyst context for executives and security teams
This analytic matters because it focuses on a Linux behavior pattern often associated with fileless or memory-resident execution: a process creates or maps memory, changes it from writable to executable, and then invokes execve or execveat without a matching ELF file on disk. For leaders, the decision value is whether Linux monitoring can see execution that may not leave normal file-based evidence.
Executive priority
Prioritize this as a control-validation item for Linux systems where uptime, sensitive workloads, or audit evidence depend on detecting execution that bypasses traditional file inspection. Security leaders should ask whether SOC and incident response teams can prove visibility into memory permission changes and process execution, not just files written to disk. Because ATT&CK provides no tactic or relationship context for this object, use it as a detection-engineering requirement rather than as evidence of a specific adversary campaign.
Technical view
Validate Linux telemetry that can correlate mmap, mprotect, and execve or execveat activity within the same process. The key analytic condition is memory permissions changing from writable to executable, followed by execution activity, without a corresponding ELF on disk. SOC teams should test whether event collection preserves process identity, timing, memory permission transitions, command/process metadata, and file-backed versus anonymous mapping context. Since no official detection logic is provided, local implementation will need careful tuning and baselining.
Likely telemetry
- Linux syscall telemetry for mmap, mprotect, execve, and execveat
- Process creation and parent/child process metadata
- Memory mapping and memory permission-change events
- File metadata showing whether an executed image corresponds to an ELF on disk
- Endpoint detection or audit logs capable of correlating events within the same process
Detection direction
- Correlate mmap and mprotect events where memory transitions from writable to executable within the same process, then associate nearby execve or execveat activity.
- Validate whether telemetry distinguishes file-backed mappings from anonymous or non-file-backed memory.
- Tune for legitimate software behaviors that may generate writable-to-executable transitions, such as runtimes, interpreters, JIT engines, or security tooling.
- Confirm that collection is enabled on relevant Linux systems and that high-volume syscall data is retained long enough for investigation.
- Because no ATT&CK relationships or tactic are supplied, avoid over-classifying alerts; treat matches as suspicious execution behavior requiring contextual triage.
Mitigation priorities
- First, confirm Linux endpoint visibility for the required syscall and process events before relying on this analytic.
- Baseline legitimate writable-to-executable memory behavior on critical Linux workloads to reduce false positives.
- Use least privilege, application control, and hardening controls where appropriate to limit unauthorized execution paths, while recognizing this object itself does not provide a specific mitigation.
- Ensure incident response playbooks include collection of process, memory, and file-system evidence when execution lacks a corresponding ELF on disk.
- Document telemetry coverage and alert-handling procedures as compliance or audit evidence where Linux execution monitoring is in scope.
Analyst notes and limits
This Glexia take is based only on ATT&CK analytic AN0839. The object is a detection analytic for Linux and describes monitoring in-process mmap, mprotect, and execve/execveat behavior with writable-to-executable memory changes and no corresponding ELF on disk. No official detection logic, tactics, aliases, labels, or relationship context were supplied.
The supplied ATT&CK fields do not identify related techniques, adversaries, software, campaigns, or mitigations. They also do not provide a complete detection query, data-source requirements, or false-positive guidance. Local Linux telemetry quality, workload behavior, and retention will determine whether this analytic is practical and reliable.
Analytic 0839
Monitor for in-process mmap + mprotect + execve/execveat activity where memory permissions are changed from writable to executable inside the same process without a corresponding ELF on 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 | 5747c6d8f6eb… |
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 AN0839Open 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.