ArticlesToolsContact
Page cover

THM Kenobi walkthrough

https://tryhackme.com/room/kenobi

Write down your target ip:

10.10.41.115 # this is example

Nmap

always do proper nmap scan in the first place. It is you starting point and the most important source of knowledge on target machine.

─$ sudo nmap -sV -sC 10.10.126.130
[sudo] password for przemo: 
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-15 23:06 CEST
Nmap scan report for 10.10.126.130
Host is up (0.052s latency).
Not shown: 993 closed tcp ports (reset)
PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         ProFTPD 1.3.5
22/tcp   open  ssh         OpenSSH 8.2p1 Ubuntu 4ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 9d:36:de:d0:39:fd:b1:fb:b0:44:c4:58:0b:28:c9:a4 (RSA)
|   256 71:8f:d8:9c:bf:ad:4a:0c:af:94:9d:8b:6c:34:1f:0f (ECDSA)
|_  256 9b:f4:23:c0:5c:2c:1b:9e:4e:5b:48:7c:ef:92:64:68 (ED25519)
80/tcp   open  http        Apache httpd 2.4.41 ((Ubuntu))
| http-robots.txt: 1 disallowed entry 
|_/admin.html
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
111/tcp  open  rpcbind     2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|   100000  3,4          111/udp6  rpcbind
|   100003  3           2049/udp   nfs
|   100003  3           2049/udp6  nfs
|   100003  3,4         2049/tcp   nfs
|   100003  3,4         2049/tcp6  nfs
|   100005  1,2,3      34070/udp   mountd
|   100005  1,2,3      47397/udp6  mountd
|   100005  1,2,3      51421/tcp   mountd
|   100005  1,2,3      60221/tcp6  mountd
|   100021  1,3,4      33589/udp   nlockmgr
|   100021  1,3,4      34483/tcp   nlockmgr
|   100021  1,3,4      40803/tcp6  nlockmgr
|   100021  1,3,4      46741/udp6  nlockmgr
|   100227  3           2049/tcp   nfs_acl
|   100227  3           2049/tcp6  nfs_acl
|   100227  3           2049/udp   nfs_acl
|_  100227  3           2049/udp6  nfs_acl
139/tcp  open  netbios-ssn Samba smbd 4
445/tcp  open  netbios-ssn Samba smbd 4
2049/tcp open  nfs         3-4 (RPC #100003)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2025-10-15T21:06:40
|_  start_date: N/A
|_clock-skew: -1s
|_nbstat: NetBIOS name: KENOBI, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)

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

SMB enumerating shares

smbclient

enum4linux - detailed enummeration

enum4linux -a 10.10.126.130

Metasploit

smbmap

connecting to anonymous share

rpc port 111 showmount

we will find the place where network file system is mouted

ftp ProFTPD 1.3.5

SearchSploit (np. searchsploit openssh) >

  • searchsploit -u - update database

  • searchsploit -m [path] - download script

The mod_copy module implements SITE CPFR and SITE CPTO commands, which can be used to copy files/directories from one place to another on the server. Any unauthenticated client can leverage these commands to copy files from any part of the filesystem to a chosen destination. You can see it when you download and open 36742.txt file from searchsploit.

We know that the FTP service is running as the Kenobi user (from the file on the share) and an ssh key is generated for that user.

So we need to try to copy private key to some other accessible location - in our case we found the mount point /var we could later mount also to our Kali

Connecting to ftp

nc 10.10.126.158 21 - open connection to proftpd

then put commands: SITE CPFR /home/kenobi/.ssh/id_rsa -> copy from (we copy provate key for ssh) SITE CPTO /var/tmp/id_rsa -> copy to (and we save it to /var location which we have access to)

now we have copied private key to nfs-showmount directory /var

The task is to mount the target’s exported /var directory via NFS on the attacking machine, access the stolen SSH private key from /var/tmp, set proper permissions, and use it to SSH into the target system as the kenobi user.

What is NFS?

NFS (Network File System) is a protocol that allows you to:

  • Share directories over a network

  • Mount remote directories as if they were local

  • Access files on another computer transparently

Think of it like:

  • Shared folders in Windows (SMB shares) but for Linux/Unix

  • A remote folder that appears as a local folder on your system

What Did You Find?

