Lion Cipher Lab
Deploy a web shell to Apache Tomcat Manager in your own lab
- Penetration Testing / Red Team
- Intermediate
- ~45 min
- Free · no account required
Why it matters
Apache Tomcat is one of the most widely deployed application servers on earth — it is the Java servlet engine sitting behind an enormous share of internal web apps, admin consoles, vendor appliances and forgotten staging boxes — and its Manager application is the single most classic foothold a pentester meets on a Java stack. The Manager exists for a legitimate, everyday reason: it lets an administrator deploy, undeploy, start and stop web applications without touching the filesystem or restarting the server, either through a browser at /manager/html or, for scripts and CI pipelines, through…
What you'll learn
- defining what Apache Tomcat is, what the Manager application (/manager/html) and the scripting API (/manager/text) do, what a WAR file is, and where tomcat-users.xml lives
- explaining the manager-gui vs manager-script roles and why the text API is the one an attacker automates against
- standing up an isolated Tomcat lab in the official tomcat:9 Docker container and deliberately weakening it — adding a weak manager-script/manager-gui user and relaxing the RemoteAddrValve — with a clear statement that a default Tomcat ships neither
- confirming the finding from a second container by curling /manager/text/list with HTTP Basic auth and seeing the deployed apps come back
- building a payload WAR two ways — msfvenom java/jsp_shell_reverse_tcp from the Metasploit Framework, and a hand-written minimal JSP command shell packaged with jar cvf
- deploying the WAR through /manager/text/deploy?path=/shell, triggering it, and proving remote code execution by running id / whoami inside the container
- naming when you meet this in the wild (internet-exposed Tomcat with tomcat/tomcat or s3cret creds), mapping it to ATT&CK T1190 and T1505.003, and how a pro does it better and less destructively
- applying the fix — remove or tightly scope the manager user, use a long random password, keep the RemoteAddrValve, run Tomcat as a non-root user, or remove the Manager app entirely — and re-running the same /manager/text/list curl to watch it return 401/403
- judgment: why this is a misconfiguration a human created (a weak user plus an opened valve) and not a Tomcat vulnerability, and why that distinction changes how you report it
Steps in this lab
- The words this lab rests on: Tomcat, the Manager app, the text API, and a WAR
- Stand up the lab — and yes, you must deliberately break it (twice)
- Confirm access — the finding is /manager/text/list answering a weak credential
- Build the payload WAR — msfvenom, or a hand-written JSP shell
- Deploy it and prove RCE — upload the WAR, trigger it, run a command
- When you meet this in the wild, why it works, and how a pro does it better
- Fix it and re-measure — remove/scope the user, keep the valve, run non-root
- The honest negative, and the habits worth keeping