Post cover image
Successful close the case.

July 12, 2026

Hacking Web Application Using cURL

A simple-looking bonus challenge that turned into a great exercise in understanding HTTP requests, authentication, and application logic.

By Shatha511

4 min read

Introduction

While solving one of the TryHackMe rooms, I noticed there was a bonus challenge hidden alongside the main tasks. Naturally, I couldn't resist giving it a try.

At first glance, it didn't seem particularly difficult — but it quickly turned into one of my favorite parts of the room.

Unlike many web challenges that rely on interacting with a browser, this one forced me to work entirely from the command line using cURL. There were no fancy interfaces, no clickable buttons, and no developer tools — just raw HTTP requests and careful observation of the application's behavior.

None

I particularly enjoyed this challenge because it demonstrates an important lesson in web security: sometimes understanding the protocol is more valuable than knowing dozens of attack techniques.

Initial Recon

The first thing I noticed was that the application wasn't accessible through a normal web browser.

Instead, the page instructed me to use the following User-Agent:

secretcomputer

That immediately told me the application was checking incoming headers before serving its functionality.

Using cURL with the required User-Agent, I started interacting with the application.

None

Enumerating the Application

After sending the initial request, the application revealed five available endpoints:

Endpoint Method Purpose
/terminal.php?action=info GET Method Displays system information
/terminal.php?action=login POST Method Authenticates a user
/terminal.php?action=pin POST Method Verifies the operator PIN
/terminal.php?action=status GET Method Displays current progress
/terminal.php?action=close POST Method Returns the final flag

At this stage, I already had a rough picture of how the application worked.

Each endpoint represented one step in a chain, and it was obvious that reaching the flag would require satisfying several conditions first.

None None None None None

Looking at the End Goal First

Whenever I solve web challenges, I like to inspect the final endpoint before working through the intermediate ones.

So naturally, I tried interacting with the close endpoint.

Instead of returning the flag, it responded with an interesting message.

None

According to the application, three requirements had to be satisfied before it would reveal the flag:

✅ Admin Session ✅ Operator Token ✅ X-Force Header

Perfect.

Now I knew exactly what I needed to obtain.

Step 1 — Obtaining the Admin Session

The first requirement was an authenticated Admin Session.

The only available authentication endpoint was:

POST /terminal.php?action=login

which expected two parameters:

username
password

Since no password were provided anywhere in the challenge, dictionary attack became the obvious approach.

Unfortunately, the attack was taking much longer than expected.

Rather than waiting indefinitely, I filtered the wordlist to remove unnecessary entries and reduce the number of candidates.

This dramatically improved the overall execution time.

And the correct password appeared.

None

Logging in

Now that I had valid credentials, I could authenticate as the administrator.

I used the following cURL command:

None

Now, it's time for generating an admin cookies file:

None

Inside that file was the authenticated session cookie.

That cookie represented the Admin Session, satisfying the first requirement.

✅ Goal #1 Complete

Step 2 — Finding the Operator PIN

Next, I turned my attention to the pin endpoint.

After sending a request, I discovered that it expected the following parameter:

pin
None

That meant another dictionary attack.

I wrote a simple dictionary attack script that continuously tested candidate PINs until the correct value was found.

#!/bin/bash

URL="http://10.48.146.16/terminal.php?action=pin"
UA="secretcomputer"

for pin in $(seq -w 4000 5000); do
    response=$(curl -s -X POST \
        -A "$UA" \
        -d "pin=$pin" \
        "$URL")

    echo "[*] Trying PIN: $pin -> $response"

    if [[ "$response" != *"Incorrect PIN"* ]]; then
        echo "[+] Possible hit! PIN: $pin"
        echo "$response"
        break
    fi
done

After some time, the script successfully identified the correct PIN.

None

Testing it manually confirmed everything worked as expected.

None

✅ Goal #2 Complete

Step 3 — The Mysterious X-Force Header

Only one requirement remained:

X-Force

At first, I had absolutely no idea what value the application expected.

I repeatedly queried the status endpoint hoping it would provide additional clues, but no luck!

I modified requests, Checked headers, Repeated the process, and still nothing…

Eventually, I came across a hint that pointed me in the right direction.

None

After updating the request with the correct X-Force header, I queried the close endpoint again.

And boom…

None

What This Challenge Teaches

Although this was presented as a bonus challenge, it covered several practical web security concepts in a surprisingly elegant way.

It reinforced the importance of:

Understanding HTTP methods. Enumerating application functionality. Using cURL effectively. Working with authenticated session cookies. Performing dictionary attacks. Reading server responses carefully. Identifying required custom headers. Solving challenges by following application logic rather than guessing.

What makes challenges like this enjoyable is that every response from the server becomes a clue for the next step.

Thanks for reading! If you enjoyed this write-up or have solved a similar challenge, I'd love to hear your thoughts.

Shatha511