# 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`

Port 22 (ssh) and Port 80 (http) are open

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.

An Ook Programming Language, I've encountered this before.

Next thing I did is to decode it using [dCode](https://www.dcode.fr/ook-language), 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. -eric ``` The 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. ```python 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. ```bash #!/bin/bash echo "root:kuro" | chpasswd ``` This 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.