VulnHub – Earth


Machine: Earth
Target IP:
Attacker IP:
Difficulty: Easy
Goal: Get root access


As usual we start with a Nmap scan to identify open ports on the target system. To do this we use the parameters -sC to scan for with default scripts as well as -sV to enumerate active services.

1. nmap -sV -sC

This gives us the extra information that there are host names within the SSL certificate as shown in figure 1.

When we access the web server on port 80 we get an 404 response back while on 443 we see a Fedora test page as the Nmap scan both already indicated.


2. Accessing Port 443 with a Browser


Since we already know about the host names of the target machine from figure 1 we can add them into the hosts file of our attacker machine /etc/hosts and access the webpage now over earth.local on port 443. Furthermore we can verify that there is also an interface answering requests for – the second name extracted from figure 1.


3. Accessing 443 on earth.local


From earth.local we are able to send messages but when submitting a message it is getting encrypted or encoded. Furthermore we have access to three old messages that have been sent before. For now it seems like there is no way of knowing what was sent before and that we have to look for hints on how to decode or decrypt the messages.

To find more information we can use a tool called wfuzz  to search for hidden web directories as shown in figure 4.


4. Using wfuzz to search for hidden directories of the web server


Using the –hw parameter we can exclude false positive findings and discover that there is a directory called /admin on earth.local where we are prompted with a login that requires a username and a password.


5. /admin page on earth.local


After trying some common username and password combinations like “admin, admin” or “admin, password” and also a quick verification if the login might be vulnerable to SQL injection attacks we keep on searching for new directories. When looking closely at the second hostname that we know of we will find a robots.txt entry on


6. Content for


The last entry within the robots.txt file looks interesting. Since it shows /testingnotes.* we can test some common file endings and have a hit on /testingnotes.txt.




The content of testingnotes.txt exposes a username and another file called testdata.txt which was used as a key for the encryption of the messages that we have seen in figure 3.


8. Content for /testdata.txt used as key for encrypting messages


With the knowledge of the encryption cipher, the encrypted message and the key that was used we can try to decrypt the messages from figure 3. After playing around with the format (Hexcode) we are able to decrypt at least one message with the key provided within /testdata.txt – however it is is not really clear on what to do with the decrypted message itself.


9. Using to decrypt the messages


After taking a shot at some wild guesses on what to do with the decoded message we are able to use it as password with the earlier identified username from /testingnotes.txt on earth.local/admin. This gives us access to an edit field  that executes the provided input on a CLI of the target system.


10. CLI access over 443 – after login on /admin


When trying to access a remote source the input does not get executed and we are prompted with an error message. However when we do not enter any IP the system is able to connect to external resources as shown in figure 11. It might be the case that there is only a filter that searches for IPs used in the input provided by the user.


11. Remote connections do work without an IP


Playing around with the CLI input we discover that we can not change directories and ware not allowed to create a file in the current directory – however we can write into the /tmp directory.
We can verify this by using commands like the following

echo “test”> /tmp/asd.txt
cat /tmp/asd.txt

which prints out the string test.

For the command
ls /var/www/html

we get an answer. This allows us to list the web server root directory
/var/www/html/ Unfortunately the permissions are all set to root so we can not write anything there.

Since it looks like we are not able to place any file with shell code on the target system and execute it over the web server we try to encode our commands with base64 to hide the usage of IPs and to create a direct connection from the target system back to the attacking machine.

12. Running echo base64string | base64 -d | bash over the web server CLI to get the base64 payload executed


Once we have access on the box we can search for the typical privilege escalation mechanisms like scheduled tasks, bad configurations, old software versions and other topics.

When searching for SUID binaries we find a strange looking binary called reset_root.


13. Finding an interesting binary called reset_root


When executing the binary on the target system itself it starts but it looks like it is missing some requirements and thus stops before resetting the root password.

To look deeper inside the binary itself we copy it over to our attacking machine.


14. Copying reset_root


Once we have the binary on our local system we can take a closer look at it by using a tool called ltrace. It intercepts and records dynamic library calls which are called by the executed process and the signals which are received by that process. It can also intercept and print the system calls executed by the program. ltrace shows parameters of invoked functions and system calls (link).


15. Checking the reset_root binary to identify possible requirements for the code to run


Since the program is checking for the existence of three files as shown in figure 15 we use the following commands on the target system over our existing remote shell.

touch /dev/shm/kHgTFI5G
touch /dev/shm/Zw7bV9U5
touch /tmp/kcM0Wewe

Afterwards we are able to run the reset_root binary on the target machine and since all requirements are in place the code gets executed and the root password gets reset. With this we are able to get root privileges.


16. Getting root privileges




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