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




Hack The Box – Sunday

Please note: This post was first released on September 29, 2018 on my old blog at:

This box retired on 29th of September 2018
Goal: CTF – user.txt & root.txt
Difficulty: 4.1 / 10 (rated by HTB-community)

We start with a Nmap scan and use the parameter “-p-” to scan the entire (tcp) port range. As figure 1 shows the box offers a ssh service on port 22022. We could use this information to start a password spraying attack, but to do so we need to know any valid usernames first. Another service that is running on the box is finger, which is a user information lookup program. As shown in figure 1 Nmap already obtained two valid usernames for the box by using finger.

1. Nmap scan result

For each of the two usernames “sunny” and “sammy” we start a password spraying attack with THC-Hydra. With the right password list we gain a hit after some minutes for the user sunny as shown in figure 2.

2. Hydra password spraying

After connecting to the box via ssh as the user sunny we search for the user flag. Typically these flags are inside the “/home” directory of a user. But we wont find any flag inside the home directory for the user sunny. Since we already know about a second user we look inside the “/home” directory for the user sammy. Inside this directory we find the “user.txt” flag, but unfortunately we are not able to access the file. To do so we need to escalate our privileges or access the machine as user sammy.

While doing the standard system enumeration and search for a valid privilege escalation technique we find an entry for the sudo command as shown in figure 3.

3. Sudo options for user sunny

Since it says “troll” we will ignore it for now, while keeping this in mind because it might come in handy later. After some more enumeration we find a backup directory. Inside that directory is a file called “shadow.backup” which contains some password hashes as shown in figure 4.

4. Backup of shadow

We copy the password hash for the user sammy and use hashcat to perform a dictionary attack to gain the cleartext password as shown in figure 5.

5. Using hashcat to recover the password for user sammy
6. Accessing the user flag

With the new obtained password we switch to the user sammy on the box, which grants us access to the user flag. The next step is to gain root privileges. To do so we once more start with the enumeration of the system. While checking for privileges on using sudo we notice that for user sammy there is no “troll”  entry anymore but instead a “NOPASSWD” for “wget” as shown in figure 7.

7. Sudo options for user sammy

With this in mind we take a look at the manual for wget and find an entry for the “–post-file=file option. With this option we can use POST as the method for all HTTP requests and send the data inside the request body. We can use this option to send the contents of the root flag to our local attacking machine while using netcat to listen for the incoming data as shown in figure 8.

8. Obtaining the root flag

At this point we could have also gained a root shell by using wget to send any ssh keys or to manipulate the passwd file on the box. Another interesting file to copy from the box is the shadow file which contains the hash for the password of user root. But sadly, after copying the hash I was not able to recover the password with hashcat and ended up with multiple failed dictionary attacks.

9. Getting root hash