TryHackMe Lookup Walkthrough | Username Enumeration, ElFinder Exploit & Linux Privilege Escalation

The Lookup room focuses on web enumeration, username discovery, exploitation of an outdated ElFinder instance, privilege escalation through a custom SUID binary, and finally abusing a sudo misconfiguration to obtain root access.

1. Enumeration

The First step of any challenge is enumeration. Enumeration helps us to identify ports and services running on the target machine.

• sV — Determines services on the target machine
• — script — Runs scripts from the NSE(Nmap Scripting Engine)
• The http-enum NSE script attempts to identify common directories and web applications, making it useful for quickly discovering hidden content exposed by the web server.

From the Nmap results, I added the target IP address to /etc/hosts file so it can be resolved with lookup.thm.

2. Information Gathering

On opening lookup.thm in Firefox, I got the login page. Since the login page revealed little information, directory enumeration was the next logical step to discover hidden endpoints. However, Gobuster did not reveal anything useful.

Moving back to the login page, I tried entering default admin credentials. During the process, I noticed something interesting: when I entered admin credentials, I got the error "wrong password. Please try again." but when I entered a random username I got a different error stating "Wrong username & password. Please try again."

Using Hydra, I tried entering different usernames.

Hydra -L /usr/share/wordlists/seclists/Usernames/Names/names.txt -p 123 lookup.thm http-post-form "/login.php:username=^USER^&password=^PASS^:F=wrong username" -T 4

Hydra identified two valid usernames: 1. Admin & 2. Jose

After entering the correct username and password, I was redirected to another subdomain called "files.lookup.thm". So, I added that subdomain to /etc/hosts.

Revisiting files.lookup.thm, I got the Elfinder service where I can create and view different files but am not able to modify them. When looking at every option, I found Elfinder version, which was 2.1.47.

So I used searchsploit, which is a known remote command execution vulnerability affecting ElFinder 2.1.47. Since Metasploit already provides a reliable module for this vulnerability, it was the quickest way to verify the exploit and obtain an initial shell.

3. Gaining Access

I opened Metasploit and selected that elfinder version 2.1.47 exploit.

I set RHOSTS to files.lookup.thm and executed the exploit. The exploit returned a Meterpreter session on the target machine.

4. Horizontal Privilege escalation

Getting a shell inside the target machine, I read /etc/passwd to see user accounts on the machine. Then I listed the contents of /home and /home/think directories. When listing the contents of /home/think directory, I found the file user.txt, which was owned by user root and group think. But, sadly, other users do not have permissions. So we need to find another way to access user.txt.

I used find / -perm -u=s -type f 2>/dev/null

• perm — Files having permissions
• -u=s — Files that have suid permissions
• -type f — file type (f files, d directories)

Among the SUID binaries, /usr/sbin/pwm stood out because it is not a standard Linux binary. Custom SUID binaries often deserve closer inspection, as they may contain insecure implementations that can be abused. So, I saw the permissions of that file. It had permission for everyone to execute. Executing the binary produced the following output.

This script was checking the ID of the particular user, and then it was looking for the .passwords file in the user's home directory. Now we have to find some way to fool this script into thinking that we are the user "think" instead of the user "www-data".

To do so, I created a file named /tmp/testbin/id with the following commands. Then, changing the path temporarily to /tmp/testbin:$PATH will display uid = 1000(think), gid = 1000(think), groups = 1000 (think). Since the binary executes the id command without using its absolute path, Linux searches the directories listed in the PATH environment variable. By placing a fake id executable earlier in the PATH, we can control the output returned to the program.

After authenticating via SSH, I obtained access as the "think" user. This also allowed us to retrieve the user flag.

5. Vertical privilege escalation

To see all privileges and permissions for user "think". I ran sudo -l

where I found that "Think" can run look command at /usr/bin/look.

Let me explain what the "look" command means. The look misconfiguration lies in granting the look binary sudo privileges. Because it executes as root, it inherits root's file permissions, allowing any readable file on the system to be accessed through look. This makes it possible to read sensitive files that the current user would otherwise be unable to access, leading to privilege escalation.

Finding this, I simply ran sudo /usr/bin/look ' ' /root/root.txt.

Executing the command revealed the root flag, completing the room.

Key takeaways:

• Small clues, like different login error messages, can reveal valuable information for enumeration.
• Always verify application versions, as outdated software may have publicly available exploits.
• Custom SUID binaries deserve careful analysis since they often introduce unexpected privilege escalation paths.

See you in the next one. Till then, happy hacking.😉

About the Author Hi, I'm TibeRius_12, a master's student in Cybersecurity and an aspiring penetration tester. I document my journey through TryHackMe labs, Active Directory, web security, and practical VAPT methodologies. If you enjoy hands-on cybersecurity content, feel free to follow me for future write-ups.