Escape to Host

Adversaries may break out of a container to gain access to the underlying host. This can allow an adversary access to other containerized resources from the host level or to the host itself. In principle, containerized resources should provide a clear separation of application functionality and be isolated from the host environment.[1]

There are multiple ways an adversary may escape 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, and utilizing a privileged container to run commands on the underlying host.[2][3][4] 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, or setting up a command and control channel on the host.

ID: T1611
Sub-techniques:  No sub-techniques
Platforms: Containers, Linux, Windows
Permissions Required: Administrator, User, root
Data Sources: Container: Container Creation, Process: OS API Execution, Process: Process Creation
Contributors: Alfredo Oliveira, Trend Micro; Ariel Shuper, Cisco; David Fiser, @anu4is, Trend Micro; Idan Frimark, Cisco; Joas Antonio dos Santos, @C0d3Cr4zy, Inmetrics; Magno Logan, @magnologan, Trend Micro; Vishwas Manral, McAfee; Yossi Weizman, Azure Defender Research Team
Version: 1.0
Created: 30 March 2021
Last Modified: 22 April 2021

Procedure Examples

ID Name Description
S0600 Doki

Doki’s container was configured to bind the host root directory.[4]

S0601 Hildegard

Hildegard has used the BOtB tool that can break out of containers. [5]


ID Mitigation Description
M1048 Application Isolation and Sandboxing

Consider utilizing seccomp, seccomp-bpf, or a similar solution that restricts certain system calls such as mount.

M1038 Execution Prevention

Use read-only containers and minimal images when possible to prevent the running of commands.

M1026 Privileged Account Management

Ensure containers are not running as root by default.


Monitor for the deployment of suspicious or unknown container images and pods in your environment, particularly containers running as root. Additionally, monitor for unexpected usage of syscalls such as mount (as well as resulting process activity) that may indicate an attempt to escape from a privileged container to host. In Kubernetes, monitor for cluster-level events associated with changing containers' volume configurations.