Daemon Of Hacking
  • WELCOME!
    • 👋/home/usr/KruKnight
  • METHODOLOGIES & RESOURCES
    • Passwords & Attacks
    • Post Exploitation
      • 👀Situational Awareness
      • 🖥️Privilege Escalation
        • Linux Privilege Escalation
        • Windows Privilege Escalation
  • Writeups
    • CyCtf 2024
      • Vending Machine
      • Aerospace
      • OhMyCell
    • Portswigger Labs
      • Authentication
        • Username enumeration via different responses
        • 2FA simple bypass
        • Password reset broken logic
        • Username enumeration via subtly different responses
        • Username enumeration via response timing
        • Broken Brute-Force Protection, IP Block
        • Username enumeration via account lock
        • 2FA broken logic
        • Brute-forcing a stay-logged-in cookie
        • Offline password cracking
        • Password reset poisoning via middleware
        • Password brute-force via password change
        • Broken brute-force protection, multiple credentials per request
      • Os Command Injection
        • OS command injection, simple case
        • Blind OS command injection with time delays
        • Blind OS command injection with output redirection
        • Blind OS command injection with out-of-band interaction
        • Blind OS command injection with out-of-band data exfiltration
      • Cross-Origin Resource Sharing (CORS)
        • CORS vulnerability with basic origin reflection
        • CORS vulnerability with trusted null origin
        • CORS vulnerability with trusted insecure protocols
      • Server-side template injection
        • Basic server-side template injection
        • Basic server-side template injection (code context)
      • Server-Side Request Forgery (SSRF)
        • Basic SSRF against the local server
        • Basic SSRF against another back-end
        • Blind SSRF with out-of-band detection
        • SSRF with blacklist-based input filter
        • SSRF with filter bypass via open redirection vulnerability
      • Path Traversal
  • 🟩HTB Writeups
    • Heal
Powered by GitBook
On this page
  • Lab Description
  • Walkthrough
  • Step 1: Observing the Login Page
  • Step 2: Capturing the Login Request
  • Step 3: Enumerating Usernames
  • Step 4: Brute-Forcing the Password
  • Step 5: Verifying Access

Was this helpful?

  1. Writeups
  2. Portswigger Labs
  3. Authentication

Username enumeration via subtly different responses

PreviousPassword reset broken logicNextUsername enumeration via response timing

Last updated 6 months ago

Was this helpful?

Lab Description

Walkthrough

Step 1: Observing the Login Page

On the login page, we see a generic error message: Invalid username or password. Our task is to determine if there's any subtle difference in the server's response for valid usernames.

Step 2: Capturing the Login Request

Using Burp Suite, intercept the login request when attempting to log in with arbitrary credentials (e.g., test:test).

The captured request contains two key parameters:

  • Username: The input username.

  • Password: The input password.

Send this intercepted request to Intruder for automated testing.

Step 3: Enumerating Usernames

Configuring Intruder for Username Testing

  1. Set Payload Positions:

    • Clear all selected payload positions and mark only the username parameter.

  2. Payloads:

    • Go to the Payloads tab and paste the provided username list.

  3. Start the Attack:

    • Launch the attack to send the modified requests.

Analyzing Responses

Once the attack finishes, filter the results to search for any differences in responses:

  • Use Burp's search feature with the error message text Invalid username or password. and enable negative search.

  • Identify responses that deviate slightly from the standard error message.

Upon doing that, we can see that there's one username with a slightly different error message, invalid username or password. vs invalid username or passwordnotice the mission dot

guessing with a different response that this username is a valid one

Step 4: Brute-Forcing the Password

Configuring Intruder for Password Testing

  1. Set Payload Positions:

    • Modify the username parameter to the valid username (app01) identified earlier.

    • Mark the password parameter as the payload position.

  2. Payloads:

    • Use the provided password list as the payload.

  3. Start the Attack:

    • Launch the attack to test passwords for the identified username

Analyzing Responses

After sorting the results by status codes, we find a request that returns a 302 Found response. This indicates that the correct password has been identified.

Step 5: Verifying Access

Using the discovered credentials (app01:qazwsx), we log into the account successfully and access the user’s account page.