T1611 Escape to Host Defensive Guide

A container shares its host's kernel, so a workload started with the wrong flags, mounts or socket access is one step from controlling the node and every other container on it. MITRE ATT&CK T1611 Escape to Host covers breaking out of a container, or a virtual machine on ESXi, to reach the underlying host, and sits in the Privilege Escalation tactic (TA0004) in ATT&CK v20. Most real-world escapes do not need a kernel exploit: they use configuration that the platform allows, such as privileged containers, host path mounts or a mounted Docker socket. This guide explains the escape routes as ATT&CK describes them, the admission controls and runtime settings that close them, and the detections that catch the attempts that remain. It is for platform engineers, Kubernetes administrators and detection engineers; it builds on the Container Runtime Security Guide and contains no escape procedures.

Key takeaways

Configuration is the main escape route. ATT&CK lists host filesystem bind mounts, privileged containers and mounted container management sockets before kernel exploits.
Pod Security Standards close most of it. The Baseline profile forbids privileged containers, host namespaces and hostPath volumes; Restricted adds non-root, no privilege escalation, a seccomp profile and dropping all capabilities.
The Docker socket is root on the host. Docker's own documentation says only trusted users should control the daemon, because it can share the host's / directory with a container without restriction.
Kernel patching still matters. Containers share one kernel, so a kernel flaw reachable from a container is a host flaw; track kernel CVEs in the CISA KEV catalogue for container nodes.
Escape is usually a means to identity. On the host, the prize is kubelet credentials, other pods' service account tokens and cloud instance credentials.

How the attack works

ATT&CK describes T1611 as breaking out of "a container or virtualized environment to gain access to the underlying host". It names several routes. Defensively, they fall into five groups, and each has a matching control.

Route (as ATT&CK describes it)	What makes it possible	Closing control
Container that mounts the host filesystem through a bind mount	hostPath volumes or `-v /:/host` style mounts, which let a container write to host paths such as cron directories	Forbid hostPath (Baseline); allow only approved read-only paths through policy exceptions
Privileged container used to run host commands or load a kernel module	`privileged: true`, broad capabilities such as `SYS_ADMIN` or `SYS_MODULE`, host PID or network namespaces	Forbid privileged and host namespaces (Baseline); drop ALL capabilities (Restricted)
Abuse of system calls such as `unshare` and `keyctl`	No seccomp profile, unconfined AppArmor or SELinux	Seccomp `RuntimeDefault` or `Localhost` (Restricted); mandatory access control profiles
Mounted container management socket such as `docker.sock`, then T1609 Container Administration Command	Socket mounted into a build or monitoring container	Never mount runtime sockets into workloads; rootless runtimes
T1068 Exploitation for Privilege Escalation, for example via global symbolic links; VM escape on ESXi through a hypervisor vulnerability	Unpatched kernel, runtime or hypervisor	Patch nodes and hypervisors; sandboxed runtimes for untrusted code

ATT&CK v20 maps five mitigations: M1026 Privileged Account Management, M1038 Execution Prevention, M1042 Disable or Remove Feature or Program, M1048 Application Isolation and Sandboxing and M1051 Update Software. The only group it lists for T1611 is TeamTNT, but container escape tooling is widely available and is part of most cluster intrusions that reach node level.

Where it shows up

Compromised application pods: an intruder who gains code execution in a pod through a web vulnerability checks what the pod was granted: capabilities, mounts, service account token and the socket list.
CI runners and build systems: Docker-in-Docker and socket-mounted builders are a common reason the socket ends up inside a container. See the Kubernetes Security Guide.
Exposed container APIs: anyone who reaches the daemon controls the host. In the TeamTNT worm, Docker APIs reachable from the internet without access control let the worm start its own containers on each host, then take AWS credential files.
Monitoring and security agents: node agents legitimately run privileged, which makes their images and namespaces a high-value target.
Multi-tenant platforms and AI code execution sandboxes: any service that runs customer or model-generated code in containers. See the AI Agent Sandboxing and Code Execution Guide.

