In the previous phase of this project, I established both insecure and hardened container baselines. With those baselines in place, I began the first attack narrative by examining one of the most well-known and most dangerous container misconfigurations: mounting the Docker socket inside a container. This attack is not subtle, and it does not rely on exploiting a kernel vulnerability or bypassing container isolation in a clever way. Instead, it demonstrates how a single configuration choice can completely undermine the security guarantees containers are often assumed to provide. Threat Overview The Docker daemon runs as root on the host system and exposes an API over a Unix socket located at /var/run/docker.sock. Any process that can communicate with this socket can issue Docker commands with root-equivalent privileges. If this socket is mounted into a container, the container effectively gains control over the Docker daemon and by extension, the host itself. This configuration is sometimes used for convenience in CI pipelines or management containers, but it introduces an extreme security risk if exposed to untrusted code. Insecure Scenerio In the insecure scenario, a container is launched with the host’s Docker socket mounted into it: The container runs as root /var/run/docker.sock is available inside the container No additional isolation or runtime restrictions are applied At this point, the container is still technically isolated, but it has been given the ability to issue commands directly to the host Docker daemon. Attack Execution From inside the container, I was able to verify access to the Docker daemon by listing running containers with the ps command. Using that access, I started a new container with elevated privileges and access to the host’s process namespace: docker run -it --privileged --pid=host ubuntu:22.04 bash This command instructs the Docker daemon (running as root on the host) to create a new container with: Full privileges Access to host devices Shared PID namespace with the host Inside this new container, standard system inspection commands revealed host-level visibility: ps aux | head The presence of processes such as /sbinit/init, kernel threads, and host workers confirmed that the container was now operatring in the host’s process namespace. Impact At this stage, the container environment is no longer meaningfully isolated. With this level of access, an attacker could: Inspect or manipulate host processes Mount host filesystems Access sensitive data Establish persistence on the host It is important to note that this was not achieved by “breaking out” of a container in the traditional sense. Instead, the container was granted the ability to ask Docker to create a new container with host-level access. The Docker socket effectively acts as a remote root API. Secure Comparison When the same attack was attempted against the hardened container baseline, it failed immediately. In the secure configuration: The container runs as a non-root user All Linux capabilities are dropped The filesystem is read-only The Docker socket is not present Attempting to locate /var/run/docker.sock resulted in an error, preventing the attack chain from starting at all. Without access to the Docker daemon, the container has no mechanism to escalate its privileges or interact with the host. Takeaway This attack demonstrates that mounting the Docker socket into a container is equivalent to granting root access on the host. No kernel exploit or container escape technique is required—only permission to communicate with the Docker API. The contrast between the insecure and hardened configurations highlights a central theme of this project: container security is largely determined by configuration choices. Containers can provide strong isolation, but those guarantees can be nullified by a single convenience-driven decision. This attack narrative reinforces the importance of treating the Docker socket as a highly sensitive resource and avoiding its exposure to untrusted workloads.