Wonderland TryHackMe Write-up

Overview

Wonderland is a Linux privilege-escalation room built around an Alice in Wonderland theme. The room begins with web enumeration, moves into SSH access, and then requires several local privilege-escalation stages.

The main learning path was:

Web enumeration
-> hidden page discovery
-> SSH access
-> Python module hijacking
-> SUID PATH hijacking
-> Linux capability abuse
-> root access

This walkthrough focuses on methodology and reasoning. It does not publish TryHackMe answers, credentials, passwords, hashes or flags.

Initial Reconnaissance

The first step was to identify exposed services on the target machine. A standard service and version scan helped define the initial attack surface.

nmap -sC -sV <TARGET_IP>

The scan revealed SSH and a web server. The web service became the main starting point because it offered the most room for content discovery.

Web Discovery

The website did not immediately expose an obvious login page or application, so directory enumeration was used to look for hidden paths.

gobuster dir \
-u http://<TARGET_IP>/ \
-w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \
-t 30

Interesting paths appeared, including a short single-letter directory. The visible page hinted that the next step involved continuing to follow the room theme.

Following the Web Clues

The Wonderland theme suggested that the discovered directory was only one part of a deeper path. Testing nested single-letter directories eventually formed a theme-connected word.

/<LETTER>/<LETTER>/<LETTER>/...

The final page appeared normal in the browser, but its HTML source contained a hidden element. Inspecting source directly is a useful habit because rendered pages can hide important clues.

curl -s http://<TARGET_IP>/<DISCOVERED_PATH>/

A hidden HTML element contained login material in a username-and-password style format. The exact values are omitted.

Foothold

The discovered account was used to connect to the target through SSH. The username and password are intentionally replaced with placeholders.

ssh <USERNAME>@<TARGET_IP>
# password: <PASSWORD_REDACTED>

After login, basic host enumeration established the current user, working directory, file permissions and sudo permissions.

whoami
hostname
pwd
ls -la
sudo -l

A Python script in the user's home directory stood out because it could be executed as another local user through a sudo rule.

Python Module Hijacking

The Python script imported the random module. The important weakness was that Python could load a local file named random.py before loading the legitimate standard-library module.

import os
os.system("/bin/bash")

A replacement module was placed in the same directory as the target script. The vulnerable script was then executed through the permitted sudo rule.

sudo -u <NEXT_USER> /usr/bin/python3.6 /home/<CURRENT_USER>/<SCRIPT_NAME>.py

Why this worked

Python searches several locations when importing a module. When a writable directory is searched before the standard library, a local file can replace the expected module.

Defensive lesson

• Run privileged scripts from trusted, non-writable directories.
• Avoid unsafe import paths.
• Use isolated environments where appropriate.
• Keep sudo permissions narrow and intentional.

SUID PATH Hijacking

The next user's home directory contained an unusual SUID binary. Its behavior was inspected with standard file-analysis commands.

ls -la
file <BINARY>
strings <BINARY>

The binary executed a common system command using only the command name rather than an absolute path. That meant it trusted the current PATH.

cd /tmp

cat > <COMMAND_NAME> <<'EOF'
#!/bin/bash
/bin/bash
EOF

chmod +x <COMMAND_NAME>
export PATH=/tmp:$PATH
/home/<USER>/<SUID_BINARY>

Why this worked

Because /tmp appeared first in PATH, the SUID program found the controlled executable before the intended system command.

Defensive lesson

• Use absolute command paths inside privileged programs.
• Set a safe fixed PATH.
• Drop unnecessary privileges.
• Avoid SUID behavior unless it is truly required.

Linux Capabilities

The next account contained a password file used only to switch into a clean shell for that user. The password is omitted. Capabilities were then enumerated across the system.

getcap -r / 2>/dev/null

A Perl binary had the cap_setuid capability. That capability allows a process to change user IDs, so Perl could set its effective UID to 0 and launch a shell.

/usr/bin/perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/bash";'

whoami
id

Why this worked

cap_setuid gives a binary permission to change user IDs without requiring the traditional SUID bit.

Defensive lesson

Administrators should regularly audit Linux capabilities and remove powerful capabilities from interpreters unless there is a strong operational reason to keep them.

Lessons Learned

• Inspect HTML source, not only rendered pages.
• Follow thematic clues carefully in CTF-style rooms.
• Review sudo -l output immediately after gaining access.
• Python import behavior can create privilege-escalation opportunities.
• SUID binaries that trust PATH are dangerous.
• Linux file capabilities can be as powerful as SUID permissions.
• Privilege escalation is often a chain of smaller weaknesses.

Ethical Use Notice

This room was completed inside an authorized TryHackMe lab environment. The techniques described here should only be used in personal labs, CTF platforms, systems you own, or systems where you have explicit permission to test.

Do not apply these methods to real systems without written authorization.

user.txt -> [FLAG_REDACTED]
root.txt -> [FLAG_REDACTED]