HackTheBox Cap Walkthrough — Step by Step

Spoiler Warning: This is a full walkthrough of the retired HackTheBox machine "Cap." If you haven't attempted it yet and want to try it yourself first, stop here. Come back when you're stuck or after you've rooted it.

Machine: Cap Platform: HackTheBox Difficulty: Easy OS: Linux Release Date: June 2021 (retired)

Cap is one of the best beginner boxes on HackTheBox. It teaches three important concepts: IDOR vulnerabilities, PCAP analysis, and Linux capability abuse. None of these require exploit code or Metasploit — it's all manual enumeration and clear thinking.

I'll walk through my methodology step by step, explaining why I made each decision, not just what I typed.

Prerequisites

• A HackTheBox account with VPN access
• nmap, curl, and wireshark (or tshark) installed
• Basic familiarity with Linux commands
• The machine spawned and your VPN connected

If you're new to CTFs, check my VPS hardening guide to understand the Linux fundamentals this box tests, and my SSH hardening guide for context on the credential reuse vector.

Phase 1: Recon

Start with a full port scan:

nmap -sC -sV -oN cap_nmap.txt 10.10.10.245

• -sC — run default scripts
• -sV — detect service versions
• -oN — save output to file

Expected results:

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu
80/tcp open  http    gunicorn

Three ports: FTP (21), SSH (22), and HTTP (80). The web server is running Gunicorn, which means a Python backend — likely Flask or Django.

Why start with nmap? Every engagement starts with understanding what's exposed. Three open ports is a small attack surface, which tells me the path is probably through the web application.

Screenshot opportunity: Take a screenshot of the nmap output here.

Phase 2: Web Enumeration

Open http://10.10.10.245 in your browser. You'll see a security dashboard with network monitoring tools. The app has several pages:

• / — Dashboard with stats
• /capture — Triggers a packet capture
• /data/1 — Views capture results

Click around. Notice the URL pattern when you view captures: /data/1, /data/2, etc. The number is an ID.

Finding the IDOR Vulnerability

Here's the key observation: the app shows your captures, numbered sequentially. But what if you change the ID to 0?

Navigate to:

http://10.10.10.245/data/0

This loads a different capture — one that was taken before you connected. This is an IDOR (Insecure Direct Object Reference) vulnerability. The application doesn't verify that the capture belongs to your session. You can access any capture by guessing the ID.

Why is this significant? IDOR is one of the most common web vulnerabilities (it falls under OWASP A01: Broken Access Control). The app trusts that users will only access their own data by following the UI. It never checks authorization on the backend.

Screenshot opportunity: Show the /data/0 page with the download button.

Phase 3: PCAP Analysis

Download the PCAP file from /data/0 (click the "Download" button). Open it in Wireshark:

wireshark 0.pcap

Or use tshark for a quick look:

tshark -r 0.pcap -Y "ftp" -T fields -e ftp.request.command -e ftp.request.arg -e ftp.response.arg

The PCAP contains an FTP session. Filter for FTP traffic in Wireshark:

ftp

You'll see the FTP login sequence:

USER nathan
PASS Buck3tH4TF0RM3!
230 Login successful.

Credentials in plaintext. FTP sends everything unencrypted — this is why FTP should never be used for anything sensitive.

Why check the PCAP? The IDOR gave us access to someone else's network capture. Network traffic often contains credentials, especially for unencrypted protocols. Always check for FTP, HTTP Basic Auth, Telnet, and SMTP in PCAP files.

Phase 4: User Access

Try the credentials on SSH (credential reuse is extremely common):

ssh nathan@10.10.10.245

Password: Buck3tH4TF0RM3!

You're in as nathan. Grab the user flag:

cat ~/user.txt

Screenshot opportunity: Show the SSH login and user flag (blur the flag).

Why try SSH? People reuse passwords across services. Nathan used the same password for FTP and his system account. In real penetration tests, credential reuse is one of the most reliable paths to access.

Phase 5: Privilege Escalation

Now we need root. Start with standard enumeration:

id
sudo -l

sudo -l shows nathan can't run anything with sudo. Dead end there.

Check for SUID binaries:

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

Nothing unusual. Check for Linux capabilities:

getcap -r / 2>/dev/null

Output:

/usr/bin/python3.8 = cap_setuid,cap_net_bind_service,cap_net_raw+eip

This is the privilege escalation vector. Python3.8 has the cap_setuid capability. This means Python can change its own user ID — it can become root.

What Are Linux Capabilities?

Linux capabilities are a fine-grained alternative to the SUID bit. Instead of giving a binary full root privileges, you can grant specific capabilities. cap_setuid allows a process to change its UID. On a binary like Python — which can execute arbitrary code — this is equivalent to root access.

Why is this misconfigured? Someone likely set cap_net_raw on Python so it could do packet captures (the dashboard application). But cap_setuid was included too, probably by accident. In security, excess permissions are the number one cause of privilege escalation.

Exploit

python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'

This tells Python to: 1. Set its user ID to 0 (root) 2. Spawn a bash shell

whoami
# root
cat /root/root.txt

Screenshot opportunity: Show the capability output and the root shell.

Summary of the Attack Chain

1. Recon — nmap found FTP, SSH, and HTTP
2. IDOR — accessed /data/0 to download another user's PCAP
3. PCAP analysis — extracted FTP credentials from plaintext traffic
4. Credential reuse — FTP password worked for SSH
5. Capability abuse — Python's cap_setuid gave us root

Lessons Learned

This box teaches three real-world security failures:

IDOR (Broken Access Control): The web application trusted sequential IDs without verifying ownership. Fix: implement proper authorization checks — verify the authenticated user owns the resource before serving it.

Plaintext protocols: FTP transmitted credentials in the clear. Fix: use SFTP or SCP instead. Never use FTP, Telnet, or HTTP for anything involving credentials.

Excessive capabilities: Python had cap_setuid when it only needed cap_net_raw. Fix: grant the minimum capabilities required. Audit with getcap -r / regularly. This applies directly to Docker security too — containers should drop all capabilities except what they need.

Troubleshooting

Problem: Nmap scan returns no results. Cause: VPN isn't connected or the machine isn't spawned. Fix: Verify your HTB VPN is up with ifconfig tun0. Re-spawn the machine from the HTB dashboard.

Problem: Can't open the PCAP file. Cause: Wireshark isn't installed or the file is empty. Fix: Install with sudo apt install wireshark. If the file at /data/0 is empty, make sure you downloaded from ID 0, not your own capture.

Problem: SSH login fails with the found credentials. Cause: Typo in the password or wrong username. Fix: Copy the password exactly from Wireshark. The username is nathan (lowercase).

Problem: getcap returns nothing. Cause: You're running it without 2>/dev/null and errors are hiding the output, or the machine was reset. Fix: Run getcap -r / 2>/dev/null and look specifically for Python.

Conclusion

Cap is an excellent first HTB machine because every step teaches a concept you'll use on harder boxes. IDOR shows up constantly in web challenges. PCAP analysis is a core CTF skill. And Linux capabilities are a privilege escalation vector that's easy to miss if you only check for SUID and sudo.

If you're building your CTF skills, I'd recommend hardening your own server using my VPS hardening guide — understanding defense makes offense click faster. And if you're interested in the Docker security angle, check out my Docker security best practices.

Happy hacking.