PortSwigger lab: Broken brute-force protection, IP block

Authentication mechanisms are designed to protect user accounts from unauthorized access. One of the most common protections implemented by modern applications is brute-force mitigation, which attempts to prevent attackers from repeatedly guessing passwords. However, these controls are only effective when implemented correctly.

In this lab, the application attempted to protect user accounts by temporarily blocking login attempts after multiple authentication failures. While this appeared to be a strong defense at first glance, further testing revealed a logic flaw that allowed the restriction to be bypassed entirely.

The objective of this lab was to obtain access to the victim account carlos by exploiting weaknesses in the application's brute-force protection mechanism.

Step 1: Understanding the login protection

After accessing the lab, I began by testing the login functionality using random credentials while intercepting requests through Burp Suite. Initially, the application behaved as expected and returned standard authentication failure messages. To better understand how the protection mechanism worked, I continued submitting invalid credentials. After approximately three failed login attempts, the application temporarily blocked any further authentication requests.

Step 2: The Interesting discovery

While testing the lockout mechanism, I noticed an interesting behavior. The application reset the failed login counter whenever a successful authentication occurred. In other words, the protection was not solely tracking failed attempts, but also clearing them after a valid login.

This created a logic flaw that could be abused. By inserting a legitimate login before the lockout threshold was reached, it was possible to continuously reset the counter and avoid triggering the IP-based restriction altogether. This observation became the foundation of the exploitation process.

Illustration:

1. user:user    -> failed
2. user:user    -> failed
3. wiener:peter -> success -> counter reset
4. user:user    -> failed
5. user:user    -> failed
6. wiener:peter -> success -> counter reset

1. user:user    -> failed
2. user:user    -> failed
3. wiener:peter -> success -> counter reset
4. user:user    -> failed
5. user:user    -> failed
6. wiener:peter -> success -> counter reset

Step 3: Turning the Flaw Into an Attack

If a successful login reset the failed-attempt counter, then there was no need to avoid the protection.

Instead, I could simply keep resetting it.

I sent the login request to Burp Intruder and configured a Pitchfork attack.

The idea was simple:

1. Log in successfully as wiener.
2. Attempt a password guess for carlos.
3. Log in successfully as wiener.
4. Attempt another password guess for carlos.

Find the usernames & passwords here: https://github.com/Spoorthijinka16/Usernames-Passwords

Step 4: Finding Carlos's Password

After loading the lists, I launched the attack.

Most responses looked identical. However, one response stood out from the rest.

With the correct password identified, I authenticated as carlos and gained access to the account.

Conclusion:

This lab demonstrates how brute-force protections can fail when they rely on flawed business logic. Although the application enforced temporary IP-based restrictions after multiple failed login attempts, the failure counter was automatically reset whenever a valid login occurred.

By alternating legitimate authentication requests with password guesses, it was possible to bypass the protection mechanism entirely and perform an unrestricted password attack against the target account. Effective brute-force protections should track authentication failures independently and should not allow successful logins on unrelated accounts to reset security controls protecting other users.