Post cover image

October 28, 2026

TryHackMe: RootMe Walkthrough

A comprehensive, step-by-step guide to bypassing web filters and exploiting SUID misconfigurations.

By lise

4 min read

RootMe is a beginner-friendly activity on TryHackMe designed to build the foundational knowledge of a penetration test. It takes you through a realistic attack chain with guide: mapping the target, discovering a web vulnerability, establishing a foothold, and escalating privileges to root.

Prerequisites:

  • TryHackMe Account
  • Virtual Environment setup
None
  • Lab Machine | Target IP address: 10.49.174.82

Phase 1: Scanning the Target (Nmap)

Before attacking, we need to understand our target's attack surface. I started with a standard network scan using Nmap to identify open ports and the services running on them. Use:

nmap -sC -sV <TARGET_IP>
  • -sC: Runs Nmap to look for common vulnerabilities.
  • -sV: Actively probes open ports to determine the exact service versions.

What kind of ports can we see here?

  • Port 22 (SSH): Running OpenSSH. We do not yet possess the necessary credentials, so we will retain this information for future reference.
  • Port 80 (HTTP): We are currently operating the Apache on version 2.4.41 (ubuntu). This configuration serves as the primary entry point for our web applications, allowing us to efficiently manage and serve HTTP requests to our users.
None None None

Phase 2: Digging Into the Web Server (Gobuster)

Since SSH generally requires credentials to exploit, Port 80 is our most viable entry point. Navigating to the IP address in a web browser just shows a default landing page. To dig deeper, we need to uncover hidden directories using Gobuster.

gobuster dir --random-agent -u [http://10.49.174.82/](http://10.49.174.82/) -w /usr/share/wordlists/dirb/common.txt -t 10

This command throws a massive list of common directory names (the wordlist) at the web server to see what exists. The scan successfully uncovered two critical endpoints:

  • /uploads — storing files
  • /panel — hidden web interface
None None

Phase 3: Getting a Foothold (File Upload Bypass)

Navigating to the http://<target_IP>/panel directory revealed a file upload form. This immediately signals a potential Remote Code Execution (RCE) vector if we can upload a malicious script.

The Payload:

I opted for the classic PentestMonkey PHP Reverse Shell. To use this, you must edit the script to point back to your attack machine:

  • Open the script and change the $ip variable to your TryHackMe VPN IP address.
  • Change the $port variable to a port of your choosing (for reference, I used 7788).

Bypassing the Filter:

When I attempted to upload the payload as shell.php, the server rejected it. The developers implemented a rudimentary extension filter to block .php files. However, Apache can be configured to execute PHP code under various extensions.

I renamed the file from shell.php to shell.phtml. The web application's filter didn't recognize .phtml as a threat and successfully allowed the upload. (❁´◡`❁)

Catching the Shell:

Before executing the payload, I set up a Netcat listener on my Kali machine to catch the incoming connection:

Set up a local Netcat listener on your machine to listen on port 7788:

nc -lvnp 7788

With the listener running, I navigated to the http://<target_IP>/uploads directory in my browser and clicked on my shell.phtml file. The web page hung, and my terminal instantly dropped into a shell. We now have access as the www-data user!

Capturing the First Flag:

To quickly find the user flag without manually digging through folders, I used the find command:

find / -type f -name user.txt 2>/dev/null

(Note: 2>/dev/null hides all the "Permission denied" errors for a cleaner output). Reading the file gave us our first flag: THM{y0u_g0t_a_sh3ll}.

Then it will print out:

cat /var/www/user.txt
# Output: THM{y0u_g0t_a_sh3ll}
None

Phase 4: Privilege Escalation

We are in the system, but www-data is a low-privileged account. Our final goal is total system compromise (root access).

A common privilege escalation vector in Linux CTFs is exploiting misconfigured SUID (Set User ID) binaries. If a binary is owned by root and has the SUID bit set, any user who runs that binary executes it with root-level privileges.

Hunting for SUID Binaries:

I searched the entire file system for these specific files:Now that we are on the machine as www-data, we need to find a path to elevate to root. A good first step in Linux privilege escalation is looking for binary files with the SUID bit set (-perm -u=s).

Files with SUID set run with the privileges of the file's owner (in this case, root), regardless of who runs them.

find / -type f -user root -perm -u=s 2>/dev/null

Scanning through the output, one binary immediately stood out as a massive security risk: /usr/bin/python. Python is a powerful interpreter; it should never have SUID root permissions natively.

The Exploit:

Tell the privileged Python interpreter to spawn a new system shell. Because Python is running as root (due to the SUID bit), the shell it creates will also be root.

python -c 'import os; os.execl("/bin/sh", "sh", "-p")'

The -p flag is crucial here—it tells the new shell to preserve the elevated permissions it inherited, preventing the system from automatically dropping us back to a standard user.

whoami

I ran whoami to verify my identity:

whoami
# Output: root / trnmrls (my username)

Snagging root.txt

To finish the room, I used the same find technique to locate the final flag:

cat /root/root.txt
# Output: THM{pr1v1l3g3_3sc4l4t10n}
None

Key Takeaways

  1. Extension Blacklisting is Flawed: Relying on simple blacklists (blocking just .php) is not enough. Secure file uploads require strict whitelisting, file renaming, and storing uploads outside the executable web root.
  2. SUID is Dangerous: Administrative tools and interpreters (like Python, Bash, or Vim) should never have SUID permissions enabled, as they can trivially be used to spawn root shells.
None