T1564.013: Bind Mounts
Adversaries may abuse bind mounts on file structures to hide their activity and artifacts from native utilities. A bind mount maps a directory or file from one location on the filesystem to another, similar to a shortcut on Windows. It’s commonly used to provide access to specific files or directories across different environments, such as inside containers or chroot environments, and requires sudo access.
Adversaries may use bind mounts to map either an empty directory or a benign `/proc` directory to a malicious process’s `/proc` directory. Using the commands `mount –o bind /proc/benign-process /proc/malicious-process` (or `mount –B`), the malicious process's `/proc` directory is overlayed with the contents of a benign process's `/proc` directory. When system utilities query process activity, such as `ps` and `top`, the kernel follows the bind mount and presents the benign directory’s contents instead of the malicious process's actual `/proc` directory. As a result, these utilities display information that appears to come from the benign process, effectively hiding the malicious process's metadata, executable, or other artifacts from detection.[1][2]
Analyst context for executives and security teams
Bind Mounts matter because a Linux host can be made to show defenders a false view of process activity. If an adversary with sudo-level access overlays a malicious process’s /proc data with benign-looking content, common tools such as ps and top may not show the real metadata. For leaders, the risk is not just malware hiding; it is loss of confidence in routine host triage during an incident.
Executive priority
Prioritize this as a Linux incident-readiness and privileged-access concern. The technique depends on abusing legitimate filesystem behavior, so coverage is decided by whether teams collect trustworthy mount and process evidence beyond what interactive utilities display. It is especially relevant to environments using containers or chroot-like patterns, where bind mounts may be normal and therefore need governance, baselining, and audit evidence. The relationship to Hide Artifacts and to KV Botnet Activity makes it material for resilience planning, but local exposure depends on Linux estate, sudo control, and telemetry maturity.
Technical view
Validate whether SOC and IR procedures can identify unexpected bind mounts involving /proc and reconcile process views across multiple evidence sources. Because official ATT&CK detection text is not provided for this technique, detection engineering should use the related DET0428 strategy as a pointer and test local Linux telemetry rather than relying on ps/top output alone. Analysts should look for suspicious mount operations, altered /proc visibility, mismatches between process inventory sources, and privileged execution context around mount changes. Container and chroot environments require careful tuning because bind mounts can be legitimate there.
Likely telemetry
- Linux mount activity and mount table state, including bind mount options
- /proc mount and namespace information
- Privileged command execution and sudo activity
- Process inventory from sources other than ps/top alone
- Kernel, audit, or endpoint telemetry showing mount-related system activity
Detection direction
- Baseline legitimate bind mount usage, especially in containerized or chroot environments, before alerting broadly.
- Alert or investigate bind mounts that overlay /proc paths or cause process metadata inconsistencies.
- Correlate mount changes with sudo/root execution, new or suspicious processes, and endpoint detections.
- During IR, verify process state using multiple collection methods because native utilities may present benign-looking data.
- Tune for administrative and container-management false positives rather than suppressing all bind-mount activity.
Mitigation priorities
- Enforce least privilege for sudo/root capabilities that can modify mounts.
- Maintain governance over Linux container and chroot mount configurations.
- Ensure incident response playbooks include checks for hidden artifacts and manipulated /proc views.
- Collect and retain mount, privileged execution, and process telemetry suitable for post-incident reconstruction.
- Use vulnerability and asset prioritization to identify Linux systems where privileged compromise would undermine monitoring confidence.
Analyst notes and limits
This is a Linux sub-technique under Hide Artifacts. The official description explains abuse of bind mounts to conceal malicious process metadata from native utilities, and external references include Linux SSH server coinminer and Docker-targeting malware reporting. ATT&CK also relates the technique to DET0428 and KV Botnet Activity. Treat these as context, not proof of current activity in any specific environment.
Official detection guidance was not supplied in the ATT&CK object. The object supports Linux only; do not generalize to other platforms without separate evidence. Practical detection quality depends on local logging, container usage, sudo policy, and whether responders can collect evidence outside normal userland process views.
Bind Mounts
Adversaries may abuse bind mounts on file structures to hide their activity and artifacts from native utilities. A bind mount maps a directory or file from one location on the filesystem to another, similar to a shortcut on Windows. It’s commonly used to provide access to specific files or directories across different environments, such as inside containers or chroot environments, and requires sudo access.
Adversaries may use bind mounts to map either an empty directory or a benign `/proc` directory to a malicious process’s `/proc` directory. Using the commands `mount –o bind /proc/benign-process /proc/malicious-process` (or `mount –B`), the malicious process's `/proc` directory is overlayed with the contents of a benign process's `/proc` directory. When system utilities query process activity, such as `ps` and `top`, the kernel follows the bind mount and presents the benign directory’s contents instead of the malicious process's actual `/proc` directory. As a result, these utilities display information that appears to come from the benign process, effectively hiding the malicious process's metadata, executable, or other artifacts from detection.[1][2]
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.
Related techniques
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 | Hide Artifacts | This object subtechnique of Hide Artifacts. |
Groups, software, and campaigns
C0035: KV Botnet Activity
KV Botnet Activity consisted of exploitation of primarily “end-of-life” small office-home office (SOHO) equipment from manufacturers such as Cisco, NETGEAR, and DrayTek. KV Botnet Activity was used by Volt Typhoon to obfuscate connectivity to victims in multiple critical infrastructure segments, including energy and telecommunication companies and entities based on the US territory of Guam. While the KV Botnet is the most prominent element of this campaign, it overlaps with another botnet cluster referred to as the JDY cluster.[1] This botnet was disrupted by US law enforcement entities in early 2024 after periods of activity from October 2022 through January 2024.[2]
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 | 2.0 | Current bundle | 711f21988e92… |
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]
Cado Security Commando Cat 2024
Nate Bill & Matt Muir. (2024, February 1). The Nine Lives of Commando Cat: Analysing a Novel Malware Campaign Targeting Docker. Retrieved April 4, 2025.
Open source URL -
[2]
Ahn Lab CoinMiner 2023
Ahn Lab. (2023, April 24). CoinMiner (KONO DIO DA) Distributed to Linux SSH Servers. Retrieved April 4, 2025.
Open source URL -
[3]
mitre-attack T1564.013Open 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.