MonitorsFour
Target Overview MonitorsFour is a Linux-based Hack The Box machine that chains multiple vulnerabilities to achieve full system compromise. The path begins with a publicly exposed .env file leaking database credentials, followed by a broken API endpoint that returns all user records — including hashed passwords — without any authentication. Cracking the admin hash and reusing credentials across services led to authenticated access on a Cacti monitoring instance. Exploitation of CVE-2025-24367 provided remote code execution inside a Docker container. From there, an unauthenticated Docker Engine API exposed on the internal network was leveraged to escape the container and land root on the host. --- Enumeration The scan revealed two open ports with all others filtered: Port 80 – HTTP (nginx) nginx is running on port 80 and redirects to http://monitorsfour.htb/, confirming a virtual host setup. Port 5985 – WinRM (Microsoft HTTPAPI 2.0) WinRM is accessible and becomes relevant if valid credentials are obtained during enumeration. Setting Up Host Mapping Before starting enumeration, the target hostname was added to /etc/hosts: --- Directory Enumeration Two notable results stood out immediately: /.env — returned HTTP 200. A publicly accessible environment file is a critical information disclosure finding. /user — a potential user-data API endpoint worth probing further. --- Sensitive Information Disclosure Fetching the exposed .env file directly: The file exposed database credentials in plaintext. Environment files must never be web-readable — they are intended for server-side use only and commonly contain secrets, API keys, and database passwords. Broken API — Full User Data Dump Probing the /user endpoint revealed it expected a token parameter: Supplying any arbitrary token value returned the full user table without any authorization check: Url: https://crackstation.net/ Please find the reference URL. An arbitrary token value returned all user records — including usernames, password hashes, email addresses, roles, dates of birth, and salary data. The admin account hash was immediately visible in the response. --- Password Hash Cracking The admin MD5 hash was submitted to CrackStation for cracking: | Username | Hash | Password | Role | |----------|------|----------|------| | admin | 56b32eb43e6f15395f6c46c1c9e1cd36 | wonderful1 | super user | MD5 is a checksum function, not a password hashing algorithm. Passwords must be stored using bcrypt, argon2id, or scrypt with a per-user salt. --- Authenticated Access & vHost Discovery Logging in at http://monitorsfour.htb/login with admin : wonderful1 granted access to the admin panel. With a valid session, vHost fuzzing was run to discover additional subdomains: A new virtual host, cacti.monitorsfour.htb, was discovered and added to /etc/hosts: image Accessing http://cacti.monitorsfour.htb/cacti/ presented a Cacti login page. The admin credentials were invalid here, but another user from the API leak — marcus — authenticated successfully via credential reuse with the same password wonderful1. --- Initial Access — CVE-2025-24367 (Cacti RCE) Vulnerability Details: CVE-2025-24367 is a command injection flaw in Cacti's Graph Template field that passes unsanitized user input directly to the rrdtool utility, enabling authenticated remote code execution. Affected versions: Cacti ≤ 1.2.28. A public PoC is available at TheCyberGeek/CVE-2025-24367-Cacti-PoC on GitHub. The Cacti version post-login was confirmed as 1.2.28, placing it squarely in the vulnerable range. image With a netcat listener ready on port 1337: A reverse shell was received. The initial shell landed inside a Docker container. --- User Flag --- Privilege Escalation via Docker API Escape Confirming Container Context After landing a shell, a few quick checks confirmed we were inside a Docker container rather than the bare host: The 172.18.0.0/16 range is the default Docker bridge subnet. The gateway 172.18.0.1 is the Docker host itself from the container's perspective. Discovering the Exposed Docker Engine API The Docker Engine API runs on TCP port 2375 (unauthenticated) or 2376 (TLS). When exposed on the network without authentication, it gives complete control over the Docker daemon — and by extension, the host itself. Checking the routing table, a 192.168.65.0/24 network was accessible from within the container. A quick sweep of all 254 hosts on that subnet for an open port 2375: The Docker API was found alive at 192.168.65.7:2375 — unauthenticated and fully accessible from within the container. The response confirmed Docker Engine v28.3.2 running with no authentication required. An unauthenticated Docker Engine API on :2375 is equivalent to unrestricted root access to the host. Anyone who can reach this port can create privileged containers, mount the host filesystem, and execute arbitrary commands as root. Enumerating Available Docker Images alpine:latest is the ideal candidate — minimal Linux image, shell available, starts instantly with no application-level dependencies. Crafting and Deploying the Escape Container A JSON container spec was crafted that mounts the host's root drive into the new container and reads the root flag directly: The Binds field in HostConfig instructs Docker to bind-mount a path from the host into the new container. Since the Docker daemon runs as root on the host, it can mount any host path regardless of container-level permissions. This is why an exposed Docker API is so dangerous. Create the container via the API: Start the container: A successful start returns HTTP 204 No Content. Retrieve the output logs: The root flag was returned in the container stdout. Host fully compromised. --- Root Flag ```