Authorization disclaimer. This walkthrough is limited to the intentionally vulnerable PortSwigger Web Security Academy lab linked below. Test only systems you own or are explicitly authorized to assess.
Overview
Repeated login attempts produce an observable difference for valid and invalid usernames, allowing the lab account to be identified before password testing.

Lab objective/setup
The supplied credentials, candidate lists, email client, and exploit server are used only inside this Academy instance to reproduce the authentication-flow evidence shown below.
What I observed
Only existing accounts enter the locked state after repeated failures. Five attempts per username expose akamai through the lock warning; a second Intruder run identifies 123321 by its redirect response.

Why it is vulnerable
Authentication failures disclose account existence through response text, lockout behavior, or another stable response characteristic.
Walkthrough in the authorized PortSwigger lab
Use Cluster Bomb so each username receives five empty-password attempts, then select the account whose body reports a one-minute lock. Test passwords for akamai and open the distinct 302 response.


Verification
The final capture shows the Academy marking the username enumeration via account lock exercise as solved after the documented request sequence. No testing was performed outside the isolated lab.

Impact and defensive lesson
Authentication controls must bind identity, challenge state, reset tokens, and retry counters to server-side transactions. Return uniform failures, rate-limit by both account and trusted client signals, and use random revocable persistent-session tokens rather than credential-derived values.