AOC25 | Day-14 + Bonus

CHALLENGE INFORMATION

	Platform: TryHackMe Event: Advent of Cyber 2025 Day: 14 Title: Containers - DoorDasher’s Demise Bonus: Bonus Task

Description

Continue your Advent of Cyber journey and learn about container security.

Summary

Here we start with a quick container theory overview, then we investigate a defaced website and discover it to be hosted in a Docker container with a critical vulnerability: the Docker socket is exposed to the container, giving us full access to the Docker Engine.

Using this access, we escalate privileges to a more privileged container, recover the original website by running a recovery script, and grab the flag. As a bonus, we find a hardcoded password on another service and use it to take over the deployer user account.

Storyline

DoorDasher, a Wareville food delivery service, has been hijacked and rebranded as Hopperoo by King Malhare. The takeover replaced menu items with bizarre ingredients (including Santa’s beard fragments), causing choking incidents and health violations. When a security engineer attempted to restore the system, Sir CarrotBaine locked him out. The SOC team must now escape their monitoring container, escalate privileges, and restore the site.

Theory

Containers are isolated packages bundling applications with their dependencies, solving installation, troubleshooting, and version conflict problems.

They share the host OS kernel (unlike VMs with full guest OSs), making them lightweight and fast.

Why Containers Matter

Microservices architecture breaks applications into independently scalable components. Containers’ lightweight nature makes scaling specific parts efficient without scaling the entire application.

Docker

Docker is the popular container engine that builds, runs, and manages containers using Dockerfiles – text scripts defining app environments and dependencies for consistent deployment across systems.

Security Risk

Container escape is an attack where code inside a container exploits vulnerabilities to access the host kernel or other containers. This occurs when attackers communicate with the container runtime’s Unix sockets, which expose the API server managing containers.

Challenge

Let us start by examining the defaced website running on the target on port 5001.

As we can see, the benign DoorDasher website was replaced by a malicious Hopperoo website.

Given our access to the target system, let us check the running Docker containers with docker ps.

The guide nudges us toward the uptime-checker service, which has port mapping 0.0.0.0:5003->80/tcp, so let us try to access it via our browser on port 5003.

The web interface reports multiple warnings and a system compromise for the DoorDasher service.

Let us try to access the container and see if we can obtain execution inside the container with docker exec -it uptime-checker sh.

To break it down: docker exec executes a command in a running container; -i makes it interactive; -t allocates a pseudo-TTY; uptime-checker is the container in which we want to run the command; and lastly, sh is the basic shell we want to run.

Once we run it, we are welcomed with root access and dropped into the root directory (/).

The next thing to check is socket access, which we can verify by running ls -la /var/run/docker.sock.

To simplify: the Docker socket is a file that allows communication with the Docker Engine through an API. When a container has access to this socket, it can create, manage, and control other containers.

By default, Docker’s Enhanced Container Isolation feature blocks socket access – meaning the socket file is not mounted into the container.

In this instance, however, the socket file was mounted, and we should have management access to the Docker Engine from within the uptime-checker container.

Given our elevated privileges, let us try to access and run commands in the privileged deployer container.

Let us use Bash this time instead of the basic sh: docker exec -it deployer bash.

It worked, and now we have command execution inside the deployer container.

Once we perform quick reconnaissance – whoami to check who we are logged in as and pwd to get the full path to our current working directory – we follow up by examining the root directory (/) with ls -hla.

There are two notable discoveries here:

• flag.txt: Probably the flag for one of the questions below.
• recovery_script.sh: The recovery script that hopefully can fully restore the DoorDasher original website.

Let us first retrieve the flag with cat flag.txt and then try to restore the website by running sudo ./recovery_script.sh, which runs the recovery script with elevated privileges.

If we take a closer look at the script and its privileges, we can note that root owns the script both in user and group, but everybody (other) has permission to execute it – even us – logged in as the deployer user.

The script reports a successful recovery, and when we check the website again on port 5001 via browser, indeed, it has been fully restored.

Questions and Answers

Question-1: Continue your Advent of Cyber journey and learn about container security.

docker ps

Question-2: What file is used to define the instructions for building a Docker image?

Dockerfile

Question-3: What’s the flag?

<redacted-flag>

Question-4: Liked the content? We have plenty more where this came from! Try our Container Vulnerabilities room.

No answer needed

Bonus Task

Bonus-Question: There is a secret code contained within the news site running on port 5002; this code also happens to be the password for the deployer user! They should definitely change their password. Can you find it?

DeployMaster2025!

Lastly, the bonus question mentions a news website running on port 5002. Let us check it out.

There are a couple of words highlighted here: ‘Deploy’, ‘Master’, ‘2025!’.

If we concatenate them, it looks like a password, which could be potentially dangerous. Let us verify it by attempting a password change with passwd:

It worked; DeployMaster2025! was truly the deployer user’s password, and we changed it to a password that we now control.