Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the DarkCorp 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.
You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment and subscribe to my YouTube channel and follow me on LinkedIn for more updates.About the Machine
DarkCorp is an Insane level Windows machine on Hack the Box which features a vulnerability in Roundcube version 1.6.7 and below, and in version 1.5.7 and below, which is vulnerable to the XSS vulnerabilities CVE-2024-42009 and CVE-2024-42008, which have critical and high ratings respectively. These allow an unauthenticated attacker to steal emails and contacts, as well as send emails from a victim's account. All the victim user has to do is view a malicious email in Roundcube.
Attackers can gain a persistent foothold in the victim's browser across restarts, allowing them to exfiltrate emails continuously or steal the victim's password the next time it is entered. For a successful attack, no user interaction beyond viewing the attacker's email is required to exploit the critical XSS vulnerability (CVE-2024-42009). For CVE-2024-42008, a single click by the victim is needed for the exploit to work, but the attacker can make this interaction unobvious for the user.
The first step in pwning the DarkCorp 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:
After the connection has been set up, I started the target machine, and I was assigned an IP address of 10.10.11.54.
With the target IP identified, I began my enumeration phase by running a detailed Nmap scan to fingerprint the open services and gather as much information as possible. I used the following command:
The -sC flag runs Nmap’s default scripts, -sV attempts to detect service versions, and -A enables aggressive scanning features such as OS detection, version detection, script scanning, and traceroute.
The scan revealed two open ports:
- Port 22 (SSH) - running OpenSSH 9.2p1 on Debian 12 (Bookworm).
This version is relatively up to date, suggesting the system might be well-maintained. Nonetheless, SSH could serve as a potential entry point later on if valid credentials or keys are discovered during enumeration.
- Port 80 (HTTP) - running nginx 1.22.1.
The HTTP service hosts a web application titled “DripMail”, as indicated by the http-title output. The server header also confirms nginx as the backend. Since CTF challenges often hide important clues or vulnerabilities in web interfaces, this immediately became the primary focus for further investigation.
Interestingly, the OS detection results were inconsistent - Nmap guessed Windows Server 2022, but the service banner clearly shows Debian Linux. This mismatch likely occurred because Nmap couldn’t find enough open and closed ports to accurately fingerprint the host. In CTF environments, such discrepancies are common and can often be ignored if banner information is more reliable.
The traceroute results showed the target is only two hops away, consistent with typical internal HackTheBox-style lab networks.
Overall, the initial scan indicates that DripMail is hosted on a Linux machine running nginx and SSH, pointing us toward web-based enumeration as the logical next step.
I visited 10.10.11.54 to check what the webpage looks like but I got an error, Hmm. We're having trouble finding that site error.
This error is as a result of not mapping my IP address with the domain name. Since the Nmap scan revealed that there is an open port 80, I suspected the target was a web application. By default, my system wouldn’t know how to resolve that hostname, so I had to manually map it to the target’s IP address.
I edited the /etc/hosts file to include both domains:
and added the following line:
After adding the domain name, I visited 10.10.11.54 and I was redirected to DripMail website. On the webpage, we are presented with four hyperlinks, "Pricing", "Contact Us", "Sign Up" and "Sign In". The sign up hyperlink let's us register an account on the RoundCube mail service by providing our credentials.
On the "Contact Us" hyperlink page, I noticed that I can input some text in the input field. The first thing that came across my mind was XSS (Cross Site Scripting) which can be leveraged if the user inputs are not properly sanitized. The contact us page allows a visitor/user fill their name, email address and write a message. The send button allows the user to send the information to the backend.
On the sign up page, you can register an account by specifying a username and password and click on "Register" After completing the registration, you can login and send a letter to yourself.
After creating an account, I attempted to login and was redirected to mail.drip.htb.
I noticed the domain change and I proceeded to add it to the /etc/host file by running:
After mapping, the IP address with the domain name, I proceed to logging in and was presented with a welcome mail. In the email, the message reads
Hi boltech,
Welcome to DripMail! We’re excited to provide you convenient email solutions!. If you need help, please reach out to us at support@drip.htb.
After I logged into the mailbox I found the expected “Welcome to DripMail!” message from no-reply@drip.htb. On first glance it’s just a friendly welcome, but the message headers (the raw mail metadata) exposed several useful breadcrumbs.
drip.htb → drip.darkcorp.htb → localhost → delivered by Postfix. In short, the mail flow mentions an internal/secondary domain: drip.darkcorp.htb.The presence of drip.darkcorp.htb in the Received: and Message-ID headers was a clear breadcrumb: this internal FQDN is likely another virtual host on the box and therefore worth probing. I added drip.darkcorp.htb to /etc/hosts and began enumerating that hostname (web endpoints, admin pages, and mail-related services) because such internal names often expose admin panels, configuration pages, or additional functionality that can lead to further footholds.
Exploring the Vulnerability in RoundCube
On the contact us page, we can send ourself a message and intercept it with BurpSuite.
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
a
b
c
d
e
f
g
The second email from ebelford with subject "Analytics Dashboard" provided a hint by providing us with a domain "dev-a3f1-01.drip.htb" which allows us to reset the password before logging in. The content of the email is as follow:
Message:
Hey Bryce,
The Analytics dashboard is now live. While it's still in development and limited in functionality, it should provide a good starting point for gathering metadata on the users currently using our service.
You can access the dashboard at dev-a3f1-01.drip.htb. Please note that you'll need to reset your password before logging in.
If you encounter any issues or have feedback, let me know so I can address them promptly.
Thanks
Afterwards, I added dev-a3f1-01.drip.htb to the /etc/host file to map the IP address with the domain URL.
In the third email, there was nothing so interesting as no message content was found. When I checked the fourth email, I found out that the email was sent from "no-reply@drip.htb" with subject "Reset token" providing us with a password reset link. This would allow us to reset the password to a new one and login with the new password we have specified. The content of the email reads as follow:
Message:
Your reset token has generated. Please reset your password within the next 5 minutes.
You may reset your password here:
http://dev-a3f1-01.drip.htb/reset/ImJjYXNlQGRyaXAuaHRiIg.aOQYTA._ckURCFB6eK6EhMbb-MTrXUtUsE
------------------------------------------------------------
[+] Email exfiltration complete! Shutting down server...
[*] Shutting down server...
[+] Server stopped successfully!
l
m
n
I attempted to reset the password and luckily, I was able to. The next step was logging in with the credentials (user:bcase and the password we have just chosen) and see if it's was going to work.
The authentication was successful and I was redirected to the dashboard.
I ran a few SQL Injection prompt in the search bar and it returned a response. Few of these are:
The query returned a list of usernames including: support, bcase, ebelford, boltech and bushsec. The next step was reading the /etc/hosts file by running the following query:
This returned several domain names with IP addresses. The next step was adding this to the /etc/hosts file to resolve the mapping.
Afterwards, I returned back to the dashboard and continued querying the search. Next, I ran:
Querying Databases
This query returned a compiled list of ID's from pg_database including the following: postgres, template1, template0, roundcube, dripmail.
This completes the query from the SQL Injection prompt ''; SELECT tablename FROM pg_tables;
This returned a list of all user hashes. I also tried to obtain the admin hashes by running:
No hashed were found for Admin and not a single hash can be brute forced from the previous hash obtained. The next step I performed was trying to determine the version by looking at the database log by running:
The query returned the database version number PostgreSQL 15.10 (Debian 15.10-0+deb12u1). To read the log, I ran the following query and it returned:
There was nothing in this log so I tried to take a look at the old log by running the following query:
This returned the hash for user ebelford and I attempted to crack the hash using crackstation.net.
This returned the output of the hash as "ThePlague61780". The next thing I did was try to authenticate to ebelford using SSH by running the following command in the terminal:
The authentication was successful and I was able to obtain the shell as ebelford@drip. Checking the /var/backups directory, I found a backup of the postgres database by running:
Then I proceeded to check /var/www/html/dashboard/ directory and found .env directory by running:
dshdhs
d
e
f
g
h
i
j
k
l
m
o
p
q
r
After pasting the password hashes on https://crackstation.net, I obtained the following plaintext victor1gustavo@# for user victor.r (cac1c7b0e7008d67b6db40c03e76b9c0) and ThePlague61780 for user ebelford (8bbd7f88841b4223ae63c8848969be86).
Afterwards, I scanned the internal network for open ports and host using sshuttle for forwarding by running the following command:
t
To verify if the host is up, I ping host IP address 172.16.20.0/24 to ensure it's up and running using the following command:
u
v
w
x
Obtaining the User Flag
After obtaining the shell, I changed the directory to Desktop and checked the IP address configuration by running:
Then, I ran the following command to obtain the user flag:
Hurray!!! I got the user flag.
The next step was obtaining the root flag.
s
t
u
v
Reconnecting to evil-winrm as administrator and using the previously obtained NTLM hash from Administrator "fcb3ca5a19a1ccf2d14c13e8b64cde0f" to authenticate user administrator by running the following command to access the remote Windows PowerShell:
To obtain the root flag, firstly I check the Windows IP Configuration by running:
Then I navigated to the "Desktop" folder by running the following command and obtained 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
0 Comments