Threat Hunting Exercise: Analyzing Linux Docker Socket Mount Container Escape Dataset

This hunt uses a simulated container-host dataset (linux_docker_escape_2022-08-19T113000.json) capturing T1611: Escape to Host, where an attacker with access inside one container abuses a mounted /var/run/docker.sock to launch a new, privileged container with the host filesystem bind-mounted, achieving full host root access.

Step 1: Hypothesis Formation

Hypothesis: A process running inside an existing container issues Docker API calls (via a mounted docker.sock) to create and start a new container with --privileged and a host-root bind mount (-v /:/host), then executes a chroot or direct file write to plant a host-level backdoor. Indicators:

Docker daemon logs show a container create API call originating from a client connecting via the Unix socket, with Privileged: true and a bind mount source of /.
The requesting container's own configuration shows docker.sock mounted as a volume - an unusual and high-risk configuration for an application container.
Shortly after the new privileged container starts, a file appears on the host filesystem (e.g., a new cron entry, SSH key, or SUID binary) that did not exist before.
The host-level auditd log shows this file creation attributed to a containerized process (via cgroup/namespace correlation) rather than a normal host administrative session.

Null Hypothesis: A legitimate CI/CD or container-orchestration tool (e.g., a Docker-in-Docker build agent) is intentionally using the mounted socket to build/deploy other containers as designed. Invalidate by confirming the calling container against the approved CI/CD image inventory and checking for a corresponding pipeline run.

Rationale: Mounting the Docker socket into a container is a common but dangerous misconfiguration that is functionally equivalent to giving that container root on the host; this hunt validates monitoring Docker API calls for privileged/host-mount container creation as a detection layer for what is otherwise a fully "legitimate-looking" use of a documented Docker feature.

Step 2: Data Sources and Scope

Sources: Docker daemon logs (/var/log/docker.log or journalctl -u docker) and the Docker Engine API audit log; host-level auditd (with container/cgroup context enrichment); container runtime security tool alerts (e.g., Falco).
Scope: ~2022-08-19T11:30:00-11:33:00 UTC; Host: docker-host-04 (10.240.2.55); Source container: webapp-frontend-7d9f8 (image: internal/webapp:1.4).
SIEM Queries (Splunk/ELK):
index=docker action="create" request_body="Privilegedtrue*"
index=docker action="create" request_body="\"Binds\":\"/:/host*"
Falco rule cross-check: index=falco rule="Launch Privileged Container" OR rule="Container Run with Sensitive Mount"

Step 3: Key Findings

Parsed events (5 shown) confirm the webapp-frontend container - which had docker.sock mounted for an undocumented reason - used it to spin up a privileged container with the host root filesystem mounted, then wrote an SSH authorized key to the host.

Timestamp (UTC)	Host	Event	Detail	IOC/Why Suspicious?
2022-08-19 11:30:05	docker-host-04	Docker daemon log	API call from container `webapp-frontend-7d9f8` (via mounted socket) to `POST /containers/create`	Socket-Abuse IOC: an application container issuing Docker daemon-management API calls is not normal webapp behavior.
2022-08-19 11:30:06	docker-host-04	Docker daemon log	Request body: `{"Image":"alpine","HostConfig":{"Privileged":true,"Binds":["/:/host"]}}`	Escape IOC: `Privileged: true` combined with a full host-root bind mount is the textbook Docker-socket container-escape payload.
2022-08-19 11:30:08	docker-host-04	Falco alert	"Launch Privileged Container" and "Container Run with Sensitive Mount (/ mounted)" fired simultaneously	Independent container-runtime security tool corroborates the daemon-log finding in real time.
2022-08-19 11:30:20	docker-host-04 (host fs, via new container)	auditd (cgroup-enriched)	`/host/root/.ssh/authorized_keys` written, appending an attacker-controlled public key	Impact IOC: this is a direct host-filesystem write from inside a container, made possible only by the `/:/host` bind mount - full host persistence achieved.
-	-	(image inventory check)	`webapp-frontend` is not on the approved CI/CD build-agent image list; no pipeline run corresponds to this timestamp	Confirms this is not legitimate Docker-in-Docker build activity.

Validation:

Timeline: socket-based API call, privileged host-mounted container creation, and host SSH key implant all within 20 seconds - a fast, automated escape chain.
False Positives: webapp-frontend is an application container, not a CI/CD build agent, and no pipeline run explains the activity; Falco's independent runtime alert corroborates the Docker daemon log.
Correlation: daemon API log, Falco runtime alert, and host-level auditd file write together confirm a successful, ground-truth container escape to host root.

Step 4: Recommendations & Next Steps

Immediate Response: Remove the planted SSH key from /root/.ssh/authorized_keys on docker-host-04; kill and remove the malicious privileged container; audit and remove the docker.sock mount from webapp-frontend's configuration; treat docker-host-04 as fully compromised at the host level and rebuild if any further host-level artifacts are found.
Detection: Sigma/Falco rule: title: Docker Socket Used to Launch Privileged Host-Mounted Container → selection: docker_api_action="create" AND (Privileged=true OR Binds contains "/:") AND caller_is_container=true.
Pro Tip: Never mount docker.sock into application containers - if Docker-in-Docker functionality is genuinely required, use a dedicated, tightly-scoped build-agent image with no other network exposure, and enforce this via an admission controller (e.g., OPA/Gatekeeper) that blocks socket mounts outside an explicit allow-list.

Hypothesis confirmed - an application container with an unnecessarily mounted Docker socket was abused to launch a privileged, host-root-mounted container, achieving full host filesystem compromise via a planted SSH key!