AN0612: Analytic 0612
Detection of container escape attempts via bind mounts, privileged containers, or abuse of docker.sock. Defenders may observe anomalous volume mount configurations (e.g., hostPath to / or /proc), unexpected privileged container launches, or use of container administration commands to access host resources. These events typically correlate with subsequent process execution on the host outside of normal container isolation.
Analyst context for executives and security teams
AN0612 focuses on signs that a container is being used to break isolation and reach the underlying host, such as risky bind mounts, privileged container launches, or abuse of docker.sock. For leaders, this matters because container isolation is often treated as a safety boundary; if that boundary fails, a workload issue can become a host-level incident affecting broader service availability and incident scope.
Executive priority
Prioritize this analytic where containers support business-critical services or shared infrastructure. The decision value is to confirm whether security teams can see dangerous container configurations and host-access patterns early enough to contain a workload before it becomes a host compromise. This also supports audit and readiness conversations around container hardening, privileged access, change control, and incident response evidence.
Technical view
Validate visibility across container runtime and orchestration activity for the Containers platform. Focus on anomalous volume mount configurations, especially hostPath or bind mounts to sensitive host paths such as / or /proc; unexpected privileged container launches; and container administration activity involving docker.sock or similar host-control interfaces. Since the description notes correlation with subsequent process execution on the host outside normal container isolation, detection engineering should test whether container events can be tied to host process telemetry in the same timeframe.
Likely telemetry
- Container runtime events for container creation, launch options, privileged mode, and volume mounts
- Container orchestration audit logs or configuration records showing hostPath or bind mount usage
- Docker or container administration command activity, including access to docker.sock where applicable
- Host process execution telemetry that can be correlated to container-originated activity
- Change records or deployment metadata to distinguish approved privileged workloads from anomalies
Detection direction
- Build or validate detections for privileged container starts and unusual host bind mounts, especially mounts to broad or sensitive host paths.
- Correlate container configuration events with subsequent host process execution outside expected container isolation boundaries.
- Tune against known administrative, CI/CD, monitoring, backup, and infrastructure workloads that may legitimately use privileged settings or host mounts.
- Review blind spots where container runtime logs, orchestration audit logs, or host EDR/process telemetry are not centrally collected or cannot be correlated.
- Because no official detection logic is provided, use local baselines and approved workload inventories to define what is unexpected.
Mitigation priorities
- Inventory and justify containers that require privileged mode, hostPath mounts, broad bind mounts, or docker.sock access.
- Restrict privileged container use and host filesystem exposure to approved workloads with documented business need.
- Apply container hardening and deployment review controls so risky mount and privilege settings are detected before production deployment.
- Ensure incident response playbooks include containment steps for both the container workload and the underlying host when escape indicators appear.
- Maintain evidence of approved exceptions and monitoring coverage for compliance and operational resilience reviews.
Analyst notes and limits
This object is a detection analytic for the enterprise ATT&CK domain and the Containers platform. It provides a high-level behavioral description but no formal detection logic, no tactics, and no relationship context. The strongest use is as a validation prompt for container telemetry coverage, risky configuration governance, and container-to-host correlation capability.
The supplied ATT&CK fields do not include a detection implementation, data components, related techniques, adversary use, mitigations, or relationships. Local environment knowledge is required to determine which privileged containers or host mounts are legitimate and which telemetry sources are available.
Analytic 0612
Detection of container escape attempts via bind mounts, privileged containers, or abuse of docker.sock. Defenders may observe anomalous volume mount configurations (e.g., hostPath to / or /proc), unexpected privileged container launches, or use of container administration commands to access host resources. These events typically correlate with subsequent process execution on the host outside of normal container isolation.
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 | 4b6eaa0c8045… |
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 AN0612Open 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.