DriftingBlues: 5 BOOT2ROOT CTF VULNHUB WRITEUP
Welcome back to my writeup!! Today I will show how I solved the fifth part of the DriftingBlues series!! No further explanations, let's start!!
First thing that will do is always, Nmap scan.
nmap -A -sC -p- -T5 -oN nmap_result.log 192.168.54.174
It's clear that the HTTP service is running WordPress. We already have an idea of how to proceed with this.
But first, let's visit the webpage.
Just a simple webpage, what to expect in driftingblues?? xD!
Next thing I did is to enumerate all the subdirectories using Gobuster .
gobuster dir -u http://192.168.54.174 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x html,php,txt
Next thing I did is to use wpscan to scan for any vulnerabilities in this WordPress webapp, since it has a login page, we can directly bruteforce this!
wpscan --url http://driftingblues.box --detection-mode aggressive -e -P /usr/share/wordlists/rockyou.txt
Since the cracking attempt using rockyou.txt was taking too long and most of the passwords in it are relatively short, I figured the actual password might be longer. To adapt, I used CeWL to crawl the target site and generate a custom wordlist by extracting words with at least 10 characters.
cewl http://driftingblues.box -m 10 -w passwd.txt
After that, I launched the wpscan and use our new wordlist.
We finally got the credential! Now let's login!
While exploring I found nothing useful, but I've found some photos stored here, that might be our key.
A DriftingBlues picpic, so I download it and check its metadata using exiftool .
exiftool dblogo.png
Well, would you look at that, an SSH password! Crazy how something as simple as metadata can end up being the key to breaking into a system. That’s the thing about CTFs, especially Boot2Root challenges, the tiniest details can make the biggest difference. It’s easy to overlook stuff that seems unimportant at first glance, but more often than not, that’s where the real gold is hidden. So if there’s one lesson here, it’s this: never ignore the small stuff. What looks like nothing could be your ticket in.
Let's login!!
ssh gill@192.168.54.174
We're in!!
Now time for the root!!
Alongside with user flag, there's a file named keyfile.kdbx .
In simple terms, a .kdbx file is a database used by KeePass, a password manager designed to securely store login credentials.
I started by transferring the file to my attacker machine. Since the database is protected by a master password that we don’t know yet, the next step is to extract the hash using keepass2john so we can attempt to crack it.
keepass2john keyfile.kdbx > hash
Now let's crack it!
john --wordlist=/usr/share/wordlists/rockyou.txt hash
We got the master key, let’s check out what’s inside this .kdbx file. To peek into it, I’ll be using keepassxc-cli, which is just the command-line tool for working with KeePassXC password databases.
Before we dive in, here’s a quick rundown of what a KeePass file actually is and how it works:
So, what’s a .kdbx file?
Think of it like a digital vault. It’s used by KeePass to store things like usernames, passwords, URLs, and even notes — all safely encrypted in one place. To open it, you usually need a master key, which could be just a password, a special key file, or both (like a second layer of protection).
Inside the file, the saved entries are neatly organized into groups and subfolders, kind of like folders on your desktop. For example, you might have groups like "Emails", "SSH Logins", or "Social Media", and inside each one are entries with:
The title of the entry (e.g., “GitHub”),
Username,
Password,
Website URL,
And maybe some notes.
All of that info is encrypted — so even if someone has the .kdbx file, they can't see anything without the correct master key.
Alright, back to the challenge — let’s list out all the groups in the database! To list, we will just use the ls parameter of keepassxc-cli.
keepassxc-cli ls keyfile.kdbx
Here are the groups! Now let’s dive in and check out the passwords saved inside.
keepassxc-cli show keyfile.kdbx "group_name" --show-protected
But..... All of the groups has no passwords.. That's why I think that this is a rabbithole.
Let's go back to the target machine. I used LinPEAS to find out more about this system.
After the scan, I noticed a strange directory in root, the /keyfolder . Let's check it out.
Looking at the permissions, we can see that other users have write access to this directory — even though it's owned by root! This could be our way to escalate privileges and gain root access.
When I looked inside, the directory was empty — leaving me completely unsure of what to do next.
At this point, I ran pspy64 to monitor scheduled tasks and see if anything interesting was running via cronjobs.
While watching the output from pspy64, I noticed the system was running /root/key.sh using both /bin/sh and /bin/bash. That basically means there’s a script in the root directory being executed automatically.
Let’s go back for a bit. In the /root directory, I found a folder named /keyfolder, and based on the presence of the /root/key.sh script, I suspected it was meant to generate or process some kind of password. I figured the script might output something important — maybe the root flag — into that folder. But when I looked, it was completely empty. Earlier, I had cracked the .kdbx file, and if you recall, the group names inside it looked a lot like potential passwords. So I thought, maybe creating a file in /keyfolder using one of those group names as the filename would trigger the script. At first, nothing worked — no output, no reaction. I kept trying different group names, and just when it was starting to feel hopeless… one of them finally worked!
After creating a directory named fracturedocean — which was one of the entries found in the .kdbx file, I waited a bit for the key.sh script to run. Soon after, a new file called rootcreds.txt was generated.
Honestly, this vulnerability was tough to spot, and it took quite a bit of trial and error to even come close to figuring it out.
Now let's login as root!
We are now root!!!
We've successfully pwned DriftingBlues: 5!!
Let's check the content of key.sh to make it clear.
#!/bin/bash
if [[ $(ls /keyfolder) == "fracturedocean" ]]; then
echo "root creds" >> /keyfolder/rootcreds.txt
echo "" >> /keyfolder/rootcreds.txt
echo "imjustdrifting31" >> /keyfolder/rootcreds.txt
fiThe key.sh script is a simple bash script that checks if the /keyfolder directory contains exactly one item named fracturedocean. If that condition is true, it writes a file called rootcreds.txt inside /keyfolder, containing the text "root creds" followed by the actual password imjustdrifting31. This explains why, after creating a directory named fracturedocean — which was a group name found in the .kdbx file — and waiting for the script to execute, the rootcreds.txt file was generated. The script is designed to look for that specific name, making the .kdbx group names a subtle hint toward the solution and showing how closely tied the cracked file and privilege escalation path are in this challenge.
This challenge was a perfect example of how Capture The Flag scenarios often test more than just technical skills — they challenge your attention to detail, creativity, and problem-solving mindset. What seemed like small or insignificant clues, like metadata or group names in a KeePass database, turned out to be key elements in solving the puzzle. By combining enumeration, password cracking, file inspection, and process monitoring, the path to privilege escalation gradually revealed itself. The solution wasn’t handed directly — it had to be pieced together from subtle hints and smart assumptions.
In the end, this challenge reinforced an important lesson: never overlook the small stuff. Whether it’s a file name, a group label, or a scheduled script, the smallest details can lead to the biggest breakthroughs. Stay curious, think outside the box, and always follow your instincts — they often point you in the right direction.
Last updated