Cap
4 April 2026 4 april 2026
HackTheBox — Cap (Easy)
Recon
nmap -sC -sV 10.129.19.233FTP, SSH and a web app on 80: vsftpd 3.0.3 on 21, OpenSSH 8.2p1 on 22, and Gunicorn serving a "Security Dashboard" on 80.
Tried anonymous FTP first — no luck, it just rejected the login. So onto the web app. "Security Dashboard" had three things in the menu: /capture (a 5-second PCAP, always bounces you to /data/1), /ip (ifconfig output) and /netstat.
The fact that /capture always redirected to /data/1 made me curious what /data/0 would do. And there it was — a download button for an earlier PCAP that wasn't mine. Classic IDOR; the ID is just a sequential number with no access check.
Foothold
Pulled /download/0 and ran it through tshark:
curl -s http://10.129.19.233/download/0 -o capture.pcap
tshark -r capture.pcap -Y "ftp" -T fields -e ftp.request.command -e ftp.request.argFTP is plaintext, so the creds were just sitting there:
USER nathan
PASS [REDACTED]Same password worked on SSH (credential reuse, of course):
ssh nathan@10.129.19.233And user.txt was there. ([REDACTED])
Privesc
Checked capabilities — that is usually the first thing I do on a box named "Cap", and the name turned out to be a double hint (PCAP and capabilities):
getcap -r / 2>/dev/null
/usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eipcap_setuid on the Python binary means it can set its own UID to 0 without being SUID. Straight from GTFOBins:
python3.8 -c 'import os; os.setuid(0); os.system("bash")'
uid=0(root)
Root, root.txt. ([REDACTED])
What I took away
Whenever an endpoint redirects to /data/1, try /data/0 — sequential IDs without an access check are an IDOR waiting to happen. And the box name was a giveaway in hindsight: "Cap" pointed at both the capture file and Linux capabilities, I just didn't connect it until I was already at the getcap stage.
HackTheBox — Cap (Easy)
Recon
nmap -sC -sV 10.129.19.233FTP, SSH en een webapp op 80: vsftpd 3.0.3 op 21, OpenSSH 8.2p1 op 22, en Gunicorn met een "Security Dashboard" op 80.
Eerst anonieme FTP geprobeerd — niks, login werd gewoon geweigerd. Dus door naar de webapp. "Security Dashboard" had drie dingen in het menu: /capture (een PCAP van 5 seconden, stuurt je altijd door naar /data/1), /ip (ifconfig-output) en /netstat.
Dat /capture altijd naar /data/1 redirecte maakte me benieuwd wat /data/0 zou doen. En ja hoor — een downloadknop voor een eerdere PCAP die niet van mij was. Klassieke IDOR; de ID is gewoon een oplopend nummer zonder access check.
Foothold
/download/0 opgehaald en door tshark gehaald:
curl -s http://10.129.19.233/download/0 -o capture.pcap
tshark -r capture.pcap -Y "ftp" -T fields -e ftp.request.command -e ftp.request.argFTP is plaintext, dus de creds lagen er gewoon in:
USER nathan
PASS [REDACTED]Zelfde wachtwoord werkte op SSH (credential reuse, natuurlijk):
ssh nathan@10.129.19.233En user.txt binnen. ([REDACTED])
Privesc
Capabilities gecheckt — op een box die "Cap" heet doe ik dat sowieso als eerste, en die naam bleek een dubbele hint (PCAP en capabilities):
getcap -r / 2>/dev/null
/usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eipcap_setuid op de Python-binary betekent dat-ie zijn eigen UID op 0 kan zetten zonder SUID te zijn. Recht uit GTFOBins:
python3.8 -c 'import os; os.setuid(0); os.system("bash")'
uid=0(root)
Root, root.txt. ([REDACTED])
Wat ik eruit haalde
Als een endpoint je naar /data/1 redirect, probeer dan /data/0 — oplopende IDs zonder access check zijn een IDOR die op gebeuren staat. En de naam van de box was achteraf een weggevertje: "Cap" sloeg op zowel het capture-bestand als Linux capabilities, ik legde dat verband pas toen ik al bij getcap zat.