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
The rejection messages differ only by a final period. A Grep Extract column makes that character visible: activestat lacks the punctuation used for nonexistent users, and the later password attack produces the redirecting 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
Extract the complete login warning in Intruder, locate the username whose warning omits the trailing period, then test the password list for activestat. Open the unique redirecting response to reach the account page.


Verification
The final capture shows the Academy marking the username enumeration via subtly different responses 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.