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, or utilizing a privileged container to run commands on the underlying host.[2][3][4] 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.[5]
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 | 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. [6] |
| S0683 | Peirates |
Peirates can gain a reverse shell on a host node by mounting the Kubernetes hostPath.[7] |
| S0623 | Siloscape |
Siloscape maps the host’s C drive to the container by creating a global symbolic link to the host through the calling of |
| G0139 | TeamTNT |
TeamTNT has deployed privileged containers that mount the filesystem of victim machine.[9][10] |
| 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. In Kubernetes environments, consider defining a Pod Security Policy that limits container access to host process namespaces, the host network, and the host file system.[11] |
| M1038 | Execution Prevention |
Use read-only containers, read-only file systems, and minimal images when possible to prevent the running of commands.[11] |
| M1026 | Privileged Account Management |
Ensure containers are not running as root by default. In Kubernetes environments, consider defining a Pod Security Policy that prevents pods from running privileged containers.[11] |
| ID | Data Source | Data Component |
|---|---|---|
| DS0032 | Container | Container Creation |
| DS0009 | Process | OS API Execution |
| Process Creation | ||
| DS0034 | Volume | Volume Modification |
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.