Impact

Node control: root on the host, with the ability to persist outside any container (for example through cron or systemd on the node).
Neighbour compromise: access to other containers' filesystems, environment variables and mounted secrets on the same node.
Credential theft: kubelet client credentials, projected service account tokens and the cloud instance identity attached to the node.
Cluster escalation: from node credentials towards the control plane, especially where nodes can read secrets broadly. See the Kubernetes Cluster Compromise Playbook.
Hypervisor reach: a VM escape on ESXi exposes every virtual machine on the host.

Detection

ATT&CK's detection strategy for T1611 looks for anomalous mount configurations (hostPath to / or /proc), unexpected privileged launches and container administration commands at the orchestration layer, and for unshare, mount, keyctl and setns calls by containerised processes followed by process activity on the host.

Layer	Source	What to alert on
Admission	Kubernetes API server audit log; Pod Security Admission audit annotations	Pods created with `privileged`, `hostPID`, `hostNetwork`, `hostIPC`, hostPath volumes or added capabilities outside the system namespaces that need them
Admission	Audit log	`pods/exec` and `pods/attach` into privileged or node-agent pods; new DaemonSets
Runtime	Docker daemon events, containerd or CRI-O logs	Container create with the privileged flag, host volume mount or `docker.sock` mount
Kernel	auditd or eBPF sensors	`unshare`, `setns`, `mount`, `keyctl`, `init_module` or `finit_module` from processes in container namespaces
Host	EDR or eBPF process lineage	Processes whose ancestry starts in a container but which run in the host's namespaces; writes to host `/etc`, cron or systemd paths from container processes
Identity	Cloud audit logs; Kubernetes audit	Node instance credentials or kubelet credentials used from unexpected addresses, or used to list secrets
Windows containers	Security 4688, Sysmon 11	Container processes touching host system directories

Metrics

Enforcement coverage: percentage of namespaces with pod-security.kubernetes.io/enforce set to baseline or restricted.
Exceptions: number of workloads running privileged, with host namespaces or with hostPath, each with an owner and review date.
Socket exposure: workloads mounting a container runtime socket, target zero outside approved node agents.
Kernel currency: percentage of nodes on a kernel with no open KEV-listed vulnerabilities.
Runtime sensor coverage: share of nodes reporting system call telemetry to the SOC.

Prevention and hardening

Pod Security Standards

Control	Baseline	Restricted (in addition)
Privileged containers	Must be disallowed	Same
Host namespaces	`hostNetwork`, `hostPID` and `hostIPC` disallowed	Same
HostPath volumes	Forbidden	Only listed volume types allowed
Windows HostProcess	Disallowed	Same
Capabilities	Additions limited to a default list	Must drop `ALL`; only `NET_BIND_SERVICE` may be added back
Seccomp	Must not be set to `Unconfined`	Must be set explicitly to `RuntimeDefault` or `Localhost`
Privilege escalation	Not restricted	`allowPrivilegeEscalation` must be false
Running as non-root	Not restricted	`runAsNonRoot` must be true

Pod Security Admission applies these per namespace in three modes: enforce rejects violating pods, audit adds an annotation to the audit event, and warn returns a warning to the user. Use them as a rollout sequence.

Rollout

Measure: label every application namespace with audit=restricted and warn=restricted, and collect the violations for two to four weeks.
Fix the easy ones: add runAsNonRoot, allowPrivilegeEscalation: false, seccompProfile: RuntimeDefault and drop: ["ALL"] to workload templates.
Enforce Baseline on all application namespaces, then Restricted namespace by namespace. Pin the policy version label so upgrades do not change behaviour unexpectedly.
Handle exceptions: keep node agents that need privilege in dedicated namespaces with tight RBAC, and use a policy engine for finer-grained exceptions. See the Kubernetes Admission Control Guide.
Roll back a namespace by changing its enforce label back to the previous level; audit and warn can stay on.

