# DriftingBlues: 2 BOOT2ROOT CTF VULNHUB WRITEUP Welcome back to another write-up! In this post, I’ll be walking you through the step-by-step process of how I successfully rooted *DriftingBlues: 2* from VulnHub. This is the second machine in the DriftingBlues series, and it continues the challenge with a slightly higher difficulty level! Let's start!

We'll use **Nmap** to identify open ports that could serve as potential entry points into the system. `nmap -A -sC -p- -T5 -oN nmap_result.log 192.168.96.47`

As shown here, the FTP service permits anonymous login—let’s go ahead and access it. `lftp -u anonymous, 192.168.96.47` Upon login, this is what I've found

Here's the image

I attempted to use `steghide` and `stegcrack` to check for any hidden data within the system, but it seems like there’s nothing concealed. Let's visit the website

The next step I took was to launch **Gobuster** and perform a brute-force scan to discover hidden subdirectories.

The blog subdirectory captured my attention so the next thing I did is to visit it and here's the result

At the very bottom, I noticed this

The `/blog` subdirectory is clearly running on WordPress. The first thing I did was add it to the `/etc/hosts` file. After that, I proceeded to use **WPScan** to gather more information about the site. `wpscan --url http://driftingblues.box/blog/`

Nothing's interesting even at the very bottom

I also checked the **uploads** directory, but didn’t find anything useful there. The next step I took was to re-run directory enumeration, this time specifically targeting the `/blog` subdirectory.

There's a `wp-login.php` , let's take that a visit

Since there's a wp-login, we can brute-force this using **WPscan**, **WPscan** has a bruteforce feature for wordpress logins. `wpscan --url http://driftingblues.box/blog/ -P /usr/share/wordlists/rockyou.txt --detection-mode aggressive -e` After spending quite some time and enjoying some coffee on a rainy day, I finally managed to obtain the credentials.

Now let's login!

We’re in! So what’s next? To get a shell, we’ll need to modify some source code under **Appearance → Theme Editor**. You can pick any PHP file from the theme, but the most effective choice is usually `404.php`, since it’s easy to trigger by simply accessing a non-existent page. For the payload, I used [PentestMonkey’s](https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php) reverse shell, but you can also use my custom version, I’ve created my [own](https://github.com/kUrOSH1R0oo/reverse-shell-payloads/blob/main/payload.php) PHP reverse shell script that works just as well.

Before we trigger the 404, we need to establish a listener first `nc -lnvp 1234` Now let's browse a subdirectory that doesn't exist and we should trigger the payload.

By the way, you can also achieve this using Metasploit with the `wp_admin_shell_upload` module. The first thing I did was upgrade to a stable shell by spawning a pseudo-terminal using Python’s `pty` module. `python3 -c 'import pty; pty.spawn("/bin/bash")'` Next, we’ll set the `TERM` environment variable to `xterm`, which tells the shell or terminal emulator to function as an xterm-compatible terminal for better display and interaction. `export TERM=xterm` Upon exploring I've found a one user at `/home`

Here are the files contained in the `freddie` directory.

As shown, the `user.txt` file is present, but notice the permissions — only the user `freddie` has read access. So, to view the contents of `user.txt`, we first need to gain access as the `freddie`user. The good news is that `freddie` has a `.ssh` directory. This means if we can access the `id_rsa` file, which is the private SSH key, we can use it to log in as `freddie` via SSH.

There it is! Now we just need to copy the private key to our attacker machine, set its permissions to `600` using `chmod`, and use it to authenticate and log in as the user `freddie` via SSH.

We're now `freddie`!

Now it’s time to fully take control of the system — let’s go for root access! I started by running the `sudo -l` command to check which actions `freddie` is allowed to execute with elevated privileges.

It turns out that `freddie` can execute `nmap` with root privileges. So, I headed over to [**GTFOBins**](https://gtfobins.github.io/gtfobins/nmap/) to find a way to exploit this, and here’s what I discovered.

This exploit takes advantage of Nmap’s native support for Lua through its Nmap Scripting Engine (NSE). By creating a temporary file containing the Lua command `os.execute("/bin/sh")` and running it with `nmap --script=$TF`, the user can execute system commands directly. Lua is used because Nmap is built to interpret Lua scripts for automation and advanced scanning tasks, making it ideal for this kind of abuse. If Nmap is run with `sudo`, the script runs with root privileges, and the spawned shell (`/bin/sh`) will also be a root shell. This leads to privilege escalation by exploiting a legitimate feature in a trusted binary to execute arbitrary commands as the superuser. Now let's try the exploit and we will try to launch nmap with sudo to see the result

It works!!! We are root!

The shell is not stable hehe, but here's the root flag!

We've successfully pwned DriftingBlues: 2!! **Conclusion** This challenge shows a common path of gaining full control over a vulnerable system. It starts by identifying a login page and using a tool like WPScan to brute-force access. After logging in, we take advantage of file editing features to upload a reverse shell and connect back to our machine. Once a basic shell is established, we stabilize it for better control and explore the system for further opportunities. Finding a private SSH key allows us to switch users, and checking for `sudo` permissions reveals a way to escalate privileges using a trusted tool. By carefully chaining each step—initial access, user escalation, and privilege escalation—we successfully gained root access, showing how small misconfigurations can lead to complete system compromise.