The goal of this lab is to conduct active reconnaissance, search for vulnerabilities, exploit said vulnerabilities, and achieve root compromise on a poorly configured system. This will help explain how web shells work.

Step one of this lab is to see what services are running on the target IP (10.0.5.25 in this context):

sudo nmap -sV 10.0.5.25 --top-ports 200

Based on the services located using the Nmap scan, it's good practice to see what client-side use looks like. Since this scan identified HTTP, SSH, and FTP, we'll try accessing each of these services via the web browser and terminal environment. Below is the output of the Nmap scan:

Here's the web page available at the IP address:

I also attempted a SSH login (the account and password I cracked from an earlier lab didn't seem to work):

Here's the same web page accessed via curl:

Currently, we've addressed the SSH and HTTP services we found via Nmap scan. The FTP service still hasn't been addressed yet. Since this is a Kali box, there are exploit scripts available at /usr/share/nmap/scripts/. Since we're looking for FTP, the following command will help find relevant scripts:

ls /usr/share/nmap/scripts/ft*

This command is listing all of the scripts within this directory that contains "ft*", where "*" is a placeholder. The output has each of the scripts that contain these characters:

With these scripts, we can try running some against the target and see if any of them will work (i.e. an exploit can be applied). I started with the one below, however, it didn't seem to provide any additional information to move forward with:

I ended up trying another script. After running Nmap, note the message at the beginning of the output-- "Anonymous FTP login allowed". This means that we can login to the FTP service via the anonymous username.

Here's the latter part of the output from this same command--the second to last directory has full permissions, which means that it's writable:

Using the built-in FTP on Kali, we can utilize the "anonymous" login to access FTP on the target (The password for the user "anonymous" is indeed "password" :( :

Since we're able to get in, and we saw that there's a writable directory, let's test the viability:

in the screenshot above, the simple file that was created on the local host was able to be put in the upload folder via FTP. When browsing to the directory via browser, you can locate the test file.

Now that we've confirmed that file upload is working, we can then consider adding a web shell:

This directory shows where built-in web shells can be located. I then copied one of the web shell scripts to my current directory. After this (see below), I renamed the web shell file, re-accessed the FTP service, and put the web shell onto the target system.

Below is a screenshot of the web shell being used on the target system to cat the /etc/passwd file (results not shown for privacy reasons):

Since we have access to the FTP service, we can check and see what else is present on the system:

In this php file, we might find useful information. Let's try browsing to the location:

I tried using two different commands to get the php file--I'm not entirely sure which one did what I wanted... I was able to transfer it to my local host and cat the file, however.

In the screenshot above, the plaintext mysql password was found inside this file. I tried this password against the named user found in /etc/passwd, and it was successful:

The information we found regarding the local settings was for mysql--let's attempt to find information in there:

The first step is to see what's inside the database:

"mediawiki" is the only non-default option, so let's start by looking there (CORRECTION: command in the screenshot below is supposed to be show tables;):

From the tables within the database, we can locate additional information by using:

describe [TABLE_NAME];

From this description, there's entries for the username and password--let's grab those:

From here I copied the output (username and hashed password) and pasted it into a text file stored on my local host. This hash will need to be cracked if we expect to achieve root compromise.

This specific hash needed to be reformatted in order to be properly processed by Hashcat. In order to achieve this, a couple of hash entries had to be omitted (the error when running the raw output involved the length of the input, so this made sense). For details on this, reference the lab submission.

Once the hash file was properly formatted, I was able to go about cracking the hash. Since we were given a hint that the password started with a lowercase "p" and was in the rockyou wordlist, I used grep to capture the relevant content and output it into another wordlist. I then ran Hashcat (using the proper hash mode), pointing to the reformatted hash file, and referencing the heavily abbreviated rockyou wordlist. Due to this filter, I was able to crack the hash in about 10 minutes.

Once I had this password, I was able to SSH into the box as root and locate the flag.

This was a useful resource while trying to understand how to use FTP: https://www.serv-u.com/linux-ftp-server/commands

I was proud of the troubleshooting skills I implemented in this lab--I was able to determine the proper hash file format, filter out the password list, and navigate Kali without any peer or professor assistance. I did need to rely on parts of the video when we were using mysql and when I hit a rather long stuck point while examining FTP, but overall this was a mostly independent lab. Take note of the grep used to shorten the wordlist, as that allowed me to take a 5+ hour crack and shorten it to ~10 minutes.

At this point I'm still curious about WHY the hash file had to be reformatted from what was provided in the mysql database (i.e. the two parameters that were omitted in order for Hashcat to work). Other than that, it's important to consider what the sysadmin for this target should change in order to secure their resources. Step one should be to consider longer, more complex passwords (change password policy). This will make life more difficult for attackers. Another note to keep in mind is how easy it was to set up a web shell on the wiki. The "upload" directory (or most any directory, for that matter) shouldn't have full write permissions--I shouldn't have been able to remotely add files under the "anonymous" user.