githubEdit

Broken Authentication

User Enumeration

Identify

  • Different error messages for valid vs invalid usernames

  • "Unknown user" vs "Invalid password"

  • Response timing differences

  • Password reset returns different messages for valid/invalid users

Exploit - ffuf User Enumeration (Login Form)

ffuf -w /usr/share/seclists/Usernames/xato-net-10-million-usernames.txt \
     -u http://TARGET/index.php \
     -X POST \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "username=FUZZ&password=invalid" \
     -fr "Unknown user"

Exploit - ffuf User Enumeration (Password Reset)

Password reset endpoints often reveal valid usernames with different error messages.

Tip: Try both login and password reset endpoints - they may have different rate limiting or lockout policies.

If the session cookie looks like a hash (e.g. 32 hex chars = MD5), it may be MD5(username) or similar. Crack it to get the username:

Useful when the app identifies users by a cookie value and you need a valid username for SQLi or further attacks.


Password Brute Force

Filter Wordlist by Password Policy

Exploit - ffuf Password Brute Force


Password Reset Token Brute Force

Identify

  • Short numeric token (4-6 digits)

  • Token in URL: ?token=7351

  • No rate limiting

Generate Token Wordlist

Exploit - ffuf Reset Token Brute Force


2FA Bypass

Identify

  • Short OTP (4-6 digits)

  • No lockout after failed attempts

  • No rate limiting

Exploit - ffuf 2FA Brute Force


Rate Limit Bypass

Identify

  • Rate limit uses X-Forwarded-For header

  • CVE-2020-35590 pattern

Exploit - Randomize X-Forwarded-For


Security Question Brute Force

Identify

  • Predictable questions: "What city were you born in?"

  • No rate limiting on answers

Create City Wordlist

Exploit - ffuf Security Question Brute Force


Password Reset Manipulation

Identify

  • Hidden username parameter in reset form

  • Username passed through all reset steps

Exploit - Change Username in Final Request

Answer YOUR security question → change username to victim in final step.


Authentication Bypass - Direct Access

Identify

  • Protected page returns 302 redirect but body contains content

  • Missing exit; after redirect

Exploit - Burp Response Modification

  1. Intercept → Do intercept → Response to this request

  2. Change 302 Found to 200 OK

  3. Forward response → page renders

Exploit - curl


Authentication Bypass - Parameter Modification

Identify

  • user_id parameter in URL after login

  • Removing parameter causes redirect

  • Sequential/guessable IDs

Exploit


Session Token Attacks

Identify Weak Tokens

  • Short length (< 16 chars)

  • Sequential/incrementing

  • Static portions with small random part

  • Base64/hex encoded data

Decode Session Tokens

Forge Admin Token


Session Fixation

Identify

  • Session token set via URL parameter (?sid=xxx)

  • Session not regenerated after login

Exploit

  1. Get valid session: a1b2c3d4e5f6

  2. Send victim: http://TARGET/?sid=a1b2c3d4e5f6

  3. Victim logs in with your session

  4. Use session=a1b2c3d4e5f6 to hijack


Default Credentials

Resources

  • https://www.cirt.net/passwords

  • https://github.com/danielmiessler/SecLists/tree/master/Passwords/Default-Credentials

  • https://github.com/scadastrangelove/SCADAPASS

Common Defaults

App
Username
Password

WordPress

admin

admin

BookStack

password

Tomcat

tomcat

tomcat

Jenkins

admin

admin

phpMyAdmin

root

(empty)


Identify

Sometimes session cookies from one subdomain work on another subdomain of the same application, even if login on the second subdomain fails.

Scenario

  • You login to intra.target.htb with user credentials

  • You discover admin.target.htb subdomain

  • Direct login to admin.target.htb fails ("not enough permissions")

  • But the session cookie from intra.target.htb works on admin.target.htb

Exploit

  1. Login to the accessible subdomain:

  2. Note the session cookies set:

  3. Copy cookies to browser for the admin subdomain:

    • Open admin.target.htb in browser

    • Open Developer Tools → Application → Cookies

    • Add/modify cookies from the working session:

      • PHPSESSID=abc123

      • Change DOMAIN cookie from intra to admin

  4. Refresh the page - you may now have access to the admin panel with the same user's elevated privileges.

Why This Works

  • Session is stored server-side and tied to PHPSESSID, not to the subdomain

  • Role/permission checks may only happen at login, not on every request

  • Cookies with domain=.target.htb are shared across all subdomains

Tool-Assisted

Last updated