Lion Cipher Lab

Exploit an exposed Docker Engine API in your own lab

• Penetration Testing / Red Team
• Intermediate
• ~50 min
• Free · no account required

Why it matters

An exposed Docker Engine API is one of the highest-severity findings you can trip over on the internet, and it comes from the same one human mistake as an exposed database — a service that is safe locally gets put on a network without the protection that move demands. Docker is the tool most teams use to run applications in CONTAINERS (lightweight, isolated packages of software). The thing actually doing the work is a background service called the DOCKER DAEMON, or `dockerd`, and you control it through the DOCKER ENGINE API — a REST API (an interface you drive with ordinary HTTP requests)…

What you'll learn

• defining what the Docker daemon (dockerd) and the Docker Engine API are, and why reaching that API is not 'read some data' but root-equivalent control of the host running it
• standing up an isolated lab where the 'victim host' is a Docker-in-Docker container running its own dockerd on a private network, so even the 'root on the host' proof happens inside a disposable container and never touches your real machine
• confirming unauthenticated access to the exposed daemon two ways: with the docker CLI pointed at tcp://victim:2375, and with a raw HTTP request to the REST endpoints (/version, /info, /containers/json) to see that the API is just unauthenticated HTTP
• reproducing the canonical escalation — starting a container that bind-mounts the victim's root filesystem to read and write arbitrary host files — and explaining precisely why daemon access equals root on the host
• distinguishing this REMOTE exposure (daemon published on a TCP port) from the LOCAL mounted-socket container escape, and why they share the same root cause but are different findings
• naming the safeguard you had to disable to reproduce it — dockerd exposes NO TCP socket by default, only a local unix socket — and why that makes an exposed 2375 always a human misconfiguration, not a Docker vulnerability
• applying the fix: don't publish the daemon at all; if remote access is truly required, use an SSH connection or mutual-TLS on 2376 with client certificates, plus a firewall — and re-measuring that the plaintext 2375 client now fails
• judgment: recognising an exposed 2375 on sight, treating docker access as root in a report, knowing that many exposed daemons on the internet are cryptojacked or honeypots, and preventing recurrence structurally

Steps in this lab

1. What the Docker daemon and Engine API are, and why reaching them is root
2. Build the isolated lab: a Docker-in-Docker 'victim host', your machine only
3. Confirm unauthenticated control — the finding, two ways
4. The escalation: mount the host filesystem = root on the host (victim container only)
5. Why the default is safe, how this differs from the socket-escape lab, and why it still happens
6. The fix: don't publish it — or use SSH / mutual-TLS, then measure
7. Do it better — how to recognise, report, and prevent the exposed daemon

Open the full interactive lab →