Escape to Host (T1611) is a Privilege Escalation technique. MITRE lists Windows, Linux, Containers and ESXi as platforms. The adversary breaks out of a container or a virtualized environment to reach the underlying host.
In principle, containers and virtual machines keep application functionality separate from the host. An escape removes that separation, and with it the idea that a compromised workload stays contained.
How attackers use it
MITRE lists several routes:
- Bind mounts. Creating a container set up to mount the host's file system using the bind parameter, so the adversary can drop payloads and run control utilities such as cron on the host.
- Privileged containers. Using a privileged container to run commands or load a malicious kernel module on the host.
- System calls. Abusing calls such as unshare and keyctl to escalate privileges and steal secrets.
- A mounted management socket. Exploiting a compromised container that has a socket such as docker.sock mounted, to break out through Container Administration Command (T1609).
- Vulnerabilities. Exploiting flaws such as global symbolic link issues to reach the root directory of the host, through Exploitation for Privilege Escalation (T1068).
- ESXi. Exploiting a vulnerability to escape from a virtual machine into the hypervisor.
Once on the host, the adversary may establish persistence, move laterally, reach other containers or virtual machines on the host, or set up command and control.
Examples listed on the page: Doki's container was configured to bind the host root directory. Peirates can gain a reverse shell on a node by mounting the Kubernetes hostPath. Siloscape maps the host's C drive into the container using a global symbolic link. TeamTNT deployed privileged containers that mount the victim machine's filesystem, and Hildegard used the BOtB tool that can break out of containers.
How to detect it
MITRE has a separate analytic for each environment.
- Containers in general: anomalous volume mounts such as hostPath to the root or to the proc directory, unexpected privileged container launches, or use of container administration commands to reach host resources. These tend to be followed by process execution on the host outside normal isolation.
- Linux: unusual system calls from containerized processes (unshare, keyctl, mount) followed by process creation on the host or changes to host resources.
- Windows containers: processes touching host directories, symbolic link abuse or privilege escalation attempts, and unusual execution with access to system directories outside container boundaries.
- ESXi: hypervisor log anomalies such as unexpected VM operations, privilege escalation events or attempts to load malicious kernel modules.
The easiest win is configuration review. Several of the escapes in that list need a risky setting to be present first: a host path mount, the privileged flag, a mounted socket. Catch the setting and you have caught the risk before anyone uses it.
How to reduce the risk
MITRE lists these mitigations:
- Patch hosts. Keep hosts up to date with security patches.
- Make containers hard to use. Use read-only containers, read-only file systems and minimal images. Add application control or SELinux to restrict files, processes and system calls.
- Sandbox system calls. Use seccomp, seccomp-bpf or a similar control to restrict calls such as mount. In Kubernetes, define Pod Security Standards that limit access to host process namespaces, the host network and the host file system.
- No root, no extra privileges. Do not run containers as root by default, and avoid unnecessary privileges and mounted components. Block privileged pods with Pod Security Standards.
- Remove unneeded tools from containers.
Check your own environment
Read-only checks (Docker on Linux, Kubernetes with kubectl):
# Docker: which running containers are privileged?
docker ps -q | xargs -r docker inspect --format '{{.Name}} privileged={{.HostConfig.Privileged}}'
# Docker: which host paths are mounted into containers (look for / and docker.sock)?
docker ps -q | xargs -r docker inspect --format '{{.Name}}: {{range .Mounts}}{{.Source}} {{end}}'
# Kubernetes: pods that use hostPath volumes
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" "}{.spec.volumes[*].hostPath.path}{"\n"}{end}'
Then review:
- Any container with docker.sock mounted. Does it truly need it?
- Any pod with hostPath, hostPID, hostNetwork or privileged set.
- Whether Pod Security Standards are enforced in every namespace, not just production.
- How quickly your hosts receive kernel and runtime patches.
Quick check
Why is a mounted docker.sock risky?
A compromised container with the socket can use the Docker API to run commands and start containers, which MITRE describes as breaking out through a Container Administration Command.
Which settings are worth finding before an attacker does?
Privileged mode, host path mounts, host namespaces and mounted management sockets. Each is a configuration, so each can be found by review.
Name one control that limits system calls.
seccomp or seccomp-bpf, which can restrict calls such as mount.
