Deathnote: BOOT2ROOT CTF VULNHUB WRITEUP
Welcome back to my writeup! Today, I’ll show you how I solved the Deathnote challenge from Vulnhub. It’s a simple Boot2Root, and I’ll walk you through each step, the tools I used, and the techniques that made it straightforward to complete. Let's start!!!
Reconnaissance
First, we’ll use Nmap to identify open ports that could serve as potential attack vectors.
nmap -A -T5 172.29.160.38
From the Nmap scan results, we can see that both port 22 (commonly used for SSH) and port 80 (used for HTTP) are open on the target machine. This tells us that the system is running services on these ports, which could potentially be leveraged for further enumeration and exploitation.
Let's visit the website.
The reason it didn’t work is because the service relies on a specific domain name. If you look closely at the URL, you’ll notice it uses a domain instead of just an IP address. To access it properly, we need to add that domain to our /etc/hosts file so the system can resolve it correctly.
After adding the entry to our /etc/hosts file, we simply refresh the page, and we’re now able to access the site properly
Woah, Kira!!! Let's take a look at the HINT.
It mentions that there’s a file called notes.txt somewhere on the server—but where exactly? Let’s broaden our enumeration to find out.
While going through the site, I noticed that it’s actually running WordPress. With that in mind, using WPScan seems like a logical next step to gather more information and potentially uncover vulnerabilities.
I quickly noticed the uploads directory. In most WordPress assessments, this is one of the first locations you should inspect, since it often contains user-uploaded files that might reveal useful information or even lead to potential footholds.
Let's visit it.
After digging around, I finally found the file mentioned in the earlier hint, located inside the 2021/07/ directory.
At the bottom, I found two text files, and one of them matched the hint we saw earlier. I simply used wget to download both files onto my machine.
With both files in our hands, the next step is to inspect what’s inside them.
Here's the notes.txt
And here's the user.txt
This looks like a wordlist. If my assumption is right, it might contain the credentials for SSH. So, let’s use these two lists and try brute-forcing SSH with Hydra.
In this case, we’ll brute-force both the username and the password. This is manageable because user.txt contains only a handful of usernames, and note.txt provides just a few potential passwords or phrases.
After some time, we've successfully got the SSH credential for user l . Now let's login to SSH as user l .
We’re in! Inside the user l account, there’s a user.txt file that contains a Brainfuck code.
When I decode it using Dcode, this is the result:
i think u got the shell, but you won't be able to kill me -kira
It seems that l is not alone here, maybe there's another user named kira .
There it is! kira is here! Now let's take a look!
As you can see, there’s a file called kira.txt. However, if you look closely at its permissions, it’s readable only by the user kira. Since we’re currently logged in as user l, we don’t have access to it. This means we’ll need to switch from user l to user kira in order to read the file. But the question is, how? Since we don't know the password of kira .
Looking more closely, you’ll notice an .ssh directory, and inside it there’s an authorized_keys file and we can read it!!
Given this setup, you’ll notice that the authorized_keys file is owned by user l, which is our current account. Because of that, we can SSH into the kira account without needing a password.
But how? Let me explain how SSH authentication logic works.
When you connect to a Linux system using SSH, the authentication process relies on a public–private key pair. The flow is simple:
The public key goes into the target user’s
~/.ssh/authorized_keysThe private key stays with the attacker/user who wants to authenticate
During login, SSH checks:
"Does the client’s private key match any of the public keys in this user’s authorized_keys?"
If yes, access is granted. If no, authentication fails.
To switch to kira, we'll just use ssh
We're now kira ! Now let's check the kira.txt .
It's a Base64 encoded string, if we decode it, this is the result:
Looks like there's a folder hidden inside /opt and /var . Let's visit L in /opt first.
Now, let's visit the fake-notebook-rule directory first.
That case.wav looks like a wav file but when I attempt to listen to it, it's said that it's not in correct format and when I take a look at its content, it's a hex string!
Decode it and this is the result:
It's a Base64 string, decode it and this is the result:
So it's a password! Let's try to use this to switch to root.
We're finally root!!
We've successfully solved Deathnote!!!
Last updated