T1611

Escape to Host

Windows · Linux · Containers · ESXinothing on this site yetT1611 on attack.mitre.org

Adversaries may break out of a container or virtualized environment to gain access to the underlying host. This can allow an adversary access to other containerized or virtualized resources from the host level or to the host itself. In principle, containerized / virtualized resources should provide a clear separation of application functionality and be isolated from the host environment.
MITRE ATT&CK 19.2, retrieved 2026-09-12

If this is happening now

Checklists and playbooks to open while the alert is still live.

Playbook for this stage

Cloud account compromise

Impossible travel, an unrecognised inbox rule, or a reported invoice-fraud attempt.

how MITRE says to see it

Detection Strategy for Escape to Host

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.
Detection of Linux container escape attempts via syscalls (`unshare`, `keyctl`, `mount`) or process execution outside container namespaces. Defenders may correlate unusual system calls from containerized processes with subsequent process creation on the host or modification of host resources.
Detection of Windows container escape attempts by observing processes accessing host directories, symbolic link abuse, or privilege escalation attempts. Defenders may detect anomalous process execution with access to system-level directories outside of container boundaries.
Detection of ESXi escape attempts by monitoring for anomalies in hypervisor logs such as unexpected VM operations, privilege escalation events, or attempts to load malicious kernel modules within the hypervisor environment.

what reduces it

M1038 Execution Prevention. Use read-only containers, read-only file systems, and minimal images when possible to prevent the running of commands. Where possible, also consider using application control and software restriction tools (such as those provided by SELinux) to restrict access to files, processes, and system calls in containers.
M1026 Privileged Account Management. Ensure containers are not running as root by default and do not use unnecessary privileges or mounted components. In Kubernetes environments, consider defining Pod Security Standards that prevent pods from running privileged containers.
M1048 Application Isolation and Sandboxing. Consider utilizing seccomp, seccomp-bpf, or a similar solution that restricts certain system calls such as mount. In Kubernetes environments, consider defining Pod Security Standards that limit container access to host process namespaces, the host network, and the host file system.
M1051 Update Software. Ensure that hosts are kept up-to-date with security patches.
M1042 Disable or Remove Feature or Program. Remove unnecessary tools and software from containers.

The description, detection analytics and mitigations are reproduced from MITRE ATT&CK, version 19.2, under its terms of use. The checklists, hunts, labs and everything else linked here are this site’s.