PortSwigger Lab Write-Up: Username Enumeration Via Different Responses

Category: Authentication Difficulty: Apprentice

PortSwigger is basically a company that focused on developing cybersecurity software. They are best known for their main product, Burp Suite, which is used for penetration testing and web application security. PortSwigger also offers a variety of tools for security testing and scanning, and is dedicated to securing the web. Additionally, they have the PortSwigger Academy, a learning platform for security that I will write about here.

For this session, I'm going to solve a lab under the Authentication's category that named "Username Enumeration Via Different Responses". Based on the link below, this lab is vulnerable to username enumeration and password brute-force attacks. It has an account with a predictable username and password, which can be found in the provided wordlists (candidate usernames and candidate passwords). To solve the lab, I need to enumerate a valid username, brute-force this user's password, then access their account page.

Lab: Username enumeration via different responses This lab is vulnerable to username enumeration and password brute-force attacks. It has an account with a predictable…

Lets get into it!

In this lab, I used Burp Suite and a browser with the Burp proxy configured. I opened Burp Suite and made sure the intercept was on. Then, I accessed the lab as usual and land on a blog site.

I tried logging in with random credentials which is test:test, just to capture a request. Then I switched over to Burp Suite and looked for the POST '/login' row in the HTTP history.

I right-clicked that request and sent it to Intruder. Once I opened the Intruder tab, I could see the request body containing 'username=test' & 'password=test'.

I cleared all the automatic § markers that Burp added by default, then selected only the value test in the username field and clicked "Add §" to mark it as the target position.

Then, I set the attack type was set to Sniper, because I only needed to target one parameter at a time.

I went to the Payloads tab and loaded the candidate usernames wordlist provided by the lab.

After that, clicked "Start attack" and let it run.

Once it finished, I checked the results table and looked for a response with a status code or length that different from the rest. After finding it, that would indicate the valid username I needed. Below we can see, the user named 'atlanta' is the only user that has 3354 length.

After finding the valid username, I went back to the same intruder tab. This time, I cleared the marker on the username field and set it as a static value (the valid username I found), then added a marker on the password field instead, so it looked like password=§test§.

And I also went to the Payloads tab again and loaded the candidate passwords word list this time.

After that, I clicked "Start attack" once more.

I checked the results and looked for a response with a different length or status code, which usually points to a 302 redirect for the correct password, while the rest stayed at 200.

Then, I went back to the lab and use the credentials I just got to log in (atlanta:112233).

And finally the lab was Solved!

This lab shows how tiny differences, like a slightly different error message or response length can quietly reveal whether a username is right or even exist. Once an attacker knows the username is valid, brute-forcing the password becomes much easier since there's only one unknown left to guess. The fix we can do is to make login errors look exactly the same no matter what's wrong, and keep response times and lengths consistent. Adding rate limiting or account lockout also helps slow down brute-force attempts overall.

That's all for this session. Thanks for reading!