Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Interpreter machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs.
About the Machine
Interpreter is a Medium-difficulty Linux machine on Hack the Box that chains together exposed enterprise middleware, unauthenticated remote code execution, credential harvesting from backend configuration, PBKDF2 hash cracking, and a Python eval()-based privilege escalation in a locally exposed Flask service.
The attack began with web enumeration, where I discovered an exposed Mirth Connect 4.4.0 instance. After identifying that the version was vulnerable to CVE-2023-43208 (Unauthenticated Remote Code Execution), I successfully gained initial access via a reverse shell as the application service account.
From there, the engagement evolved into a deeper post-exploitation exercise:
- Extracted plaintext database credentials from application configuration files
- Authenticated to a local MariaDB instance
- Retrieved a PBKDF2-HMAC-SHA256 password hash (600,000 iterations)
- Reconstructed and cracked the hash using Hashcat
- Achieved lateral movement via SSH as a legitimate system user
The final privilege escalation required source code analysis of a custom root-owned Flask service. The service unsafely used eval(f"..."). By leveraging f-string expression injection, I achieved arbitrary code execution as root and completed the machine.
This machine rewards methodical enumeration, source code analysis, and understanding of Python f-string evaluation internals.
The first step in owning the Interpreter machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:
Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the Interpreter machine and I was assigned an IP address (10.129.8.152).
Nmap Enumeration
I began my reconnaissance by running an aggressive Nmap scan to identify open ports, service versions, and operating system details.
The scan confirmed that the host was up with a latency of approximately 0.19 seconds. Out of the 1000 scanned TCP ports, only three were open: 22 (SSH), 80 (HTTP), and 443 (HTTPS). The remaining ports were closed, which indicated a relatively limited external attack surface.
Port 22 was running OpenSSH 9.2p1 (Debian 12). The version string strongly suggested that the underlying operating system was Debian-based, most likely Debian 12 (Bookworm). Since the SSH version appeared modern and fully patched, I noted it for potential credential reuse later rather than immediate exploitation.
Ports 80 and 443 were both serving a Jetty web server. The page title revealed the application as “Mirth Connect Administrator.” This immediately became the primary focus of my attack surface, as Mirth Connect is an enterprise integration engine that has historically been associated with authentication bypasses and remote code execution vulnerabilities.
The HTTP enumeration scripts also revealed that the TRACE method was enabled, which can sometimes indicate insecure configuration. While not immediately exploitable, it is generally considered a risky method and worth noting.
On port 443, I observed a self-signed SSL certificate with the common name mirth-connect, valid for 50 years (2025–2075). The unusually long validity period suggested that this was a default-generated certificate, reinforcing the likelihood that the service was minimally hardened.
Web Enumeration
After identifying ports 80 and 443 during my Nmap scan, I proceeded to manually enumerate the web service by visiting the target IP address in my browser.
Upon accessing the page, I was automatically redirected to:
The redirection revealed that the application was exposing the Mirth Connect Administrator interface. The landing page displayed branding for NextGen Healthcare – Mirth Connect, confirming that the service identified during Nmap enumeration was indeed accessible through the web interface.
The page presented two primary options:
- Launching the Mirth Connect Administrator
- Accessing the Web Dashboard (HTTPS required)
The presence of /webadmin/Index.action suggested that the application was likely using a Java-based framework (such as Struts, given the .action extension), which immediately caught my attention from an attack surface perspective.
Additionally, the page explicitly mentioned the use of a self-signed certificate, which aligned with the SSL findings from my Nmap scan. This reinforced the assumption that the service was running in a default or minimally hardened configuration.
At this stage, I had confirmed:
- The application was publicly accessible.
- The administrative interface was directly exposed.
- The application relied on a Java-based backend.
- HTTPS was available but not strictly enforced for the initial access.
Since this was an administrative portal rather than a public-facing user interface, I shifted my focus toward version enumeration and vulnerability research targeting Mirth Connect, particularly looking for authentication bypasses or remote code execution vulnerabilities that could provide initial access.
Host Resolution Configuration
To streamline further enumeration and avoid repeatedly referencing the target by IP address, I added a local host entry mapping the machine’s IP to a custom hostname.
By appending this entry to /etc/hosts, I ensured that my system would resolve interpreter.htb directly to 10.129.8.152. This approach is particularly useful when dealing with web applications that may rely on virtual host routing or hostname-based access controls.
Using a hostname instead of the raw IP address not only keeps commands cleaner but also allows me to test for potential host header–based behavior during web enumeration.
With name resolution configured, I continued interacting with the target using interpreter.htb moving forward.
Version Enumeration
After identifying the exposed Mirth Connect Administrator interface, I proceeded by clicking “Launch Mirth Connect Administrator.” This action downloaded a webstart.jnlp file to my system.
Upon inspecting the contents of the file, I immediately identified the application version.
The version="4.4.0" attribute clearly revealed that the target was running Mirth Connect 4.4.0. This was a critical finding, as a quick vulnerability search confirmed that version 4.4.0 is vulnerable to CVE-2023-43208, an unauthenticated remote code execution vulnerability patched in version 4.4.1.
With a confirmed vulnerable version, I shifted to exploit research.
Exploit Acquisition
After searching for publicly available Proof-of-Concept code, I located a GitHub repository containing an exploit for the vulnerability. I cloned the repository to my local machine.
Once cloned, I navigated into the directory to review its contents.
The repository contained:
CVE-2023-43208.py- CVE-2023-37679.py
- detection.py
- README.md
Before launching the exploit, I first verified whether the target was indeed vulnerable using the detection script.
Vulnerability Verification
The script responded:
This confirmed that the instance was both running version 4.4.0 and exploitable.
Remote Code Execution
With confirmation in place, I proceeded to test command execution by issuing a harmless command that would create a file on the target system.
The script returned:
This indicated successful remote command execution.
To further validate execution behavior, I tested another payload:
Again, the exploit reported successful execution.
At this point, I had confirmed unauthenticated remote code execution against the target via CVE-2023-43208. The Mirth Connect instance was fully exploitable, providing a reliable foothold for obtaining an interactive shell and proceeding with post-exploitation activities.
Initial Access - Reverse Shell
After confirming remote command execution via CVE-2023-43208, I proceeded to obtain an interactive shell.
First, I set up a Netcat listener on my attacking machine to receive the reverse connection:
With the listener waiting, I executed a reverse shell payload using the exploit script from the cloned repository:
Shortly after running the command, my Netcat listener received a connection from the target:
This confirmed successful remote code execution and reverse shell callback.
Shell Stabilization
To verify the context of the shell, I ran:
The output revealed:
I had gained access as the mirth service account, which corresponds to the Mirth Connect application user.
Since the shell was initially non-interactive, I upgraded it to a fully interactive TTY for better usability:
This provided a proper bash shell, allowing me to navigate the filesystem more comfortably.
Post-Exploitation Enumeration
I began by inspecting the application directory:
The output showed the full Mirth Connect installation structure under /usr/local/mirthconnect, including directories such as:
conf/- logs/
- extensions/
- server-lib/
- webapps/
- custom-lib/
This confirmed that I was inside the application’s installation directory and operating with the privileges of the service account responsible for running Mirth Connect.
At this stage, I had successfully transitioned from unauthenticated web exploitation to a stable shell on the system as the mirth user. The next step was to begin deeper local enumeration to identify sensitive configuration files, credentials, or privilege escalation vectors.
Credential Discovery - Application Configuration Review
After obtaining a stable shell as the mirth user, I began enumerating the application’s configuration files in search of sensitive information such as credentials or connection details.
From the Mirth Connect installation directory, I inspected the main configuration file:
While reviewing the contents of mirth.properties, I identified several important configuration parameters. Most notably, the file contained cleartext database credentials:
This confirmed that:
- The backend database was MariaDB/MySQL
- The database was hosted locally on
localhost - The database name was
mc_bdd_prod - The credentials were exposed in plaintext within the configuration file
The presence of hardcoded credentials inside a world-readable configuration file is a common misconfiguration and immediately presented an opportunity for lateral movement within the system.
Database Access
Using the discovered credentials, I attempted to authenticate to the local MariaDB instance directly from the compromised host.
When prompted for the password, I entered:
The authentication succeeded, and I was presented with the MariaDB monitor:
This confirmed several key points:
- The database server was running locally.
- The credentials were valid.
- The
mirthuser had sufficient privileges to access the application database.
At this stage, I had moved from remote code execution as a service account to authenticated access to the application’s backend database. The next logical step was to enumerate database tables for stored credentials, API keys, or other sensitive information that could potentially lead to privilege escalation or lateral movement to another user on the system.
Database Enumeration - Credential Extraction
After gaining access to the MariaDB instance, I began enumerating the database for potentially sensitive information. Since this was an application database, I expected to find stored user credentials.
From within the mc_bdd_prod database shell, I executed the following query to extract usernames and their associated password hashes:
The query returned:
This revealed a user named sedric along with what appeared to be a Base64-encoded password hash.
Hash Analysis
Back on my Kali machine, I began analyzing the extracted value. First, I decoded the Base64 string and examined its raw hexadecimal representation:
This produced:
The structure of the decoded output suggested the format:
I separated the first 16 bytes (salt) from the remaining bytes (hash) and re-encoded them into Base64 format:
The format strongly resembled a PBKDF2-HMAC-SHA256 hash, which is commonly used by Java-based applications. Based on this structure, I prepared the hash in Hashcat format:
The 600000 iteration count is typical of modern PBKDF2 implementations.
Hash Cracking
To crack the hash, I used Hashcat with mode 10900 (PBKDF2-HMAC-SHA256):
After running through the RockYou wordlist, Hashcat successfully recovered the password:
The password for user sedric was:
At this stage, I had successfully:
- Extracted user credentials from the backend database
- Identified the hashing mechanism
- Converted the stored value into crackable format
- Recovered the plaintext password
With valid credentials for sedric, the next logical step was to attempt authentication via SSH, potentially transitioning from a service account (mirth) to a legitimate system user.
Lateral Movement - SSH Access as sedric
After successfully cracking the PBKDF2 hash and recovering the plaintext password snowflake1, I attempted to authenticate to the target over SSH as the user sedric.
To streamline the login process, I used sshpass to supply the recovered password non-interactively:
The connection was successful. This confirmed that:
- The credentials were valid.
sedricwas a legitimate system user.- SSH password authentication was enabled.
After logging in, I verified my access by listing the contents of the home directory:
The directory contained a single file:
I proceeded to read the file:
Which revealed the user flag:
At this stage, I had successfully moved from remote code execution as a service account (mirth) to authenticated access as a real system user (sedric) and captured the user flag. The next objective was to enumerate the system further for privilege escalation opportunities in pursuit of root access.
Process Enumeration
After obtaining SSH access as sedric and capturing the user flag, I began standard post-exploitation enumeration to identify potential privilege escalation vectors.
One of the first checks I performed was reviewing running processes, specifically looking for Python scripts that might be custom, misconfigured, or writable.
The output revealed several Python processes running as root:
The first process, fail2ban-server, is a legitimate and expected security service used to prevent brute-force attacks. It was unlikely to be directly exploitable without additional misconfigurations.
However, the second process immediately caught my attention:
This indicated that a Python script named notif.py located in /usr/local/bin/ was running as root. Unlike fail2ban, this appeared to be a custom script rather than a standard system service.
The presence of a custom root-executed Python script is a strong indicator of a potential privilege escalation vector. If the file is writable by a lower-privileged user or improperly secured, it could allow code injection and execution as root.
The third Python process belonged to the mirth user and was simply the upgraded shell I previously spawned, which I could safely ignore.
At this stage, /usr/local/bin/notif.py became my primary focus. The next logical step was to inspect its file permissions and contents to determine whether it could be leveraged to escalate privileges to root.
Privilege Escalation Enumeration - Analysis of notif.py
After identifying the root-owned Python process /usr/local/bin/notif.py, I proceeded to inspect its contents to understand its functionality and assess whether it could be abused for privilege escalation.
The script revealed a locally running Flask-based notification server designed to process XML messages containing patient information. According to the header comments, the service listens on 127.0.0.1:54321 and is intended to accept requests only from Mirth Connect running on the same machine.
Key observations from the source code:
The Flask app listens only on 127.0.0.1:
It restricts access to local requests:
It parses incoming XML and extracts specific tags:
firstname- lastname
- sender_app
- timestamp
- birth_date
- gender
It writes formatted notifications to:
At first glance, the script attempts to validate user input using a restrictive regex pattern:
However, the most critical finding was inside the template() function:
This is a major red flag.
Even though the script performs regex validation, it ultimately passes user-controlled input into an eval() call wrapped inside an f-string. Using eval() on dynamically constructed input is inherently dangerous, especially in a root-executed process.
Because the service runs as root and evaluates formatted strings, any way to inject executable Python expressions into that evaluated string could result in arbitrary code execution as root.
Attack Surface Analysis
The security controls implemented in the script attempt to:
- Restrict access to localhost only.
- Enforce a strict character whitelist.
- Validate date-of-birth format.
- Limit input to specific XML fields.
However:
- The regex explicitly allows
{and}characters. - The template string is processed through
eval()as an f-string. - The application writes files as root.
Since f-strings evaluate expressions inside {}, and those braces are permitted by the regex, this immediately suggested a potential expression injection vulnerability.
Because the service runs locally on port 54321 and only accepts requests from 127.0.0.1, it cannot be accessed remotely but as a local user (sedric), I could interact with it directly.
At this point, the notification service became the primary privilege escalation vector. The combination of:
- Root execution context
- User-controlled input
- Unsafe
eval()usage
strongly indicated that this was the intended path to escalate privileges from sedric to root.
Local Service Interaction - Notification Endpoint Testing
After reviewing the source code of notif.py and identifying the locally running Flask application on 127.0.0.1:54321, I decided to manually interact with the service to better understand its behavior.
Since the endpoint only accepts requests originating from 127.0.0.1, I crafted a simple Python script to send a POST request containing properly formatted XML data.
The server responded with:
This confirmed several important points:
- The service was actively running and reachable locally.
- XML parsing was functioning correctly.
- The
template()function was processing user-supplied fields. - The output format matched the f-string logic observed in the source code.
- The service executed successfully under root privileges.
The calculated age (26 years old) demonstrated that the application dynamically computed the age from the supplied birth date, further confirming that user-controlled values were being passed into a formatted string that was evaluated at runtime.
At this stage, I had validated that:
- I could interact with the service locally.
- The input validation was active.
- The f-string evaluation logic was functioning exactly as implemented in the source code.
With successful interaction confirmed, the next step was to determine whether the f-string eval() usage could be abused to inject arbitrary Python expressions and ultimately execute code as root.
Privilege Escalation - Exploiting eval() Injection
After confirming that the local notification service was functioning as expected, I proceeded to test whether the unsafe eval() usage inside the template() function could be abused.
From reviewing the source code earlier, I observed that:
- User-controlled input was inserted into an f-string.
- The final string was passed directly to
eval(). - The regex filter allowed
{and}characters. - The service was running as root.
Since f-strings evaluate expressions inside {}, I crafted a payload that injected a Python expression into the firstname field. Specifically, I attempted to read the root flag directly:
The server responded with:
Instead of printing the literal string {open("/root/root.txt").read()}, the application evaluated the expression inside the braces. Because the service runs as root, it successfully opened and read /root/root.txt, embedding its contents directly into the response.
This confirmed full arbitrary code execution as root via f-string expression injection.
The vulnerability stemmed from this line in the source code:
By injecting a Python expression inside {}, I was able to execute arbitrary Python code within a root-privileged context.
At this stage, I had successfully escalated privileges and retrieved the root flag, completing the machine.
Hurray!!! I got the user flag
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee
Found this walkthrough helpful?
Buying me a coffee helps power the late nights spent writing technical walkthroughs and keeping them free for everyone ☕
Keywords:
interpreter htb write up
interpreter htb walkthrough
owned interpreter from hack the box
interpreter.htb
interpreter hack the box write up
interpreter hack the box walkthrough
hackthebox interpreter
eighteen writeup htb
gavel htb
eighteen hackthebox
hack the box eighteen
gavel htb writeup
eighteen hack the box
eighteen hackthebox writeup
eighteen walkthrough htb
gavel writeup
htb gavel writeup
hackthebox eighteen walkthrough
eighteen hack the box walkthrough
hack the box eighteen walkthrough
hackthebox eighteen
eighteen.htb
eighteen.htb writeup
eighteen write up
eighteen htb write up
htb gavel walkthrough
"eighteen.htb"
eighteen hackthebox walkthrough
hack the box eighteen writeup
0 Comments