The lab

here is how portswigger describes it

This lab is vulnerable to username enumeration. It uses account locking, but this contains a logic flaw. To solve the lab, enumerate a valid username, brute-force this user's password, then access their account page.

the earlier enumeration labs leaked valid usernames through a missing dot and through response timing. this one leaks them through its own defence. the account lockout that is meant to stop brute forcing only kicks in for accounts that actually exist, which quietly tells us which usernames are real.

why a lockout can become an oracle?#

locking an account after a handful of failed logins is a reasonable brute force defence. the flaw here is that the lock only happens to real accounts. the app cannot lock an account that does not exist, so if we hammer a list of usernames with repeated failures, only the valid ones will ever respond with a lockout message.

that turns the defence into the very oracle it was supposed to deny us. instead of comparing single responses, we send several failed attempts at each username in one go and watch for the one that starts complaining about too many attempts. a username that can be locked is a username that exists. the catch is that the lockout message only appears once the threshold is crossed, so we have to make sure every candidate gets tried enough times to trip it.

Step 1 - Hit each username several times with a cluster bomb#

we capture the login request, send it to intruder, and choose the cluster bomb attack type, which runs every combination of two payload sets against each other.

we put a payload position on the username, then add a second, empty payload position at the end of the request body with add section. that second position does not change the request content at all, it exists purely so we can repeat each username several times.

in the payloads panel we load the username wordlist into position one. for position two we pick the null payloads type and tell it to generate five, which injects nothing but makes intruder fire the request five times. because cluster bomb pairs every username with all five nulls, each username gets attempted five times in a row, which is enough to trip the lockout on a real account.

Step 2 - Spot the username that locks#

we run the attack and scan the results. one username's responses stand out as longer than the rest, and reading one of them shows a different error, You have made too many incorrect login attempts. rather than the usual invalid credentials message.

that lockout only appears because the account is real and our five tries pushed it over the limit. every other username, being fake, just keeps returning the plain error no matter how often we try. so this is our valid username, and we note it.

Step 3 - Brute force the password with a Sniper attack#

now we switch to the sniper attack type, which drives a single payload position. we clear the previous positions, put one position on the password, and fix the username to the valid one we just found. then we load the password wordlist and start the attack.

the results show a few different error messages, which is expected now that the account can lock during the run. the response we care about is the odd one out, the single attempt that came back with no error message at all. no error means that guess was not rejected, so that is the correct password.

Step 4 - wait out the lock and solve#

there is one last snag. our own guessing has probably left the account in a locked state, so trying the password straight away would fail even though it is right. the lock is temporary, so we wait about a minute for it to clear, then log in with the username and password we uncovered.

with this, the lab is solved!