HackTheBox - Cap
Pre
- Cap is one of my favourite easy boxes because every step teaches something distinct and modern: a web IDOR, pcap analysis, and a Linux capabilities privilege escalation. No dusty CVEs here.
- It’s a great contrast to Bashed: instead of an obvious webshell, the foothold comes from noticing a number in a URL and changing it.
Phase 1: Recon
1
2
3
4
5
$ nmap -Pn -n -p- --min-rate 10000 --open -vv -oN nmap/firstScan $IP
PORT STATE SERVICE REASON
21/tcp open ftp syn-ack
22/tcp open ssh syn-ack
80/tcp open http syn-ack
1
2
3
4
5
6
7
$ nmap -Pn -n -p 21,22,80 -T4 -sSCV -A -oN nmap/versions $IP
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
80/tcp open http Gunicorn
|_http-server-header: gunicorn
|_http-title: Security Dashboard
FTP, SSH and a Python web app served by Gunicorn – a “Security Dashboard”. Note we don’t have FTP creds yet, so port 21 is on hold. Let’s explore the dashboard.
Phase 2: The IDOR
The dashboard offers network security tooling. One feature, “Security Snapshot”, generates a packet capture of the current traffic and shows a report at a URL like:
http://10.10.10.245/data/1
That trailing number is a direct object reference. The app trusts it blindly and never checks whether this capture belongs to us. What happens if we ask for capture 0?
http://10.10.10.245/data/0
Capture 0 is the very first snapshot ever taken on the box – likely generated by an admin or an automated process. The report page lets us download the raw .pcap. This is a textbook Insecure Direct Object Reference (IDOR): no authentication bypass, no injection, just an ID we weren’t supposed to iterate.
Whenever you see a sequential ID in a URL, try
0,1, and neighbouring values. IDOR is one of the most common real-world web bugs precisely because it looks harmless during development.
Phase 3: Reading the capture
Download the pcap from /data/0 and open it in Wireshark (or tshark). We’re hunting for plaintext credentials, and there’s an obvious candidate on this box: FTP is cleartext.
1
2
3
$ tshark -r 0.pcap -Y "ftp.request.command == USER || ftp.request.command == PASS" -T fields -e ftp.request.arg
nathan
Buck3tH4TF0RM3!
Following the FTP stream in Wireshark shows the same thing visually: a USER nathan / PASS Buck3tH4TF0RM3! exchange captured in the clear. That’s exactly why FTP should never be used over untrusted networks.
We now have nathan:Buck3tH4TF0RM3!. These creds work on both FTP and – because of password reuse – SSH:
1
2
$ ssh nathan@10.10.10.245
nathan@cap:~$ cat user.txt
Phase 4: Privilege Escalation via capabilities
On modern Ubuntu, before reaching for SUID binaries, always check file capabilities – a finer-grained way of granting a binary specific root powers without the full SUID bit.
1
2
nathan@cap:~$ getcap -r / 2>/dev/null
/usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eip
/usr/bin/python3.8 carries cap_setuid. That capability lets the binary call setuid(0) and become root while running – no exploit, just an intended-but-dangerous configuration. GTFOBins documents the one-liner:
1
2
3
nathan@cap:~$ /usr/bin/python3.8 -c 'import os; os.setuid(0); os.system("/bin/bash")'
root@cap:~# id
uid=0(root) gid=0(root) groups=0(root)
Root in a single line. 🐍
Conclusions
- Cap packs three independent, modern lessons into one easy box: iterate suspicious URL IDs (IDOR), inspect captured traffic for cleartext secrets (pcap/Wireshark), and enumerate Linux capabilities alongside SUID.
- The through-line is a real-world theme: cleartext protocols + credential reuse. The FTP password was reused for SSH, turning a passive capture into full interactive access.
- Defensive fixes are equally clean: authorise object access server-side, kill cleartext FTP in favour of SFTP/FTPS, and never grant
cap_setuidto an interpreter. - Next up, a web-app RCE and a GTFOBins
sudoescalation on OpenAdmin.
Keep hacking 🙈🙉🙊
