DriftingBlues: 1 BOOT2ROOT CTF VULNHUB WRITEUP
Welcome back to another CTF writeup! In this post, I’ll walk you through my step-by-step process of rooting DriftingBlues: 1, a vulnerable machine from VulnHub. I know it’s been a while since my last post, I’ve been tied up with school projects and other responsibilities, but I’m back and ready to dive into this challenge. This is the first installment in the DriftingBlues series, and I’m determined to complete the entire set soon. So buckle up, because we’re about to break down the exploitation process in detail and uncover all the flags this box has to offer.
First, we will scan for the open ports for potential entry points using Nmap
nmap -A -sC -p- -T5 -oN nmap_result.log 192.168.22.229
Let's visit the webpage
As I scroll down, I noticed something that might be useful for us
I noticed that there are two webmail users: sheryl and eric. To proceed, I edited the /etc/hosts file to map the domain to driftingblues.box.
While inspecting the webpage’s source code, I came across something interesting — a comment containing a Base64-encoded string.
I decoded it and this is the plaintext
It appears to be a path, so I appended it to the domain and here’s what the page returned.
Next thing I did is to decode it using dCode, and this is the plaintext.
my man, i know you are new but you should know how to use host file to reach our secret location. -ericThe message subtly points toward the hosts file as a potential route to uncover something hidden. Given that, I turned my focus to the website and began brute-forcing directories using Gobuster, hoping to uncover any overlooked paths or directories that might offer valuable clues or lead to further access.
gobuster dir -u http://driftingblues.box -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 10
The secret.html captured my eyes, let's take that a visit.
And as always, a Rabbithole:<
But no worries, time to dig even deeper! Let’s try brute-forcing subdomains and see if anything useful turns up.
gobuster vhost -u driftingblues.box -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt --append-domain -t 10
And it has! Next thing I did is to add test.driftingblues.box to our /etc/hosts file.
When I visit the subdomain, this is the result.
Nothing useful, so let's move on and try brute-forcing directories within this subdomain.
I noticed a robots.txt file listed, let’s check it out and see if it reveals any hidden or restricted paths we can explore further.
Inside the robots.txt file, there’s a disallowed path named /ssh_cred.txt. While "Disallow" is meant to keep web crawlers out, it doesn’t actually prevent us from visiting it directly — so let’s go ahead and check it out.
Wait, wait, wait, before that, I'll explain the meaning of Disallow in y'all to avoid confusion.
In the context of a robots.txt file, "Disallow" is a directive used to tell web crawlers (like those from Google or Bing) not to access or index specific parts of a website. Here's an example.
User-agent: *
Disallow: /private/This tells all web crawlers not to access the /private/ directory.
Important Note:
Disallow is not a security feature — it only provides guidance to well-behaved bots.
Anyone (including you) can still visit that path manually in a browser or using tools like
curl.
So when you see something like Disallow: /ssh_cred.txt, it’s more like saying, “Hey, bots, please don’t go here,” but nothing is technically stopping you from visiting it.
Now let's visit the /ssh_cred.txt .
This looks promising — we’ve got an SSH password! However, the message hints that there's a numeric value at the end of it. Since I didn’t want to manually brute-force every possibility, I took a more efficient approach.
for i in range(10):
print(f"1mw4ckyyucky{i}")Then I pasted the output to passw.txt and collect the two users we saw earlier, sheryl and eric to user.txt .
Time to bruteforce using Hydra.
hydra -L user.txt -P passw.txt 192.168.22.229 ssh -t 10
We've got eric's credentials, now let's login!
ssh eric@192.168.22.229
Yes!! We're in!
I attempted to run sudo -l, but it seems that eric doesn’t have any elevated privileges.
What I did next is to use linPEAS, but it doesn't give me anything valuable.
I decided to run pspy64, a powerful tool designed to monitor real-time processes on a Linux system without requiring root access. It’s especially useful for spotting scheduled tasks, scripts, or unusual activity that might otherwise go unnoticed.
After a short wait, I spotted some unusual processes being executed.
This sequence of commands reveals an automated backup process likely triggered by a cron job. It begins with /usr/bin/zip compressing the /var/www/ directory into /tmp/backup.zip, followed by the execution of a script located at /var/backups/backup.sh via /bin/sh. The duplication of the command using -c suggests it's being run through a cron entry or another script. The presence of /usr/sbin/CRON -f confirms that cron is actively handling scheduled tasks. The use of /bin/chmod indicates that file permissions are being modified during the process, and most notably, the command sudo /tmp/emergency suggests that a privileged script or binary is executed at some point — potentially offering a privilege escalation vector if the /tmp/emergency file can be manipulated.
But when I checked the /tmp directory, the emergency file wasn’t there — it simply didn’t exist. This could mean that the file is either created temporarily during execution and then deleted, or it’s being generated dynamically at runtime and removed immediately after use. Either way, it suggests there's a small time window where I might be able to replace or hijack it before the system does, which opens up a potential privilege escalation opportunity if timed correctly.
The idea that came to mind was: what if I create a file named emergency inside /tmp and embed a malicious payload in it? Since the system is executing /tmp/emergency with root privileges, any code I place inside that file would run with the same elevated permissions — effectively giving me root access if it works.
So I went ahead and created a file named emergency inside /tmp, and here’s the payload I placed inside it.
#!/bin/bash
echo "root:kuro" | chpasswdThis script changes a user's password by passing the new credentials to the chpasswd command. When run as root, it sets the specified user's password to the one provided.
Next thing I did to make it executable
chmod +x emergency
and execute pspy64 again and wait for the modified emergency file to execute.
As you can see, the chpasswd command runs right after sudo /tmp/emergency — which means the exploit worked perfectly!
All we need to do is to switch to root using su or su root and type kuro as our password.
And here's the root flag
We've successfully pwned DriftingBlues: 1!!!!
Conclusion
This box demonstrated a clear privilege escalation path through an insecure cron job or scheduled task that executed a script from the /tmp directory with root privileges. By placing a custom emergency script containing a password-changing payload into /tmp, and waiting for it to be executed by the system, I was able to successfully gain root access. This highlights the dangers of running scripts from world-writable locations without proper validation or permission controls, making it a valuable lesson in system hardening and secure task scheduling.
Last updated