# HTB Machines :: MonitorsFour Writeup


## Reconnaissance

We begin by setting up DNS resolution using the `etc/hosts` file and conducting an `nmap` scan to enumerate the open ports.

### Network Scan

Initial `nmap` scan shows port 80 and 5985 is open, indicating that the machine is hosting a php webserver on top of nginx


## Enumeration

### Website Enumeration

Going to `http://monitorsfour.htb` shows us a landing page for a networking service, however there is nothing interesting to be found here.


A simple header check shows us that the server is running PHP v.8.3.27


### Subdomain Enumeration

Using `gobuster`, we enumerated the subdomain and found an additional subdomain called `cacti`


Going to `http://cacti.monitorsfour.htb` shows us a user login page for Cacti v1.2.28


### Directory Enumeration

Using `gobuster` again, we checked the main domain for anything interesting and we found a `/user` endpoint.


## Exploitation

Accessing the user endpoint for possible IDOR vulnerability dumps us the entire user array when accessing using `0` as the user token.


### Hash Cracking

Cracking the hash for the user `admin` using `hashcat` and MD5 as the mode gives us the credentials that we can use for the cacti service


However, logging in using the username admin doesn't work, we tried `higgins` and `marcus`, and `marcus` works.

marcus : wonderful1

### CVE-2025-24367


Since the Cacti service is running v1.2.28, it's vulnerable to a Post-Auth RCE by creating a malicious graph template containing a PHP reverse shell, which was published [here](https://nvd.nist.gov/vuln/detail/CVE-2025-24367)


Using this [script](https://github.com/TheCyberGeek/CVE-2025-24367-Cacti-PoC), we were able to gain a reverse shell on the target machine


## Privilege Escalation (User)

Since www-data has misconfigured permission, we can get the user flag by simply reading the `user.txt` file from `/home/marcus`


User Flag : 61eebf8c6161e53926e98376c3b93096

## Privilege Escalation (Root)

From the hostname, we could deduce that the service is running within a docker container, to enumerate information about the docker version, we have to query the Docker API


However, since the docker internal hostname doesn't work, we enumerate the subnet for a reachable service with port 2375 open and found out that `192.168.65.7:2375` is open


From here, we found out that the machine is running Docker Desktop on top of WSL, specifically v28.3.2 which allows a container to access the Docker API of the host machine

### CVE-2025-9074


This vulnerability allows the docker container to execute arbitrary docker commands via the Docker API, allowing the host machine drive to be mounted and accessed via a containerized instance. The details can be read [here](https://nvd.nist.gov/vuln/detail/CVE-2025-9074)

we proceeded by creating a docker image that mounts the root flag and outputting it to the logs


And then we use the exposed Docker API to run the image, outputting the logs to stdout


And just like that, we earned the root flag


Root Flag : 266aa41a9130955c69e8f21ef0297679