Last reviewed:
T1611 is container escape: breaking out of a pod or container onto the node that runs it, via privileged containers, sensitive host mounts or kernel bugs. One escape converts a single compromised workload into every workload on the node. DCV pairs GuardDuty's runtime RuncContainerEscape and DockerSocketAccessed findings and the Persistence:Kubernetes/ContainerWithSensitiveMount signal with the Azure policy set denying privileged containers and container privilege escalation in Kubernetes clusters. Admission control is the cheap win: block the privileged pod before scheduling rather than detecting the escape afterwards.
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.
There are multiple ways an adversary may escape from a container to a host environment. Examples include creating a container configured to mount the host’s filesystem using the bind parameter, which allows the adversary to drop payloads and execute control utilities such as cron on the host; utilizing a privileged container to run commands or load a malicious kernel module on the underlying host; or abusing system calls such as `unshare` and `keyctl` to escalate privileges and steal secrets.
Additionally, an adversary may be able to exploit a compromised container with a mounted container management socket, such as `docker.sock`, to break out of the container via a Container Administration Command. Adversaries may also escape via Exploitation for Privilege Escalation, such as exploiting vulnerabilities in global symbolic links in order to access the root directory of a host machine.
In ESXi environments, an adversary may exploit a vulnerability in order to escape from a virtual machine into the hypervisor.
Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, accessing other containers or virtual machines running on the host, or setting up a command and control channel on the host.
Platforms: Windows, Linux, Containers, ESXi.
DCV maps 18 detections across 2 cloud providers to T1611. Coverage by source:
| Source | Cloud | Findings mapped | Avg confidence |
|---|---|---|---|
| Azure Policy | Azure | 8 | 0.89 |
| AWS GuardDuty | AWS | 5 | 0.90 |
| AWS Config Rules | AWS | 3 | 0.65 |
| Microsoft Defender for Cloud | Azure | 2 | 0.93 |
CloudSigma has coverage metadata for 18 T1611 rules across 1 platform. The linked platform page remains the canonical rule surface; this page will embed an example after a rule clears the public embed bar.
CloudSigma has coverage metadata for T1611, but no public example rule clears the embed bar for this page yet. Generate a fresh starting-point rule in CloudSigma from the relevant advisory or threat-research input, then validate it against your local telemetry before enabling it in production.
T1611 is container escape: breaking out of a pod or container onto the node that runs it, via privileged containers, sensitive host mounts or kernel bugs. One escape converts a single compromised workload into every workload on the node. DCV pairs GuardDuty's runtime RuncContainerEscape and DockerSocketAccessed findings and the Persistence:Kubernetes/ContainerWithSensitiveMount signal with the Azure policy set denying privileged containers and container privilege escalation in Kubernetes clusters. Admission control is the cheap win: block the privileged pod before scheduling rather than detecting the escape afterwards.
DCV maps 18 cloud-native detections to T1611 across 2 cloud providers, drawn from AWS Config Rules, AWS GuardDuty, Azure Policy and Microsoft Defender for Cloud.
T1611 is part of MITRE ATT&CK TA0004 Privilege Escalation: How adversaries gain higher privileges than they were given.
CloudSigma ships 1 validated Sigma rules for T1611 across Linux auditd. Each rule is validated against its source SIEM dialect before publication.