Jerry is a capture-the-flag VM on Hack The Box. This box focuses on web enumeration, default credential stuffing, and custom payload generation. This box has several paths for exploitation; we will only cover one in this walkthrough. Follow the tabs on the left for a detailed explanation on how to compromise this machine. Happy hacking!

As with most engagements, the recon phase is the longest one. Let’s start with a scan of the IP address:

The scan results show that Apache Tomcat/7.0.88 is running on port 8080. Let’s visit the website and see what info we can gather:

The site displays a default webpage with a banner confirming the Apache version we found via nmap. Using the Wappalyzer extension, we can also examine the different technologies utilized by the website. Although there are several vulnerabilities worth researching for this version of Apache, we are going to ignore them for the sake of this walkthrough. We next enumerate public subdirectories:

Gobuster returns an interesting folder that is accessible to us: /manager. When we navigate to it on the website, we are prompted for login credentials. Note: You could have also discovered this login page by clicking around the main website.

Up to this point, we do not have any login information. Time to look up default usernames and passwords for this web app. A quick Google search provides us with the following list:
We sort this list with a little bash scripting and create two files: “usernames-Tomcat” & “passwords-Tomcat”:

We could use any number of tools to brute force these credentials, like Burp Suite, hydra, or a custom python script. For this walkthrough, we are going to use Burp Suite. Start by setting up and turning on the FoxyProxy extension.

Open up Burp Suite and make sure the “intercept” option is turned on. Then, navigate to the /manager directory in back in the browser. Enter some random credentials in the Username and Password fields (we entered “admin/admin” for this example). Nothing will happen on the webpage because Burp Suite intercepted the request. We should see this back on Burp Suite:

The body of the request seems to be encoded. The padding at the end (“=”) suggests that it might be base64. Let’s try to decode it using Burp Suite:

On the right hand side, select the option to “Decode as Base64”. This shows up:

We were able to decode it, which means our guess was right. Had we been wrong about the encoding schema, we could have used another tool to attempt to crack it, like CyberChef. Now that we have a better idea of how the server accepts credentials, we can create the actual wordlist we will be using for the dictionary attack. Using the “usernames-Tomcat” and “passwords-Tomcat” files we created earlier, let’s create the wordlist in a format that the server will understand. Here is the bash script to accomplish this. You can copy the full command from my GitHub.

Now let’s try to gain access.

Let’s save the output to a file called “wordlist-Tomcat”. We go back to Burp Suite and send the request to Intruder by right-clicking the empty space in the Proxy tab.

We then configure the payload, making sure to disable url-encoding:

We launch the dictionary attack:

Perfect. We found a password that returned a 200 status code. We go back to the website to enter the matching credentials. Note: you will need to base64 decode the payload first to find out what the credentials are:

We go back to the browser, turn off FoxyProxy, and enter the credentials. We are greeted with the Tomcat Manager page. We have gained initial access.

Now that we have access to the Tomcat Manager Application page, let’s do more recon. At the bottom of the page, we find some useful information about the architecture of the server running this application:

We could have also obtained a copy of this info with a credentialed API request (just in case it was omitted from the site):

Knowing the server architecture can be useful for developing custom exploits. After some external research (a.k.a. Google search), we find out that Tomcat is used by developers to deploy web apps through something called “war” files. If we scroll down, we see an option to upload war files.

Let’s see if we have permission to upload by creating an empty, test file:

We successfully uploaded the test file to the server. Now let’s see if we can develop something malicious to gain unauthorized access.

To develop the exploit, we are going to use msfvenom. (Note: for the OSCP, you can use msfvenom as many times as you want , but you can only use its meterpreter payload one time). Let’s look up some msfvenom commands using my favorite msfvenom cheat sheet. Pro tip: press Ctrl + F to search for the file type you are looking for.

Let’s set up a netcat listener with the port we specified in the payload:

Now, we upload the payload the same way we uploaded the test file earlier. We then deploy the file by clicking the file name on the web app portal. This creates a reverse shell connecting back to our machine:

Success. We gained access to the server. Even better, we have nt authority\system access, which gives us full admin access. No need to worry about privilege escalation.

To exfiltrate the flag, we have to manually explore the server. Tip: focus on places where users save their data, and not system folders.

Congratulate yourself on making it this far! Hope this box was fun and that you learned something new.