####1. Port 111 - RPC (Remote Procedure Call)

From your first scan:

Explanation:

  • rpcbind = Service that manages RPC connections

  • Required for NFS to work - it's like a "directory service" that tells clients which port NFS is using

  • Port 111 is the "coordinator" for services like NFS

2. Port 2049 - NFS Service

From your first scan:

Explanation:

  • This is the actual NFS service listening

  • NFS version 3-4 is running

  • This allows file sharing over the network

What the Nmap Script Found

Command Breakdown:

  • -p 111 = Scan port 111 (rpcbind)

  • --script=nfs-ls = List files in NFS shares

  • --script=nfs-statfs = Show filesystem statistics

  • --script=nfs-showmount = Show which directories are exported (shared)

Script Results Explained:

What this means:

  • The server is exporting (sharing) the /var directory

  • The * means ANYONE can access it (no IP restrictions)

  • This is a CRITICAL security vulnerability!

In simple terms:

Why Mount /var to the Attacking Machine?

The Attack Strategy:

Step 1: Discover NFS share Step 2: Mount the share to your machine

  • mkdir /mnt/kenobiNFS = Create a local directory to use as mount point

  • sudo mount = Mount command (requires root)

  • -t nfs = Type of filesystem is NFS

  • 10.10.126.130:/var = Remote server and directory

  • /mnt/kenobiNFS = Local directory where it will appear

Step 3: Browse the files as if they were local

The Attack Explained:

Before mounting:

After mounting:

What you can do now:

  1. Read all files** in /var

  2. Search for sensitive data** (SSH keys, passwords, configs)

  3. Analyze logs** for usernames and system info

  4. Download files** to your local machine

  5. Use tools like grep, find** to search efficiently

SSH

What We're Looking For:

  1. SSH private keys in /var/tmp

  2. Information about users (like the user "kenobi")

  3. Files that can help you gain access to the system

We will go to /mnt/kenobiNFS/tmp and connect via ssh using private key: We also need to add 600 privileges to the private key:

SSH Key Permission Requirements

Permissions
Notation
Meaning
SSH Accepts?

-rw-------

600

Only owner: read/write

βœ… YES

-rw-r--r--

644

Owner: rw, Others: read

❌ NO (too open)

-rwxr-xr-x

755

Owner: rwx, Others: rx

❌ NO (too open)

-r--------

400

Only owner: read

βœ… YES (read-only)

-rwx------

700

Only owner: rwx

βœ… YES (but overkill)

Best permissions for SSH keys:

  • 600 (rw-------) = Standard for private keys

  • 400 (r--------) = More restrictive, also OK

Find SUID binaries (CRITICAL):

  • find / = Search entire filesystem

  • -perm -u=s = Files with SUID bit set

  • -type f = Only files

  • 2>/dev/null = Hide error messages

Look for unusual binaries! Common SUID binaries are normal, but look for something custom or uncommon.

output (look for this):

This is UNUSUAL! Standard systems don't have /usr/bin/menu with SUID.

Check the binary:

Output:

  • rwsr-xr-x = The s means SUID bit is set

  • Owner: root = When you run it, it runs AS ROOT

  • This is your escalation vector!

Run the binary:

Output:

Test each option:

Use strings to see what it executes:

Look for command execution patterns:

CRITICAL FINDING:

  • The binary calls curl, uname, and ifconfig

  • WITHOUT FULL PATH (not /usr/bin/curl)

  • This means it uses PATH environment variable to find these commands

  • PATH MANIPULATION VULNERABILITY!

Since the binary:

  1. Runs as root (SUID)

  2. Calls curl without full path

  3. Uses the PATH variable to find curl

We can:

  1. Create a fake curl that spawns a shell

  2. Put it in a directory we control

  3. Modify PATH to check our directory first

  4. When menu runs "curl", it actually runs OUR fake curl

  5. Our fake curl runs as ROOT = ROOT SHELL!

Create the exploit:

Put below command in Kenobi terminal:

Line 1: cd /tmp

  • Change to /tmp directory (we have write access here)

Line 2: echo '/bin/sh' > curl

  • Create a file called "curl" - we use curl but you can also use uname or ifconfig fake name to trick /usr/bin/menu binary

  • Put /bin/sh inside it (this will spawn a shell)

