Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I pwned the Outbound 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
Outbound is an Easy Linux machine that demonstrates a realistic web → creds → SSH → local-privilege escalation chain. The box hosts a Roundcube webmail instance on port 80 (mail.outbound.htb) vulnerable to CVE-2025-49113, which allows an attacker to gain a www-data shell. From the webroot, configuration and database credentials (and the Roundcube des_key) are recovered, enabling decoding of session blobs to extract user credentials (e.g., jacob / tyler) and pivot to SSH for user-level access. Local escalation stems from a NOPASSWD sudo policy for the monitoring tool below and CVE-2025-27591 (writable-log symlink injection), which allows an attacker to inject a root account and obtain the root flag. Outbound is a compact, instructional box highlighting the dangers of unpatched webapps, exposed session/storage secrets, poorly owned log directories, and overly-permissive sudo rules.
The first step in pwning the Outbound 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 Outbound machine and I was assigned an IP address (10.10.11.77)
After identifying the target IP 10.10.11.77, I began my initial enumeration phase using an aggressive Nmap scan to gather as much information as possible about the running services and operating system. I ran the following command:
The scan revealed two open TCP ports:
- Port 22 (SSH) - Running OpenSSH 9.6p1 on Ubuntu, which indicates a relatively recent version. Since SSH is commonly used for remote administration, it’s worth noting but not immediately exploitable without valid credentials or a known vulnerability.
- Port 80 (HTTP) - Running nginx 1.24.0 on Ubuntu. The HTTP service immediately redirected to
http://mail.outbound.htb/, revealing a potential virtual host (mail.outbound.htb) that could lead to additional web content or subdomain enumeration opportunities.
From this initial enumeration, the key takeaway is that the machine hosts a web service on mail.outbound.htb. This will likely serve as our next point of investigation, exploring the website’s content, performing virtual host enumeration, and looking for any web-based entry points.
With the Nmap output pointing us to an HTTP service that redirects to http://mail.outbound.htb/, I treated that virtual host as the primary attack surface and started web enumeration.
1) Make the virtual host resolvable locally
First, I added the host to /etc/hosts so my browser and tools resolve mail.outbound.htb to the target IP.
This lets me request the site exactly as the server expects (important for name-based virtual hosts).
I ran nuclei against http://mail.outbound.htb/ to quickly surface known vulnerabilities and misconfigurations:
Nuclei identified the site as running Roundcube 1.6.10 and raised a critical match for CVE-2025-49113, so I flagged the Roundcube instance for immediate follow-up and CVE research. The scanner also discovered an exposed log at roundcube/logs/errors.log, a medium severity finding and returned a matched snippet, so I fetched the file manually. Additional findings included missing security headers and cookies lacking the Secure/SameSite attributes, along with an nginx server banner and the SSH banner OpenSSH_9.6p1.
Together, these results focused my next steps:
- Manually review the exposed error log for credentials or internal paths
- Research the CVE and test it safely if a working PoC exists, and
- Enumerate Roundcube config files and any uploaded artifacts for credentials that could be used to pivot to SSH or the database.
CVE-2025-49113
The Nuclei scan pointed me at Roundcube 1.6.10 and flagged CVE-2025-49113, so I searched for a public proof-of-concept and found a GitHub PoC.
I cloned the GitHub repository on my attacker machine by running:
After cloning the repository, I executed the exploit against the mail virtual host:
The script confirmed the target Roundcube version (10610) and reported the target as vulnerable. It even printed Login successful! and started the exploit. During execution the PoC emitted this warning:
That indicates the PoC failed to upload whatever payload it tried via one particular HTTP request (the script attempted a file upload and that request returned an error). Despite that specific error the exploit still succeeded in getting a reverse shell - a sign the PoC probably tried multiple techniques and one of them worked or the server responded in a way that still triggered command execution.
I had a netcat listener running on my machine (nc -lvnp 4444) and immediately after running the PoC it connected back:
So, I obtained an interactive shell as the www-data user on the target. After the connection landed, I confirmed my privileges and environment:
This confirmed the shell was running as the webserver user (www-data), which is a common low-privilege foothold on web hosts. I then enumerated the filesystem from the root to look for the webroot and application files:
Navigating to the Roundcube installation revealed the application directory:
Inside the config directory I found config.inc.php and read it:
Two clear secrets stood out:
- Database credential:
roundcube:RCDBPass2025(MySQL userroundcube, passwordRCDBPass2025). Location:$config['db_dsnw']- this is the DSN used by Roundcube to connect to its database. - Session encryption key:
rcmail-!24ByteDESkey*Str.Location:$config['des_key']- used by Roundcube to encrypt IMAP passwords stored in sessions and possibly other sensitive material.
The DB credentials gave me a direct route to the Roundcube database, while the DES key could be used to decrypt any IMAP passwords Roundcube stores - together, these artifacts provided a clear escalation path (dump the DB, recover/decrypt mail credentials, and pivot further).
Using these credentials, I attempted to connect to the local MySQL service:
After entering the password RCDBPass2025, I successfully accessed the Roundcube database. To explore its structure, I selected the database and queried two key tables: users and session, which often contain stored credentials, session tokens, or encoded user data:
The users table revealed three active accounts within the Roundcube webmail application:
| user_id | username | mail_host | created | last_login |
|---|---|---|---|---|
| 1 | jacob | localhost | 2025-06-07 13:55:18 | 2025-06-11 07:52:49 |
| 2 | mel | localhost | 2025-06-08 12:04:51 | 2025-06-08 13:29:05 |
| 3 | tyler | localhost | 2025-06-08 13:28:55 | 2025-10-23 07:15:00 |
Among these, tyler stood out as the most recently active user - a strong indicator that this account might belong to a real system user rather than just a default Roundcube account.
Next, I examined the session table, which contained encoded session data for these users. Within these entries, I noticed several Base64-like strings and serialized PHP objects, storing IMAP session variables and encrypted password data. Specifically, one of the sessions belonging to the tyler account contained a suspicious password field:
Although encrypted, this value might be decryptable using the DES key found earlier in the configuration file (rcmail-!24ByteDESkey*Str). At this stage, I took note of the encoded data for potential decryption later.
From this point, I had identified:
- Valid MySQL credentials.
- A list of Roundcube users (with
tyleras a possible pivot target). - Encrypted session and password data that could potentially be decrypted using the DES key from the config file.
With these findings, the next logical step was to attempt password recovery for the tyler account or use the decrypted credentials to escalate privileges within the system.
I pulled the session table from the Roundcube database and noticed the vars column contained long Base64 / serialized PHP blobs. These blobs store user session state (including, in this case, an encrypted/encoded IMAP password). To inspect the contents I copied the vars value for one of the sessions into CyberChef and ran a simple From Base64 → Bake recipe to decode it.
The decoded output revealed a PHP serialized array with user metadata and crucially it contained a plaintext password field for the jacob account:
This is a high-value find: the password came directly from Roundcube’s session data, which means it is the IMAP/SMTP credential Roundcube used for that account. In CTF terms, this provides an immediate privilege escalation pivot either by authenticating to the mail services (IMAP/SMTP) or by trying the same credential against system services (SSH) if credentials were reused.
With access to the Roundcube database and the session table, I extracted another vars blob and decoded it with CyberChef (From Base64). The decoded PHP-serialized session revealed the tyler account metadata and critically a cleartext credential:
This confirmed that Roundcube stores IMAP/SMTP credentials in session data and that these session blobs can be decoded trivially once retrieved from the database.
Having harvested the Roundcube des_key from config.inc.php earlier, I turned my attention to an encrypted blob I pulled from the session table. The session data included an 8-byte IV and a ciphertext (presented as hex). I used CyberChef to perform a Triple-DES (3DES) CBC decryption with the Roundcube key and the IV from the session.
In CyberChef I set:
- Operation: Triple DES Decrypt (3DES / DES-EDE3)
- Key:
rcmail-!24ByteDESkey*Str(thedes_keyfromconfig.inc.php) - IV:
2f b4 6f d3 40 3c 4e ec(taken from the session metadata) - Input: the ciphertext in hex
- Mode: CBC, Output: raw/text
I kept a netcat listener running on my machine while testing credential-derived escalation paths:
Shortly after attempting service authentication, the listener showed an incoming connection from the target and I landed a basic www-data shell. From that shell I attempted privilege escalation to a real user account using the decrypted value I recovered earlier:
The switch succeeded — su to jacob confirmed with id:
I then enumerated the home directories to see what jacob had access to:
Inside jacob’s mailbox I found a cleartext email from tyler with the subject Important Update. The message contained a new password for jacob:
Privilege pivot — SSHing in as jacob and capturing the user flag
Armed with the password recovered from jacob’s mailbox, I attempted an SSH login to the target host:
After providing the password, the login succeeded and I was greeted with an interactive shell as jacob. The first thing I did was check the home directory and look for the user flag:
The file user.txt contained the user flag ********************************, confirming a successful user-level takeover. Hurray!!! I got the user flag.
After gaining a shell as jacob I checked my privileges and then ran sudo -l to see what I could run as root without a password:
This output is important:
NOPASSWD: /usr/bin/below * — Jacob can run /usr/bin/below as root without a password with arbitrary arguments.- There are exclusions:
--config, --debug, -d are explicitly blocked, but everything else is allowed. Those exclusions matter only if an exploit requires those options.
I invoked the binary help to learn what below does:
CVE-2025-27591
A quick vulnerability search turned up CVE-2025-27591 - a local privilege escalation in below (affecting versions prior to v0.9.0). The root cause is simple and dangerous: below will log runtime errors into /var/log/below, and that directory (or files within it) may be world-writable or otherwise improperly permissioned. If an attacker can create a symlink inside /var/log/below that points to a sensitive file (for example /etc/passwd or /etc/shadow), running sudo /usr/bin/below as root will cause below to write log lines into the symlink target - effectively letting an unprivileged user overwrite arbitrary root-owned files.
Having identified CVE-2025-27591 as a viable escalation vector for the below binary, I grabbed a working PoC implementation and adapted it into a small exploit script to leverage the writable-symlink logging behaviour on the target.
I created exploit.sh on the box and populated it with a few straightforward steps:
I made the script executable and ran it:
Why this worked
below writes log data into /var/log/below in a way that can be influenced by an unprivileged user (or the directory is writable by a non-root account). By placing a symlink in that directory that points to a sensitive target (here /etc/passwd) and then invoking below via sudo, the process running as root writes log content into the symlink target. This allows an attacker to inject controlled lines into privileged files.- Because
jacob has NOPASSWD sudo rights for /usr/bin/below, the entire attack could be executed without needing any additional credentials. Overwriting /etc/passwd to add a UID 0 entry (or writing a sudoers file / root SSH key) is an immediate route to root.
Outcome
The exploit created a new root-equivalent user haxor with password hacked123. After running ./exploit.sh, and authenticating to haxor, I changed into /root directory and read root.txt, yielding the root flag:
Hurray!!! I got the root flag. With that the machine was officially pwned
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
Keywords:
Outbound Hack the Box Writeup
Outbound Hack the Box Machine Writeup
Outbound Hack the Box Walkthrough
Outbound Hack the Box Machine Walkthrough
Outbound HTB Writeup
Outbound HTB Walkthrough
Outbound HTB Machine Walkthrough
Outbound HTB Machine Writeup
Outbound Hack the Box HTB Machine Walkthrough Writeup
Outbound Hack the Box Solution
Outbound Machine Walkthrough
HTB Outbound
Outbound Machine Write-up
HackTheBox Outbound Writeup
outbound htb writeup
outbound htb walkthrough
outbound hack the box writeup
outbound hack the box writeups
outbound htb walkthroughs
outbound htb solution
outbound htb writeups
outbound htb complete writeup
outbound htb complete walkthrough
0 Comments