Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1196: Analytic 1196

Abuse of bind mounts to obscure process directories. Defender perspective: detecting anomalous mount operations where a process’s /proc entry is remapped to another directory, often hiding malicious activity from native utilities (ps, top). Behavior chain includes: (1) execution of `mount` with `-o bind` or `-B` flags, (2) modification of /proc entries inconsistent with expected process lineage, and (3) subsequent anomalous activity from processes whose metadata no longer matches execution context.

EnterpriseAN1196AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because it focuses on a Linux evasion pattern where bind mounts can make a process’s /proc entry appear inconsistent with what is actually running. For leaders, the practical issue is visibility: if native tools such as ps or top are misled, responders may underestimate what is active on a host unless they have stronger mount, process, and endpoint telemetry.

Executive priority

Prioritize this as a Linux host visibility and incident response readiness issue. It is most relevant where Linux systems support critical workloads, administrative access, containers, or sensitive services. Security leaders should ask whether SOC and IR teams can independently verify process identity, mount activity, and process lineage rather than relying only on standard command-line utilities during an investigation.

Technical view

Validate detection around anomalous Linux mount operations involving bind mounts and /proc paths. The supplied analytic describes a behavior chain: execution of mount with bind options, /proc entry changes inconsistent with expected process lineage, and later activity from processes whose metadata no longer matches execution context. SOC teams should test whether endpoint, audit, and system telemetry preserve enough detail to correlate mount command execution, mount table changes, process identifiers, parent/child relationships, and subsequent process behavior. No ATT&CK tactic mapping or relationship context was supplied, so detection engineering should treat this as a host-level Linux evasion/visibility analytic rather than infer broader campaign context.

Likely telemetry

  • Linux process execution telemetry for mount command invocations and command-line arguments
  • Audit or endpoint records of mount operations and mount table changes
  • /proc-related filesystem activity where available
  • Process lineage, PID, PPID, executable path, and command-line metadata
  • Subsequent process behavior from processes with inconsistent or unexpected metadata

Detection direction

  • Look for bind mount usage involving /proc entries, especially when process metadata no longer aligns with expected execution context.
  • Correlate mount activity with process lineage and later process behavior instead of alerting on bind mounts alone, because legitimate administrative or system workflows may also use bind mounts.
  • Validate whether native utility output can be bypassed or obscured in local triage procedures; responders should have alternate evidence sources.
  • Tune for Linux environments where bind mounts are common, such as administrative maintenance or containerized workloads, to reduce false positives.
  • Because no official detection logic is provided, build detections from observable behavior classes rather than assuming a specific query or tool coverage.

Mitigation priorities

  • Establish baseline visibility for Linux mount operations, process execution, and process lineage on systems where this risk matters.
  • Restrict privileged capabilities required to perform mount operations to authorized administrators, services, or tightly controlled automation.
  • Harden incident response procedures so investigators corroborate process state using multiple telemetry sources, not only native utilities that may be affected by /proc manipulation.
  • Review Linux administrative and container operational patterns to distinguish expected bind mount behavior from anomalous use.
  • Use detection validation exercises to confirm SOC alerting and IR collection can identify inconsistent process metadata after mount activity.
Analyst notes and limits

The supplied object is an ATT&CK detection analytic for Linux focused on abuse of bind mounts to obscure process directories. There are no supplied ATT&CK relationships, tactics, mitigations, groups, software, or data components, so this take is intentionally scoped to defensive validation of the described behavior.

Official detection content was not provided, and no relationship context was supplied. This summary does not assert active exploitation, attribution, impact, or guaranteed detectability. Local Linux architecture, container usage, audit policy, endpoint tooling, and administrative practices will determine practical coverage and tuning.

Official MITRE ATT&CK definition

Analytic 1196

Abuse of bind mounts to obscure process directories. Defender perspective: detecting anomalous mount operations where a process’s /proc entry is remapped to another directory, often hiding malicious activity from native utilities (ps, top). Behavior chain includes: (1) execution of `mount` with `-o bind` or `-B` flags, (2) modification of /proc entries inconsistent with expected process lineage, and (3) subsequent anomalous activity from processes whose metadata no longer matches execution context.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
8dbf1d696df4b609...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 8dbf1d696df4…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1196
    Open source URL
Source and licensing

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.