Runtime and host

Rootless or remapped runtimes: Docker's rootless mode runs both the daemon and containers inside a user namespace; userns-remap remaps container users while the daemon stays root.
No sockets in workloads: Docker notes the API uses a Unix socket so that file permissions can limit access; do not undo that by mounting it into containers or exposing the daemon over TCP.
Mandatory access control: AppArmor or SELinux profiles for containers. See the seccomp Guide and the AppArmor Guide.
Sandboxed runtimes (a user-space kernel or lightweight VM per pod) for untrusted or multi-tenant code, accepting the performance cost (M1048).
Node hygiene: minimal container-optimised host operating systems, fast kernel patching, and no long-lived cloud credentials on nodes beyond the instance identity.

Small and large platforms

A small team running one cluster gets most of the value from enforcing Baseline everywhere, Restricted for internet-facing workloads, and removing any Docker socket mounts. A large platform adds a policy engine for exceptions, eBPF runtime detection on every node, sandboxed runtimes for tenant or AI-generated code, and node pools separated by trust level so an escape on one pool cannot reach sensitive workloads.

Where identity fits

After an escape the intruder holds the node's identities: kubelet credentials, every pod's projected service account token on that node and the cloud instance role. Limit what each can do: scope service account RBAC tightly, disable token automounting where pods do not call the API, use workload identity federation with per-pod roles rather than broad node roles, and rotate node credentials after any suspected escape. See the Kubernetes Service Account Token Guide and the Kubernetes NHI Security Guide.

Framework mapping

Framework	Relevant items
MITRE ATT&CK v20	TA0004 Privilege Escalation; T1611; related T1609 Container Administration Command, T1610 Deploy Container, T1068
MITRE D3FEND	D3-SCA System Call Analysis, D3-PA Process Analysis
NIST SP 800-53 Rev. 5	SC-39 Process Isolation, CM-7 Least Functionality, AC-6 Least Privilege, SI-4 System Monitoring, RA-5 Vulnerability Monitoring and Scanning
NIST SP 800-190	Application Container Security Guide (host OS, runtime and orchestrator countermeasures). See the NIST SP 800-190 Container Security Guide.
NIST CSF 2.0	PR.PS-01 (configuration management), DE.CM-09 (runtime environments monitored), ID.RA-01 (vulnerabilities identified)
CIS Controls v8.1	Control 4 Secure Configuration, Control 7 Continuous Vulnerability Management

Common failure patterns

Audit mode forever: namespaces labelled audit=restricted whose violations nobody reviews give a false sense of coverage.
System namespaces as a dumping ground: privileged exceptions granted to kube-system attract unrelated workloads, and anyone who can create pods there inherits the exception.
Socket mounts for convenience: build and monitoring containers given the runtime socket "temporarily" become the easiest escape on the node.
Patching images but not nodes: image scanning is mature in most teams, while node kernels and runtimes lag, yet the kernel is the shared boundary.
Broad node identities: a node cloud role that can read every secret store turns a single escape into a cloud account compromise.

Practitioner checklist

Label every namespace with Pod Security Admission audit and warn at restricted, and enforce at least baseline.
Remove every container runtime socket mount outside approved node agents.
Require seccompProfile: RuntimeDefault, drop: ["ALL"] and runAsNonRoot in workload templates.
Alert on privileged, host namespace and hostPath pods outside system namespaces.
Collect container-aware system call telemetry for unshare, setns, mount and module loading.
Patch node kernels and runtimes against KEV-listed vulnerabilities on a defined deadline.
Use sandboxed runtimes for untrusted or AI-generated code.
Scope node and service account identities so an escape does not give cluster-wide secrets.

T1611 Escape to Host Defensive Guide: Preventing and Detecting Container Breakout