Line 3: chmod 777 curl

  • Make it executable by everyone

  • 777 = rwxrwxrwx

Line 4: export PATH=/tmp:$PATH

  • Modify PATH variable

  • Put /tmp at the BEGINNING

  • Now system looks in /tmp BEFORE /usr/bin -> this is critical part! We created face curl, pasted it into /tmp which is added in the beginning of path so menu binary will automatically run it in first place before it reaches to real curl

The whole attack idea is to fake one of the 3 real commands use by menu binary and manipulate PATH to sue our fake commands as first to execute. And because menu binary has SUID set it will run our fake command (with shell built in) as root.

PATH Manipulation

output:

Notice /tmp is FIRST!

output:

System will use OUR fake curl first!

Trigger the Exploit

Choose option 1:

What happens:

  1. Menu binary runs as ROOT (SUID)

  2. Tries to execute curl -I localhost

  3. Looks for curl in PATH

  4. Finds /tmp/curl FIRST (because we modified PATH)

  5. Executes /tmp/curl as ROOT

  6. Our fake curl contains /bin/sh

  7. ROOT SHELL SPAWNED!

Output:

You are now root!

Output:

Get the Root Flag

Output:

Submit this as the root flag!

Complete Exploit Commands (All Together)

Why This Works - Technical Explanation

SUID Bit:

  • Allows a file to run with the permissions of its owner

  • /usr/bin/menu is owned by root with SUID

  • When kenobi runs it, it executes AS ROOT

Relative Path Vulnerability:

  • Binary uses curl instead of /usr/bin/curl

  • System searches PATH directories in order

  • Attacker controls PATH variable

PATH Manipulation:

  • Normal PATH: /usr/bin:/bin

  • Modified PATH: /tmp:/usr/bin:/bin

  • System checks /tmp first now

Exploitation:

Cleanup - if you finished Kenobi room

Step 1: Unmount the NFS Share

First, make sure you're NOT in the mounted directory:

Explanation:

  • You cannot unmount a filesystem if you're currently inside it

  • Change to your home directory or any other location

Unmount the NFS share:

Explanation:

  • umount = Unmount command (note: it's "umount" not "unmount")

  • /mnt/kenobiNFS = Mount point to unmount

  • sudo = Required because you mounted with sudo

Verify it's unmounted:

Expected output:

Step 2: Remove the Mount Point Directory

  • rmdir = Remove directory (only works if directory is empty)

  • This deletes the mount point we created

If you get "Directory not empty" error:

Warning: rm -rf is powerful - double check the path!

Step 3: Remove the SSH Key

  • Removes the SSH private key we copied

  • Good security practice - don't leave keys lying around

If you want to keep it for reference:

Step 4: Remove SSH Known Hosts Entry

Remove the target from your known_hosts:

  • -R = Remove host from known_hosts file

  • 10.10.171.122 = The Kenobi machine IP

  • This removes the fingerprint stored during your first SSH connection

Why do this?

  • TryHackMe machines are temporary

  • Next time this IP might be a different machine

  • Prevents "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" errors

Step 5: Verify Cleanup

Check mount points:

Expected output:

Check for leftover files:

Both should return nothing related to Kenobi.

Complete Cleanup Commands (All Together)

Troubleshooting Unmount Issues

Issue: "Device is busy"

Solution 1: Check what's using it:

Solution 2: Force unmount:

  • -l = Lazy unmount (detach filesystem immediately, clean up later)

Solution 3: Kill processes using it:

Explanation:

  • fuser -km = Kill all processes using this mount point

  • Warning: Only use if you're sure no important processes are running

Solution 4: Check if you're still in the directory:

If output shows you're in /mnt/kenobiNFS/*, exit first:

Summary - Cleanup Checklist

  • Unmount NFS share: sudo umount /mnt/kenobiNFS

  • Remove mount directory: sudo rmdir /mnt/kenobiNFS

  • Delete SSH key: rm ~/Downloads/kenobi_id_rsa

  • Remove known_hosts entry: ssh-keygen -R IP

  • Clean temp files: rm /tmp/curl

  • Verify: mount | grep kenobi (should return nothing)

PreviousCTF Machines & Labs walkthroughNextXSS Game walkthrough

Last updated