vulnhub walkthrough writeup evilbox security

EvilBox Writeup – Vulnhub – Walkthrough

EvilBox is a Vulnhub machine rated as easy by the author Mowree. I have tried this machine on VirtualBox and it works fine on the default setting. However, you might want to change the network type to NAT Network if you are using one. Furthermore, this machine is a new machine at the time of writing. So, I recommend you try this on your own. “EvilBox Writeup – Vulnhub – Walkthrough”

Link to the machine:,736/

Identify the target

First of all, I identified the IP address of the target machine.

fping -aqg 10.0.0/24
The IP address of the target machine is

From the fping scan, I identified that the IP address of the target machine is Likewise, my IP address is

Scan open ports

Next, we have to scan the open ports on the machine. This would give us information about its exposed services on the network.

sudo nmap -v -T4 -p- -A -oN nmap.log
Nmap scan result shows ports 22 and 80 are open

Ports 22 and 80 are open. Also, Nmap shows the operating system being Debian. However, this has nothing to do with this CTF challenge. So, I brute-forced the directories on the server.

Bruteforcing directories

Firstly, I tried on the server root.

gobuster dir -r -u -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,html,txt -o dir.log 
Paths on the main page

I found an interesting path /secret that is empty. So, I further bruteforced to find other paths inside of it.

gobuster dir -r -u -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,html,txt -o dir-secret.log
Paths in /secret

I found a PHP script inside the /secret path. The script is empty and since I have nowhere to go from there, I fuzzed the GET parameter on it.

ffuf -c -r -u '' -w /usr/share/seclists/Discovery/Web-Content/common.txt -fs 0
Found the GET parameter as ‘command’

Local file inclusion (LFI)

Up to now, we found that command allows the inclusion of local files of the target.

/etc/passwd file as a result of the LFI

Also, we see that there is a user “mowree”. Let’s check the source code of evil.php. To do this, we have to use a PHP wrapper to show the content in a different format than PHP. This is because PHP files are executed by the server.



Using this gives us the following encoded text.


We get the PHP script as follows after decoding this.

base64 -d <<< PD9waHAKICAgICRmaWxlbmFtZSA9ICRfR0VUWydjb21tYW5kJ107CiAgICBpbmNsdWRlKCRmaWxlbmFtZSk7Cj8+Cg==
Source code of evil.php

The above code is vulnerable to RFI if only the PHP configurations “allow_url_open” and “allow_url_include” are allowed. By default, these are restricted. Here, this is the same case. Therefore, we cannot do RFI and execute a backdoor by including files from a remote machine (in this case my local machine).

Thus, I have to search sensitive files that would give me access to the machine. Since I have a user, I tried checking files from its home directory. Luckily, I found a public key in the /home/mowree/.ssh/authorized_keys file. Then, I checked if I can access the private key and I could.

id_rsa of the user mowree

The private key is encrypted by a passphrase. We can see that above. Now, I have to crack the passphrase. So, I copied the content to a file “id_rsa” on my local machine, changed its permissions and fed it to john the ripper.

chmod 600 id_rsa

We have to crack the hash of the passphrase. Therefore, we need a tool called to generate the hash. Hence, we have to download the script from the repo of john the ripper. I already have that.

~/ id_rsa | tee hash
john hash --wordlist=/home/kali/rockyou.txt
The passphrase is cracked

As we can see above, I was successful at cracking the passphrase. Now, I can easily log in.

User shell

Root privilege escalation

The root privilege escalation is also simple in this machine. When I checked the permissions on the file /etc/passwd, I found out that anyone can write on this file.

The file permission of /etc/passwd shows anyone can write on this

This file looks as follows.


The “x” in a row represents that the hash of the password of the user is stored in the /etc/shadow file. Upon removing the “x”, we could remove the password. But this didn’t work in here. So, I updated this with my custom password “root” for the user root.

openssl passwd -1
Generate the hash of the word “root” to use it as a password

I used openssl to generate the hash of the word “root”. Then, I copied the hash to the /etc/passwd file of the target. I updated the password of the user root as follows.

Updated /etc/passwd file

Now, I used the password “root” to get access to the root user.

su -l root
The root shell

Check my other writeup: Shenron 2 Walkthrough – Vulnhub – Writeup

4.6 12 votes
Article Rating
Notify of
Newest Most Voted
Inline Feedbacks
View all comments