“Tomcat supports the deployment of web applications using WAR (Web Application Archive) files. A misconfigured Tomcat server allows attackers to upload malicious WAR files, translating administrative web access directly into Remote Code Execution (RCE).”
Find an exposed /manager/html on an internal engagement and there is a decent chance you already own the box—someone left the credentials at tomcat:tomcat and moved on. Apache Tomcat sits behind an enormous share of enterprise Java applications, bridging the web perimeter and the backend logic, which is precisely why it draws fire on every test. Tomcat Penetration Testing concentrates on the vulnerability that turns up again and again in these deployments: the deployment mechanism itself.
Understanding the Architecture
A static web server hands back files. Tomcat compiles and serves Java Servlet and JavaServer Pages (JSP) code, and that difference is the whole attack surface. The manual starts by building the thing from the ground up on Ubuntu—installing the JDK, creating a dedicated unprivileged service account (useradd -s /bin/false tomcat), and wiring the systemd unit. It feels like a detour until you are on target.
That groundwork pays off directly. You cannot reason about what a reverse shell will and won’t be able to do until you understand the constraints it inherits: what user it runs as, and what that user can touch under /opt/tomcat.
The WAR File Attack Vector
Tomcat exploitation revolves around one interface: the Tomcat Manager App. By design, it lets authorised users push new code as WAR files—that is the feature, not the bug.
The bug is what happens when the gate is weak. Compromise the Manager, whether through default credentials (tomcat:s3cret) or a dictionary attack, and every application-level control below it becomes irrelevant; you are deploying code, not exploiting it. The guide walks the full sequence: generate a malicious Java reverse shell, package it into a .war archive, upload it through the admin GUI, and trigger it by browsing to its deployed context path.
Command & Control
Once you have done it by hand and understand each step, the manual shows how to fold the whole chain into the Metasploit Framework. Dedicated modules handle authentication, payload generation, deployment, and execution in one pass, returning a stable Meterpreter session running with whatever privileges the Tomcat process holds. Worth stating plainly: that speed is also noise—the automated route lights up any monitoring watching the Manager endpoint, so the manual method still earns its place when stealth matters.
Who Is This Book REALLY For?
- Penetration Testers: A tight tactical guide for turning an exposed admin panel into a persistent Java-based reverse shell.
- Java Developers: A blunt reminder of what leaving
/manager/htmlreachable on production actually costs, and why deployment panels belong behind strict IP allow-listing. - Systems Administrators: Seeing exactly how a shell spawns as a child of the
tomcatprocess is what lets you write an AppArmor or SELinux profile that stops Java from executing the binaries an attacker needs.
The Bottom Line
Tomcat Penetration Testing makes a point web teams keep relearning: the execution engine is frequently softer than the code it runs. If you audit Java infrastructure, this is a focused guide to the conveniences that get people owned.
