AN0140: Analytic 0140
Adversaries writing or moving payloads into directories configured as AV/EDR exclusion paths (e.g., /tmp, /var/lib, or custom directories from auditd exclusion rules). Defender perspective: detect file creation in paths matching known exclusions correlated with unusual parent processes.
Analyst context for executives and security teams
This analytic matters because Linux payloads placed in antivirus or EDR exclusion paths may avoid expected inspection and delay incident response. For leaders, the key issue is not just whether exclusions exist, but whether the organization can prove that file creation in those excluded locations is monitored and investigated when the parent process looks unusual.
Executive priority
Treat AV/EDR exclusions as a governed risk area. Security leaders should ask who approves Linux exclusion paths, whether those paths are periodically reviewed, and whether SOC teams receive usable evidence when new files appear there. This supports resilience, audit readiness, and incident decision-making because exclusions can create blind spots in otherwise well-funded endpoint programs.
Technical view
For Linux environments, validate monitoring for file creation or movement into known AV/EDR exclusion directories such as /tmp, /var/lib, or locally defined custom paths, including exclusions derived from auditd rules where applicable. The analytic direction is to correlate writes into excluded paths with unusual parent processes. Because no ATT&CK tactic or formal detection logic is supplied, teams should translate this into local detection content using their own exclusion inventory, process baselines, and endpoint/file telemetry.
Likely telemetry
- Linux file creation and file movement events
- Process execution telemetry with parent-child process context
- Known AV/EDR exclusion path configuration
- auditd rules or audit configuration relevant to excluded paths
- Endpoint security logs showing path exclusions or scanning bypass policy
Detection direction
- Build or validate an inventory of Linux AV/EDR exclusion paths before writing detection logic; without that inventory, coverage will be incomplete.
- Alert on file creation in known excluded directories when the parent process is uncommon, unexpected for the host role, or inconsistent with normal administrative activity.
- Tune for legitimate software installers, package managers, temporary-file usage, and approved operational scripts to reduce false positives.
- Check whether paths such as /tmp and /var/lib are too broad for high-confidence alerting and require process, user, host role, or timing context.
- Confirm that telemetry is still collected for excluded paths even if prevention or scanning is bypassed.
Mitigation priorities
- Review and minimize Linux AV/EDR exclusion paths, especially broad or writable directories.
- Require documented approval and ownership for custom exclusions.
- Ensure endpoint and audit logging continue to capture file and process activity in excluded locations.
- Use change control to detect new or modified exclusions.
- Periodically test whether SOC detections trigger on suspicious file creation in approved exclusion paths.
Analyst notes and limits
This object is a detection analytic, not a technique, and provides a defender-oriented behavior: payloads written or moved into Linux directories configured as AV/EDR exclusions. There are no supplied relationships, aliases, labels, tactics, or procedure examples, so the take focuses on control validation and telemetry readiness rather than attribution or campaign context.
Official detection content is not provided, and no relationship context is supplied. The specific exclusion paths, parent-process baselines, and logging sources must be determined from the local Linux environment. This summary does not assert active exploitation or existing detection coverage.
Analytic 0140
Adversaries writing or moving payloads into directories configured as AV/EDR exclusion paths (e.g., /tmp, /var/lib, or custom directories from auditd exclusion rules). Defender perspective: detect file creation in paths matching known exclusions correlated with unusual parent processes.
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 | 655a01bc4a11… |
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 AN0140Open 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.