4️⃣MonitorsFour
HTB MonitorsFour — Detailed Solution Notes Platform: Hack The Box | Machine: MonitorsFour | OS: Windows (Host) / Linux (Container) | Difficulty: Hard | Vulnerability Types: Command Injection, Rabbit Holes, Unauthenticated Docker API, Docker Volume Escape
Initial Foothold (Command Injection): Exploiting CVE-2022-46169 in Cacti to gain a reverse shell as www-data inside a Linux Docker container. The Rabbit Holes (Information Disclosure & Misdirection): Finding hardcoded database credentials in a .env file, cracking MD5 hashes to find the web admin password (wonderful1), and attempting to use these for Evil-WinRM or Second-Order RCE via database poisoning. All failed due to strict host configurations. Network Pivot (Internal Discovery): Recognizing the Docker Desktop for Windows architecture, bypassing the lack of network tools (like ping or nmap) by writing a native bash loop to sweep the 192.168.65.x subnet for port 2375. Privilege Escalation / Host Takeover (Docker Escape): Discovering an unauthenticated Docker Engine API. Interacting with it via curl to create and start a malicious container that mounts the Windows host's C:\ drive, triggering a reverse shell to gain full control of the Windows Host system.
When you compromise a web application and find a treasure trove of credentials, hashes, and custom PHP APIs, the immediate instinct is to exploit the application logic. We spent hours trying to force a WinRM connection or trick a background Windows task into executing poisoned database entries.
However, the core lesson of this machine is about Architectural Awareness. If you are trapped inside a container on a Windows host, and application-level logic isn't yielding execution, stop digging into the code. Look at the walls of your prison. Docker Desktop on Windows inherently relies on a virtualized network bridge. If the Docker API is left exposed on that bridge, you don't need a clever web exploit—you just need to ask Docker to give you the host keys. Sometimes, the most devastating vulnerability is not an obscure code flaw, but a wide-open architectural misconfiguration.
The entry point was relatively straightforward. The machine hosted an outdated version of Cacti (1.2.22), which is vulnerable to unauthenticated command injection (CVE-2022-46169). By bypassing the local IP restriction using specific HTTP headers (like X-Forwarded-For) and injecting a payload into the poller mechanism, we secured an interactive shell.
However, the shell returned as www-data with the hostname 821fbd6a43fa. We weren't on the Windows host; we were trapped inside a Linux container.
Before finding the actual path to root, it is crucial to document the failed hypotheses, as they represent the reality of penetration testing.
While exploring the web directory, we found a .env file leaking MariaDB credentials (f37p2j8f4t0r). Accessing the database revealed a users table containing MD5 hashes. We cracked the admin's hash (Marcus Higgins) to reveal the password wonderful1. We attempted to use Evil-WinRM against the Windows host (10.129.233.9) with marcus, Administrator, and various password combinations. We received a WinRMAuthorizationError. The door was open, but our credentials lacked access rights.
We analyzed a custom web API (/var/www/app) and noticed changelogs hinting at automated "system-to-system communication." We hypothesized a Windows Scheduled Task was pulling users from our database via the API. We poisoned the username fields in the database with PowerShell and CMD reverse shell payloads (e.g., mwatson$(ping...)), hoping the Windows host would blindly execute them. We waited with tcpdump. Silence. The application was a dead end.
Realizing we were overcomplicating the application layer, we shifted our focus to the infrastructure.
Understanding Docker Desktop for Windows Docker on Windows uses a VM (WSL2 or Hyper-V) to run Linux containers. This creates a specific internal network routing. While the container itself was on a 172.18.0.x subnet, Docker Desktop often utilizes the 192.168.65.x subnet for host-to-VM communication and API exposure.
The Maneuver: "Living off the Land" Port Scan Our container was extremely stripped down. We had no nmap, no ping, and no netcat. To scan the internal Docker gateway, we used a native bash /dev/tcp loop to probe port 2375 (the default Docker API port) across the subnet: for i in {1..20}; do (echo > /dev/tcp/192.168.65.$i/2375) >/dev/null 2>&1 && echo "BULDUM! Port 2375 acik: 192.168.65.$i"; done
The result? Port 2375 was wide open on 192.168.65.7.
The Docker Escape Maneuver With access to the unauthenticated Docker API, we essentially had administrative control over the Docker Engine running on the Windows host.
Identifying the Environment We used curl to query the API and list available images. We found an existing image named docker_setup-nginx-php:latest.
The Maneuver: Malicious Container Creation We needed to break out of the containerized environment. Docker allows you to mount host directories into containers (Volumes). If we mount the entire Windows C:\ drive into a new container, we can read or overwrite any file on the host.
We crafted a JSON payload to POST to /containers/create. This payload instructed Docker to:
- Use the existing nginx-php image.
- Bind mount /mnt/host/c: (the Windows host drive) to /host_root inside the new container.
- Execute a bash reverse shell back to our Kali machine upon startup.
The Trigger: Starting the Container We parsed the container ID (CID) from the API's response and sent a final POST request to /containers/$cid/start. Immediately, a root shell popped on our Kali listener.
By navigating to /host_root/Users/Administrator/Desktop/, we bypassed Windows authentication entirely and read the root flag.
Bash Native Port Scanning (Living off the Land) Technical Description: Using bash redirection (/dev/tcp/IP/PORT) inside a loop to test TCP connections when standard network tools are missing. Rationale: To bypass restricted container environments and map internal subnets (like 192.168.65.x) without needing to drop binary tools to disk.
Unauthenticated Docker API Exploitation Technical Description: Interacting with an exposed Docker Engine HTTP API (port 2375) via curl to list images, inspect configurations, and issue administrative commands. Rationale: An exposed Docker API is equivalent to root/SYSTEM access. It allows an attacker to manipulate the host's container lifecycle directly.
Docker Volume Mount Escape Technical Description: Crafting a REST API payload to spawn a new container with elevated privileges, specifically using the "Binds" host configuration to mount the underlying host OS filesystem into the container. Rationale: To bridge the gap between the isolated container network and the underlying Windows Host OS, granting unrestricted read/write access to the host's hard drive.
Don't Force a Square Peg into a Round Hole: If you have valid credentials but WinRM refuses authorization, or if database poisoning yields no execution, step back. Don't spend days analyzing a custom PHP application if the underlying infrastructure is the real target. Understand the Architecture: Knowing that Docker Desktop on Windows behaves differently than Docker on bare-metal Linux (specifically regarding the 192.168.65.x subnet and host.docker.internal) was the key to finding the hidden API. Embrace the "Living off the Land" Mentality: When stripped of your tools (no nmap, no ping), you must know how to use the raw operating system. A simple bash loop is often just as effective as a compiled scanner. APIs are God Mode: If you find port 2375 open inside an internal network, drop everything else. An unauthenticated Docker API is a guaranteed path to complete system compromise.