DET0428: Detection Strategy for Bind Mounts on Linux
DET0428 is a MITRE detection strategy for the Linux technique Bind Mounts (T1564.013), where bind mounts may be abused to conceal files, directories, or ac...
Analyst context for executives and security teams
DET0428 is a MITRE detection strategy for the Linux technique Bind Mounts (T1564.013), where bind mounts may be abused to conceal files, directories, or activity from normal native utilities. The practical issue for leaders is not the mount feature itself—it is legitimate and common in Linux, container, and chroot contexts—but whether defenders can tell the difference between expected privileged filesystem mapping and stealthy manipulation.
Executive priority
Prioritize this as a Linux visibility and privileged-access assurance question. Because the related technique requires sudo access and is associated with stealth, executives and security leaders should ask whether privileged Linux actions are monitored, whether container/chroot-heavy environments have mount visibility, and whether incident responders can prove what was actually mounted during a suspected compromise. This also supports audit and compliance evidence around privileged activity logging and change accountability.
Technical view
For SOC, detection engineering, and IR teams, validate coverage around Linux bind mount creation and changes, especially when performed by privileged users or processes outside expected administrative, container, or chroot workflows. Since the ATT&CK detection strategy object does not provide official detection logic, teams should derive local analytics from the related T1564.013 behavior: bind mounts can map files or directories, including empty or benign-looking locations, in ways that may hide artifacts from common file listing or inspection tools. Detection should be tuned against known legitimate mount activity to avoid noisy alerting.
Likely telemetry
- Linux mount table and mount namespace evidence, such as current and historical mount state where available
- Process execution telemetry for privileged mount-related commands and utilities
- Sudo, privilege escalation, and authentication logs tied to mount activity
- Linux audit or endpoint telemetry showing filesystem mount operations and related process lineage
- Container, chroot, or workload orchestration logs where bind mounts are expected administrative behavior
Detection direction
- Baseline legitimate bind mount activity for Linux servers, containers, and chroot environments before alerting on all bind mounts.
- Look for new or unusual bind mounts initiated by privileged users, unexpected service accounts, or processes with suspicious lineage.
- Correlate mount activity with sudo/authentication events to confirm whether privileged access was expected and approved.
- During IR, compare apparent filesystem contents with mount state so hidden artifacts are not missed by native utilities alone.
- Treat container and chroot environments carefully: bind mounts are common there, so context is essential to reduce false positives.
Mitigation priorities
- Restrict and review sudo privileges related to filesystem and mount administration.
- Require accountability for privileged Linux administration through logging, approval, and periodic access review.
- Ensure endpoint or audit tooling captures mount operations and privileged process lineage on relevant Linux systems.
- Document expected bind mount patterns for containerized, chroot, and administrative workflows so deviations are detectable.
- Include mount-state review in Linux incident response playbooks, especially for suspected stealth or artifact-hiding activity.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy record with no official description, platforms, tactics, or detection text. The usable context comes from its relationship to T1564.013 Bind Mounts, which is an enterprise Linux stealth technique. Glexia’s take therefore focuses on validation questions, telemetry classes, and control priorities rather than a specific analytic rule.
No active exploitation, attribution, prevalence, vendor coverage, or guaranteed detection can be inferred from the supplied fields. Local Linux architecture, container usage, sudo policy, audit configuration, and EDR coverage are required to determine actual risk and detection maturity.
Detection Strategy for Bind Mounts on Linux
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1564.013 | Bind Mounts Sub-technique | This object detects Bind Mounts. |
All related ATT&CK context
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 | 1de7172c789d… |
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 DET0428Open 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.