T1611
Escape to Host
Escape to Host (i.e., container escape) enables adversaries to bypass security measures set by virtualized environments, usually allowing them to gain access to the host system’s resources.
Pairs with this song Threat sounds
Escaping from a Linux container to its host must be quite a rush, enough for us to let out a Millennial whoop with Akon.
Analysis
What is a container?
Containers are short-lived processes designed to run an application. They are typically isolated from the underlying host via mechanisms such as namespaces, cgroups, and capabilities. In combination, these mechanisms ensure containers are isolated, resource-controlled, and maintain a level of security.
For example, capabilities in Linux are employed to granularly assign privileges to processes. If an admin wants to grant a process with the ability to open a port but not kill any processes running on the system, they can assign the CAP_NET_BIND_SERVICE capability without granting CAP_KILL. This capability-based approach allows admins to tailor specific privileges for containers while avoiding unnecessary access.
Linux namespaces, a feature designed to provide processes with isolated views of specific system resources, come in various types. Among them, the process ID (PID) namespace isolates the PID number space, and the mount namespace allows each process to have its own filesystem. This is why PID 1 inside a container is not equivalent to PID 1 on the host (and similarly for a file path on the container versus on the host).
Why do adversaries escape to the host?
When adversaries gain a foothold on a container, they are typically limited and will seek to expand their privileges. One way to do so is by escaping to the host (otherwise known as a container escape), where they are no longer limited to the privileges associated with a container. The escape permits an adversary to execute commands at the host level, enabling actions such as establishing persistence through, for example, a rootkit that could be difficult to remove. In addition, container escapes allow them to more effectively enumerate the environment and move laterally. This is because the host frequently stores credentials and sensitive files that may not necessarily be accessible within the container.
How do adversaries escape to the host?
Categorizing the conditions that enable container escapes precisely can be challenging, but a general classification includes: vulnerabilities, privileged containers, and misconfigurations.
Vulnerabilities
Adversaries can exploit vulnerabilities found either in the kernel or in the container runtime environment to escape containers.
Lets first consider kernel vulnerabilities. The kernel is the lowest level of software and hence vulnerabilities that allow adversaries to bypass kernel protection mechanisms can have an impact across the entire host system. One example is the “Dirty Pipe” (CVE-2022-0847) privilege escalation vulnerability, which allows unprivileged users to overwrite data in read-only files.
While the Dirty Pipe vulnerability does not inherently provide a direct means of a container escape, it can be chained with another vulnerability or misconfiguration to escape to the host. Consider a few examples:
- Suppose an admin grants a container read-only access to certain libraries stored on the host for development purposes. An adversary can use Dirty Pipe to write to these files (e.g., inject a reverse shell). Subsequently, when the host executes the libraries, the adversary will escape the container.
- If the host is configured to bind-mount the
runCbinary inside containers, and the adversary can create new containers, they are able to establish a container that waits for therunCbinary to execute. Upon execution, the adversary can overwrite the cloned binary with a custom, malicious binary. The custom binary can execute arbitrary commands on the host, resulting in a container escape. You can read more about this technique here.
Container runtime vulnerabilities consist of security issues within the runtime environment and not necessarily throughout the host. For instance, CVE-2022-23648 exposes a vulnerability in containerd’s Container Runtime Interface (CRI) plugin. Through the creation of a container with a volume that points to a host path, an adversary can gain read access to those files on the host. Hence, if the adversary lands in an environment where they can create containers, they can mount sensitive paths (e.g., /root/.ssh) and gain credentials that would lead to a container escape.
Privileged containers
The second way to conduct a container escape is with privileged containers. There are a few ways a container can be classified as privileged, with capabilities being a key factor.
There are certain capabilities that are overloaded with privileges. For example, the CAP_SYS_ADMIN capability grants a container administrative rights over its own namespace. This allows the container, among other actions, to create or join new namespaces, mount arbitrary filesystems, and load kernel modules. An adversary can leverage this in a few ways:
- An adversary gains access to a non-root user on a container with the
CAP_SYS_ADMINcapability. They then escalate privileges to root and use the nsenter utility to join the initial namespace. This is considered a container escape because commands executed within the initial namespace run at the host level. - An adversary lands on a container with the ability to create new containers. They create a new container with the
CAP_SYS_ADMINcapability and runnsenteras the root user. Similar to above, they consequently achieve a container escape. - While
CAP_SYS_ADMINdoes not inherently imply a container escape, it can be coupled with another capability. For example, a container with theCAP_SYS_PTRACEandCAP_SYS_ADMINcapabilities could allow a user to attach to a process running on the host and proxy commands through it.
You may encounter instances of container creation with no mention of capabilities and instead --privileged (or privileged: true for Kubernetes pods). This setting not only grants all capabilities to a container (including CAP_SYS_ADMIN), but also allows access to all devices on the host, ability to bypass seccomp security profiles and more.
Misconfigurations
Lastly, misconfigurations in the container environment can open doors to container escapes. One notable example is the exposure of the Docker socket inside a container (with default settings, available under /var/run/docker.sock). Developers use this to connect to the Docker daemon to perform administrative tasks. An adversary, however, can also leverage this to create vulnerable or privileged containers (such as the one in the last section), potentially enabling lateral movement within the containerized environment and an escape to the host. Adversaries can leverage this by mounting host paths or exposing sensitive host environment variables.
A similar container escape can occur within a Kubernetes environment. If the service account tied to the pod permits creation of pods or other higher order objects (e.g., daemonsets), an adversary can similarly escape to the host.
Take Action
Consider restricting creation of privileged containers where it is not necessary. Also monitor important components in a containerized environment (i.e., Docker API and Kubernetes API server).
Visibility
Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.
File, script, and command monitoring
Defenders can leverage host telemetry to detect malicious files and scripts. Additionally, command line telemetry can be useful for container escapes involving tools such as nsenter.
Application log monitoring
Defenders can leverage application logs from applications like Docker or Kubernetes to identify attempts at creating privileged containers. For instance, creating a pod with the CAP_SYS_ADMIN capability would lead to a Kubernetes audit log entry similar to the following:
<SNIP>
"spec": {
"containers": [
{
"name": "privileged-pod",
"image": "ubuntu",
"command": [
"sleep",
"3600"
],
"resources": {},
"terminationMessagePath": "/dev/termination-log",
"terminationMessagePolicy": "File",
"imagePullPolicy": "Always",
"securityContext": {
"capabilities": {
"add": [
"CAP_SYS_ADMIN"
]
}
}
}
<SNIP>
Process monitoring
Defenders can use process logs to identify odd parent/child relationships consistent with container escape attempts.
Collection
Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.
Endpoint detection and response (EDR) tools
Traditional EDR sensors can collect the host telemetry and process logs described in the section above.
Kubernetes audit policy
Kubernetes audit policy is a set of rules that define what events in a cluster should be recorded and with what level of granularity. This is typically enabled in self-managed environments, where administrators have direct access to the API server.
Cloud provider logs
Managed Kubernetes providers will provide Kubernetes audit logs with their predefined rules. They also may provide API calls made at the Cloud layer (for instance when an admin instructs Amazon’s Managed Kubernetes Service to scale up a deployment).
Detection opportunities
While providing precise detection logic for this technique can be challenging, the general detection philosophy starts by baselining how containers are used in the environment. If we’re detecting container escapes via privileged containers in a small environment with infrequent use, monitoring creation of all privileged containers is a decent start.
However, in larger environments with frequent use of privileged containers, searching for instances of privileged container creation from externally exposed containers can be a starting point. Consider the following starter detector ideas:
A shell process within a container launching numerous reconnaissance commands
This includes the traditional commands (e.g. whoami and hostname) and also container/Kubernetes-based (e.g., capsh and kubectl get pods).
is_container == true
&&
process_name == shell
&&
child_process == whoami && child_process == kubectlDocker spawning a container that uses nsenter to execute an interactive shell in the initial namespace
Example command: docker run -it --rm --pid=host --privileged ubuntu bash nsenter --target 1 --pid -- /bin/bash
process_name == docker
&&
command_line_includes (“--privileged”)
&&
command_line_includes (“nsenter”)
&&
command_line_includes (“--target 1”)
A container leveraging wget or curl to download additional files
As seen in Dirty Pipe exploit described above.
is_container == true
&&
process_name == (“wget” || “curl”)
&&
(file_modification_extention_includes (“.sh” || “.py”)
Note that certain detectors that would be noisy at the host level (e.g., the last example) could work at the container level. This is because activities such downloading files and excessive network scanning are unusual to occur in containers.
Testing
Start testing your defenses against Escape to Host using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Getting started
View atomic tests for T1611: Escape to Host. In most environments, these should be sufficient to generate a useful signal for defenders. In Atomic test 1, a privileged pod is created, leveraging nsenter to spawn a shell within the initial namespace. Test 2 involves mounting the host filesystem granting the container access to the host’s crontab file, enabling the creation of a reverse shell.
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.