Authentication on an's security blog

Broken brute-force protection, IP block | Practitioner

Mon, 08 Jun 2026 15:31:16 +0800

The key to this lab is to occasionally insert our valid credentials inbetween the enumerations, so that maybe the rate limit imposed on our IP is reset to zero. This is never guaranteed for every web app.

To solve this, we can either use the Turbo Intruder extension or macros. But for the sake of simplicity, we need only edit the username and password payloads so that our valid credential and our brute-forcing attempts alternate. The password wordlist can be done through a simple Python script as follow:

Username enumeration via response timing | Practitioner

Mon, 08 Jun 2026 14:15:16 +0800

First I thought this is a straightforward lab: just pump into Intruder and compare response received times. But the lab also implements some sort of IP-based brute-force protection, where if you guess too many incorrect attempts, it will lock you out.

To solve this, we shall use the X-Forwarded-For header, which is used to identify the source IP address connecting through a proxy or load balancer. This is good for redirecting traffic but opens up to spoofing. If we are locked out, we just need to tweak the IP address every now and then, and include our valid credentials occasionally in our payload to avoid being locked out.

Username enumeration via subtly different responses | Practitioner

Mon, 08 Jun 2026 13:34:16 +0800

Before going into the solution, I just want to say I wasted time eyeballing for the slightest odd-one-out response received time and response length (rip). Turns out there is a nifty feature in Intruder called Grep-Extract. This feature will extract any useful info of our choosings from responses into the attack table.

Firstly, we shall use Grep-Extract to harvest pieces of data from our responses, including cookies, tokens, error messages and so on. This time we will highlight the Username or password invalid text Notice that there is one less dot from akamai, turns out that’s our valid username. After that, we just proceed with password brute-forcing normally. Very nifty.

2FA simple bypass | Apprentice

Tue, 02 Jun 2026 16:14:16 +0800

This excerpt from PortSwigger sums this up pretty nicely:

“At times, the implementation of two-factor authentication is flawed to the point where it can be bypassed entirely.

If the user is first prompted to enter a password, and then prompted to enter a verification code on a separate page, the user is effectively in a “logged in” state before they have entered the verification code. In this case, it is worth testing to see if you can directly skip to “logged-in only” pages after completing the first authentication step. Occasionally, you will find that a website doesn’t actually check whether or not you completed the second step before loading the page.”

Username enumeration via different responses | Apprentice

Tue, 02 Jun 2026 15:23:16 +0800

Using the provided username and password wordlists, my initial solution is to simply run a cluster bomb attack in Intruder to test all permutations possible. But on the Community version this took an excruciatingly long time because of the rate limit.

Another way to do this is to perform a sniper attack to enumerate only the valid usernames first, and from there we have a much shorter list of usernames to check their passwords.