Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the MonitorsFour machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs.
You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment and subscribe to my YouTube channel and follow me on LinkedIn for more updates.About the Machine
MonitorsFour is an easy-difficulty Windows machine that focuses on web application enumeration, containerized environments, and Docker misconfigurations. The machine begins with the discovery of a vulnerable Cacti monitoring instance, where improper input handling leads to remote code execution and an initial foothold within a Docker container.
Once inside the container, the challenge shifts toward post-exploitation and lateral enumeration, requiring players to identify internal services and misconfigured infrastructure. By uncovering an exposed, unauthenticated Docker API, attackers can abuse container management endpoints to create malicious containers and mount the host filesystem.
This misconfiguration enables a straightforward container escape, ultimately leading to full compromise of the underlying Windows host and retrieval of the root flag.
MonitorsFour highlights common real-world security pitfalls, including insecure container deployments, reliance on isolation assumptions, and the critical risk posed by exposed Docker services. It serves as an excellent introduction to container escape techniques and Docker API abuse in hybrid Linux–Windows environments.
The first step in owning the MonitorsFour machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:
Once the connection between my Kali Linux terminal and Hack the Box server has been successfully established, I started the Gavel machine and I was assigned an IP address (10.10.11.98).
Initial Reconnaissance
Before interacting with the target application, I first ensured that the hostname used by the service resolved correctly on my attacking machine. Since CTF environments often rely on virtual host routing, accessing the server by IP alone may not return the intended content.
To address this, I added a local DNS entry mapping the target IP address to its corresponding hostname:
By appending this mapping to /etc/hosts, I forced my system to resolve monitorsfour.htb locally without relying on external DNS. This allows tools like the browser, curl, and fuzzers to correctly reach the application as it expects the proper Host header.
With hostname resolution in place, I will now be able to interact with the target using http://monitorsfour.htb, ensuring that subsequent enumeration and exploitation steps behaved as intended.
Nmap Enumeration
I began by performing an aggressive Nmap scan to enumerate open ports, running services, and underlying operating system details by running:
The scan identified only two open TCP ports, indicating a restricted external attack surface. Port 80 was running nginx and hosted a web application titled “MonitorsFour – Networking Solutions”, making it the primary target for further enumeration. A PHPSESSID cookie without the HttpOnly flag was observed and noted for potential relevance later.
Port 5985 was also open and mapped to WinRM (Microsoft HTTPAPI 2.0), confirming that the target is a Windows Server system. While not immediately exploitable, WinRM commonly becomes useful once valid credentials are obtained.
Web Enumeration
After identifying port 80 as open, I navigated to the target IP address 10.10.11.98 in the browser.
Accessing http://10.10.11.98 resulted in an automatic redirect to http://monitorsfour.htb, confirming that the application relies on virtual host routing and expects the correct hostname to be used. This validated the earlier /etc/hosts configuration and indicated that further web enumeration should be performed against the domain name rather than the raw IP address.
The landing page presents a corporate-style website branded “MonitorsFour”, advertising networking solutions. The navigation bar exposes several publicly accessible endpoints: Home, About Us, Services, and Pricing, along with a Login button. No immediate functionality is available on the public pages, suggesting that sensitive functionality may be gated behind authentication.
At this stage, the presence of a dedicated login portal stood out as a likely attack vector. With no obvious vulnerabilities visible on the landing page, the next step was to enumerate the login functionality and underlying web application behavior more closely.
Subdomain Enumeration
After identifying that the application relies on virtual host routing, I proceeded to enumerate potential subdomains using ffuf.
This approach brute-forces subdomains by fuzzing the Host header, allowing the detection of virtual hosts that may not be directly reachable through standard DNS resolution. Auto-calibration was enabled to filter out default responses and reduce false positives.
The scan returned a single valid result: cacti.monitorsfour.htb, which responded with an HTTP 302 redirect. Although the response body was empty, the redirect status confirmed that the subdomain exists and is actively handled by the web server.
The discovery of a Cacti subdomain was particularly interesting, as Cacti is a well-known network monitoring platform with a history of critical vulnerabilities. This finding significantly narrowed the attack surface and provided a clear direction for further enumeration.
With a valid subdomain identified, the next step was to add cacti.monitorsfour.htb to /etc/hosts and begin focused enumeration against this newly discovered service.
Hostname Configuration
After discovering the cacti subdomain during virtual host enumeration, I added a local hostname mapping to ensure proper name resolution when interacting with the service.
This forces my system to resolve cacti.monitorsfour.htb to the target IP address without relying on external DNS. Since the web server uses virtual host routing, accessing the application by IP alone would not return the intended content.
With the hostname configured, I was able to directly access http://cacti.monitorsfour.htb, allowing accurate enumeration of the Cacti application hosted on the target.
Cacti Web Access
With the cacti.monitorsfour.htb hostname properly configured, I navigated to the subdomain in the browser.
Accessing http://cacti.monitorsfour.htb redirected me to /cacti/index.php, presenting an authenticated Cacti login portal. This confirmed that the discovered subdomain is hosting a live instance of the Cacti network monitoring application, rather than static content or a placeholder virtual host.
The login page requires a username and password, indicating that further interaction with the application is gated behind authentication. The application version is clearly disclosed at the bottom of the page as Cacti v1.2.28, which is a critical finding, as version disclosure significantly narrows down potential attack vectors.
At this stage, the focus shifted toward identifying known vulnerabilities affecting this specific Cacti version, as well as assessing whether authentication could be bypassed or abused to gain initial access.
API Enumeration
After completing initial web and subdomain enumeration, I looked for hidden or undocumented API endpoints that might expose additional functionality. To do this, I used ffuf to fuzz common API paths on the main web application.
This scan brute-forced potential API routes using a custom wordlist, with auto-calibration enabled to reduce noise from default responses.
The scan identified two interesting endpoints under the /api/v1/ namespace. The first, /api/v1/auth, returned an HTTP 405 Method Not Allowed response, indicating that the endpoint exists but does not accept unauthenticated GET requests. This strongly suggests that the endpoint expects a different HTTP method (such as POST) and may be involved in authentication logic.
The second endpoint, /api/v1/user, responded with HTTP 200 OK, confirming that it is accessible and actively serving content. Although the response was minimal, the fact that it returned successfully without authentication made it a high-value target for further inspection.
The discovery of exposed API endpoints suggested that parts of the application’s backend logic are reachable directly, making API interaction a promising avenue for further exploitation.
API Data Disclosure
After identifying the exposed /api/v1/user endpoint, I manually interacted with it to understand how access control was being enforced. I issued a simple request using curl, supplying a token parameter with a value of 0.
Unexpectedly, the endpoint returned a full JSON response containing user records, without requiring authentication. The response included multiple user accounts, among them an administrator-level account, along with highly sensitive information such as usernames, email addresses, roles, authentication tokens, and hashed passwords.
Of particular interest was the admin user, who holds the role of super user. The disclosure of password hashes and associated tokens represents a critical security flaw, as this information can be leveraged for offline password cracking or direct authentication bypass, depending on how the backend validates tokens.
This confirmed the presence of an Insecure Direct Object Reference (IDOR) / Broken Access Control vulnerability, where a predictable token value grants unrestricted access to backend user data. With valid credentials and tokens now exposed, the next step was to attempt authentication against the Cacti login portal using the leaked information.
Password Hash Cracking
From the exposed API response, I obtained a password hash associated with the admin account (admin@monitorsfour.htb). The hash format appeared to be unsalted and consistent with common hashing algorithms, making it a good candidate for offline cracking.
To quickly validate this, I submitted the hash to CrackStation, a public hash-cracking service that leverages large precomputed wordlists and rainbow tables.
CrackStation successfully identified the hash as MD5 and resolved it to the plaintext password:
Cacti Authentication
With a valid plaintext password recovered from the leaked API data, I attempted to authenticate to the Cacti login portal. My first attempt used the obvious combination admin:wonderful1, however this did not succeed, indicating that the Cacti username did not directly match the email prefix.
Using the additional profile information exposed by the API, specifically the administrator’s name Marcus Higgins and email address, I tested a small set of plausible username variations derived from the real name.
After a few attempts, authentication was successful using the following credentials:
This confirmed that the Cacti instance was configured with a local username that differed from the email address used elsewhere in the application. With valid administrative access now obtained, the attack surface expanded significantly, enabling authenticated enumeration and exploitation within the Cacti application.
Vulnerability Identification
After successfully authenticating to the Cacti dashboard, I revisited the application details identified earlier during enumeration. The login page explicitly disclosed that the instance was running Cacti v1.2.28, which immediately narrowed the scope for vulnerability research.
A review of known issues affecting this version revealed CVE-2025-24367, a critical vulnerability impacting Cacti versions ≤ 1.2.28. This flaw allows remote code execution (RCE) through command injection in the Graph Template functionality. The root cause is improper sanitization of user-supplied input that is ultimately passed to the rrdtool utility, enabling attackers to inject and execute arbitrary system commands.
The vulnerability is particularly impactful in this context because it requires authenticated access, which had already been obtained. A publicly available proof-of-concept exploit exists and demonstrates reliable exploitation of this issue:
With a confirmed vulnerable version, valid administrative access, and a working public PoC, this vulnerability presented a clear and reliable path to achieving remote code execution on the target system. The next step was to weaponize this flaw to gain an initial shell.
Exploit Preparation
With a confirmed vulnerable Cacti version and a public proof-of-concept available, I prepared the exploit locally. I began by cloning the PoC repository to my attacking machine and navigating into the project directory.
This repository contains a ready-to-use exploit targeting CVE-2025-24367, which abuses command injection in Cacti’s Graph Template functionality to achieve remote code execution. Having the exploit code available locally allowed me to review its behavior and prepare it for execution against the authenticated Cacti instance.
With the exploit environment set up, the next step was to configure the PoC and launch it against the target to obtain a foothold on the system.
Remote Code Execution (Foothold)
With the exploit prepared and valid Cacti credentials in hand, I set up a listener on my attacking machine to catch an incoming reverse shell.
I then executed the public proof-of-concept exploit from the cloned repository, supplying the target URL, authenticated Cacti credentials, and my local IP address and listening port for the callback.
The exploit confirmed the presence of a vulnerable Cacti instance and successfully authenticated using the provided credentials. It then abused the Graph Template functionality to inject a malicious payload, resulting in the creation of temporary PHP files on the target. After triggering the payload, the exploit indicated that the request had timed out, which is expected behavior when a reverse shell is successfully executed.
Shortly afterward, my netcat listener received an inbound connection from the target system, confirming successful remote code execution. The shell landed as the www-data user inside the Cacti web directory, providing an initial foothold on the machine.
Obtaining the User Flag
After gaining an initial shell on the target, I first confirmed the context of my access. Running basic identification commands showed that the shell was operating as the low-privileged www-data user, which is typical for web-based exploitation and confirmed that I had not yet escalated privileges.
I then enumerated the /home directory to identify valid local users on the system. This revealed a home directory for the user marcus, which aligned with the credentials previously used to access the Cacti application.
Navigating into /home/marcus, I found the standard user environment files along with a readable user.txt file. Since this file was world-readable, it could be accessed directly from the www-data shell.
Reading the contents of user.txt successfully revealed the user flag, confirming completion of the user-level objective on the machine.
Hurray!!! I got the user flag
With the user flag obtained, the next step was to focus on local enumeration and privilege escalation in order to gain root access.
Environment Enumeration
After obtaining the user flag, I continued with basic system enumeration to better understand the execution environment and identify potential privilege escalation paths.
I first checked the system hostname, which returned a random-looking identifier rather than a meaningful machine name. This immediately suggested that the shell was running inside a containerized environment, rather than directly on the host system.
To confirm this, I inspected the network configuration. The system was assigned an internal IP address in the 172.18.0.0/16 range, which is commonly used by Docker bridge networks. The default gateway pointed to 172.18.0.1, further reinforcing the conclusion that this instance is operating within a container.
At this point, it became clear that the Cacti application and the obtained shell were running inside a Docker container, not directly on the underlying host. This distinction is important, as it changes the post-exploitation strategy: instead of traditional local privilege escalation, the focus shifts toward container escape, misconfigurations, or access to host-mounted resources.
With confirmation that I was inside a container, the next step was to enumerate mounted volumes, running processes, and container permissions to determine whether escaping to the host system was possible.
Docker Host Enumeration
After confirming that the shell was running inside a Docker container, I attempted to determine whether the underlying Docker daemon was exposed to the container. An exposed Docker API is a common misconfiguration and can often be abused to escape the container and gain access to the host.
I first tried querying the Docker API directly via the default bridge gateway at 172.18.0.1 on port 2375, which is commonly used when the Docker daemon is exposed over HTTP.
This attempt failed, indicating that the Docker API was not accessible through the bridge gateway.
I then tried accessing the Docker host using the special hostname host.docker.internal, which is sometimes configured to resolve to the host system from within a container.
The hostname resolved successfully, but the connection was explicitly refused. This confirmed that, even if the hostname is reachable, the Docker daemon is not listening on port 2375, or is properly firewalled from container access.
These results ruled out an exposed Docker API as an immediate container escape vector. With this avenue closed, the focus shifted toward other container breakout techniques, such as examining mounted volumes, privileged container settings, or credentials that could be reused on the host system.
Docker Socket Discovery
After confirming that the shell was running inside a Docker container, I continued enumerating for common container escape vectors. One of the first checks was to see whether the Docker socket was mounted inside the container, as access to docker.sock would allow direct control over the Docker daemon and lead to immediate host compromise.
I first checked the default socket location:
No socket was present, and a filesystem-wide search confirmed that docker.sock was not mounted anywhere inside the container. This ruled out the most straightforward container escape technique.
Since the Docker socket was not locally accessible, I shifted focus to identifying whether the Docker daemon was exposed remotely on the internal Docker network. Docker hosts sometimes expose the API on port 2375, which can be abused if reachable from within a container.
To test this, I performed a lightweight sweep of the internal subnet, attempting to connect to port 2375 and checking for a valid Docker API response:
This scan identified a single responsive host:
The response confirmed that a Docker API endpoint was accessible over the network, indicating that the Docker daemon was exposed without authentication. This finding represented a critical misconfiguration, as access to the Docker API typically allows attackers to create privileged containers, mount the host filesystem, and execute commands as root on the host.
With a reachable Docker API now identified, the next step was to interact directly with the daemon and leverage it to escape the container and gain root-level access on the host system.
Docker API Enumeration
After identifying an exposed Docker API on 192.168.65.7:2375, I verified access by querying the daemon directly.
The request returned detailed version information from the Docker daemon, confirming that the API was fully accessible without authentication. The response showed a running Docker Engine Community instance, along with kernel and build details, definitively confirming control over the Docker service from within the container.
With confirmed access to the Docker API, I proceeded to enumerate available images on the host to understand the environment and identify potential targets for container abuse.
This revealed several locally available images, including:
docker_setup-nginx-php:latest- docker_setup-mariadb:latest
- alpine:latest
The presence of a minimal Alpine Linux image was particularly useful, as it provides a lightweight base for spinning up a new container. More importantly, unrestricted access to the Docker API meant I could create a new container with arbitrary settings such as mounting the host filesystem or running in privileged mode, making host escape and root compromise trivial.
With full Docker API control confirmed and suitable images available, the next step was to abuse the daemon to launch a malicious container and gain root access on the host system.
Malicious Container Preparation
With unrestricted access to the Docker API confirmed, the next objective was to abuse it to read sensitive files directly from the host system. To do this, I prepared a custom Docker container definition that would mount the host filesystem and execute a command to retrieve the root flag.
I created a JSON payload defining a new container based on the lightweight Alpine image. The container was configured to bind-mount the host’s filesystem and execute a command that reads the root.txt file from the Administrator’s desktop:
Since the compromised container did not have direct access to this file, I hosted the JSON payload on my attacking machine using a simple Python HTTP server:
From inside the compromised Cacti container, I then downloaded the container configuration file:
This allowed me to stage the malicious container definition inside the environment that already had network access to the exposed Docker API. With the payload now in place, the final step was to submit this configuration to the Docker daemon, spawn the container, and retrieve the root flag from the host filesystem.
Abusing the Docker API to Retrieve the Root Flag
With the malicious container configuration staged locally, the final step was to interact directly with the exposed Docker API to create and execute the container on the host system.
I first sent a POST request to the Docker daemon’s /containers/create endpoint, supplying the previously crafted container.json payload. This instructed Docker to create a new container named pwned, based on the Alpine image and configured to mount the host filesystem:
The API responded with a container ID, confirming that the container had been successfully created on the host.
Next, I started the container using its ID:
Since the container was configured to immediately execute a command rather than spawn an interactive shell, it ran, completed its task, and exited silently.
To retrieve the output, I queried the container logs:
The response contained the contents of the root.txt file:
At this point, full system compromise was achieved. By abusing an unauthenticated Docker API and bind-mounting the host filesystem, I was able to escape the container boundary and read arbitrary files from the host, ultimately obtaining the root flag.
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee
Search Keywords:
MonitorsFour Hack the Box Writeup
MonitorsFour Hack the Box Machine Writeup
MonitorsFour Hack the Box Walkthrough
MonitorsFour Hack the Box Machine Walkthrough
MonitorsFour HTB Writeup
MonitorsFour HTB Walkthrough
MonitorsFour HTB Machine Walkthrough
MonitorsFour HTB Machine Writeup
MonitorsFour Hack the Box HTB Machine Walkthrough Writeup
MonitorsFour HTB Solution
MonitorsFour Hack the Box Solution
MonitorsFour Hack the Box Complete Walkthrough
MonitorsFour Hack the Box Complete Writeup
MonitorsFour Hack the Box Complete Solution
MonitorsFour htb write up
HackTheBox MonitorsFour Writeup
HTB MonitorsFour Writeup
HackTheBox MonitorsFour Writeup
HackTheBox - MonitorsFour (Writeup)
HTB Writeups - MonitorsFour
HackTheBox MonitorsFour Writeup
MonitorsFour | HTB Writeup | Linux
MonitorsFour htb
HTB - MonitorsFour Writeup
Owned MonitorsFour from Hack The Box
Hack The Box - HTB MonitorsFour Writeup
HTB MonitorsFour Detailed Writeup English
HackTheBox | MonitorsFour HackTheBox · HackTheBox | MonitorsFour
MonitorsFour HTB Writeup | HacktheBox | Season 9
HTB Writeup - MonitorsFour
Write-ups Category Posts | Hack The Box Blog
MonitorsFour - Hack the Box - Walkthrough
MonitorsFour - HTB - Walkthrough
MonitorsFour - Hack the Box - Writeup
0 Comments