Solving the “Vulnversity” room following the Kill of Chain methodology

In this article, I’m going to solve the well-known Vulnversity room from tryhackme, but following the cyber kill of chain methodology, the reason for doing this is to keep an eye on the standards and also helping you to improve the documentation of the attack phases, which will be also good in the future when you are auditing systems.

The cyber kill chain methodology is an effective way of illustrating how an adversary can attack the target organization. It helps in the identification and prevention of malicious intrusion activities. It provides greater insight into attack phases, which helps security professionals to understand the adversary’s tactics, techniques, and procedures beforehand.

Figure 1. Cyber kill of chain

Reconnaissance

The main objective is to obtain as much information about the target as possible in order to find weaknesses in the target. There are two types of reconnaissance:

• Active: This is a direct interaction with the target and will also generate alerts of the security systems that are monitoring the targeted application.
• Passive: This is usually done via OSINT (Open Source Intelligence) in which we use publicly available information to learn more about our target without directly interacting with the target.

Knowing this, let’s start our Active reconnaissance (since it is a controlled environment for learning purposes).

For this, we are going to use nmap, usually, we would like to learn about or target, so a simple scan searching for versions will be enough to find.

sudo nmap -sT -sV 10.10.220.26 -oN fullTCPscan.nmap

Here we are doing a full open scan, in which we are completing the TCP three-way handshake (-sT) and also checking for the version of those services (-sV) with -oN I’m exporting the result to a file, so if needed I can review in the future the output and avoid further interaction with the target. Remember, this can generate alerts and also is a good practice.

Our output looks like this, in which we enumerated the open ports and its version, you may know that Apache is a web server, so likely we are facing a web page that is being served by Apache

Figure 2. Nmap results

Let’s try it out by accessing http://10.10.220.26:3333 and let’s see what we can find.

Figure 3. Identified web page

And look at the screenshot above, it is a web URL in which we can find hidden directories, so our reconnaissance has found a web that is being served by an Apache server in n Apache in version 2.4.18. But, what can we do next? Well with this we may want to do a little bit of research of that Apache version maybe with searchsploit (exploit database) or metasploitable to find an exploit to compromise this server. But in this case, we are going to proceed as the original walkthrough, we are going to identify all those hidden directories using a Fuzzer in this case using gobuster, and this is still part of the active reconnaissance.

Using the following command we are using 400 threads (-t) and using a worldlists to brute force the paths (-w), we are also avoiding showing 404 status codes and errors with — no-error, and saving it to a file called output.gobuster.

sudo gobuster -t 400 dir -u http://10.10.193.195:3333/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt — no-error -o output.gobuster

And we found some interesting paths for that specific web page, the one that caught our attention is /internal

Figure 4. Gobuster enumeration

Let’s check what can we found in the http://10.10.193.195:3333/internal URL.

Figure 5. Upload server was found

As you can see we have an URL that seems to be used only for internal purposes only in which you can upload files. Now we need to identify which kind of extensions this server is allowing, are they doing any kind of input sanitization? Let’s identify it using BurpSuite and the SNIPER function.

Let’s use the following list of extensions in our own sample file called myExtensions.php:

• .php
• .php3
• .php4
• .php5
• .phtml

Let’s start by selecting a random image and begin intercepting the traffic before clicking the submit option. Once you are intercepting click submit and take a look at the burp suite.

We have successfully intercepted the request, let’s click in the dropdown menu called Actions > Send to Intruder and then clock the Intruder tab

Figure 6. Intercepting the file upload

Once in the intruder, click clear and select the extension of our file, in this case, the .jpg and click add, it should look like this

Figure 7. Selecting our sniper subject

Then click in the payloads tab and Load our file created before, called myExtension.php, and it will load our extensions

Figure 8. Extensions to test the webserver

Click start attack and let’s evaluate the results:

Figure 9. Sniper results

As we can see all were successfully handled by the webserver since we had an HTTP status code 200, but you may want to check the response of those to confirm if the server accepted or rejected our extensions. In this case, the accepted extension is .phtml.

At this point, we know this server accepts file uploads with extensions in .phtml and we can use this to upload a malicious file and spawn a reverse shell. Here we have enough information about the target and a possible way to get access to its system. So our reconnaissance step is done for now. Let’s continue with the Weaponization phase.

Weaponization

Now that we have identified a web server as well as a place to put files with a fake file extension, now we can think about which is the better way to get into the system, usually, when we have a vulnerable web server that allows this type of files to be uploaded we can follow the File Inclusion attack, by sending a malicious script to the webserver and then trying to access the route in which it is being saved to execute the script. This script may send us a reverse shell so we can get into the target server.

To achieve this we can use the MonkeyPentester tool which is a PHP file that spawns a reverse shell and that tool can be found in the following repo, https://github.com/pentestmonkey/php-reverse-shell/

Let’s download the script and let’s edit the IP and PORT, if we are behind a VPM the IP should be the IP of your VPN.

Figure 10. Preparing our weapon

And now let’s put ourselves in listening mode using ncat, use the following command to achieve this:

nc -lvnp 1234

And now we are done with our weaponization phase for the initial access.

Delivery

Now you may be wondering how we are going to deliver it? Well, in our reconnaissance phase we found a place to upload files with a particular file extension .phtml, we are going to change the extension of our reverse shell script so the target server will save it in their records.

So rename the script and put the extension .pthml and go to upload the file into the /internal/ URL.

Figure 11. Delivering our payload.

Once it is uploaded, it is time for the next step.

Exploitation

Now that we know that our payload is in the target host, how can we access to it? well if you are aware of how the file uploads works, usually they put everything into an /uploads directory so let’s try to access that specific file following the URL, be sure that you are listening in the port that you have configured in that file!

http://10.10.193.195:3333/internal/uploads/php-reverse-shell.phtml

Figure 12. Reverse shell spawned

As you can see the target server sends us a reverse shell with the user that exposes the webserver, in this case the default user for the Apache webserver is www-data.

At this point, we have gained access to the system but we are not a superuser yet, here we may have to start the Reconnaissance (to search any other vulnerability that allows us to do privilege escalation in the current box), Delivery (if we need to send new files to the webserver to continue the exploitation) and exploitation phase again to escalate privileges. This is why this methodology of the cyber kill of chain is not a plain procedure, we may have to go back to previous steps once we have achieved an initial intrusion

Knowing that I’ll assume that you are aware of it, so we are going to skip some details in the further steps to do a privilege escalation. In this box we have found there is a system binary with a SUID (systemctl), this means that we can take advantage of that binary and try to create our own service (or upload [deliver] a crafted one with the .phtml extension and then change the extension) this crafted file can spawn a new reverse shell and since it is using the SUID the root user will be the one that sends us a new shell with high privileges, so we can continue with the installation phase. So, as you can see, we are iterating over the 3 first steps to do a proper privilege escalation.

Installation, Command and Control, and Actions on Objectives

The last three steps that usually are not in the scope of this room, is the installation in which we have already compromised the superuser and we have full control of the system to start installing more malware to be able to enable the command and control to do not lose the access to the system. Now those two steps are done, we finally can do whatever we want, and that phase is the actions on the objectives.

Hopefully, you enjoyed this article!

Cheers!