📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
Everyone knows about brute force. You run Hydra, you pick rockyou.txt, you point it at the login form. And then you hit the rate limit after ten requests and your attack is dead.
That’s because modern login pages don’t have one protection — they have layers. Rate limiting. Account lockout. CAPTCHA. MFA. IP reputation checks. The hunters consistently finding authentication bypass findings on major bug bounty programmes aren’t brute-forcing in the traditional sense. They’re testing whether each protection layer actually works, and finding the specific implementation flaws where one layer fails without breaking the others.
I’ve found rate limiting bypasses on FTSE 100 company login pages by adding a single header. I’ve found CAPTCHA token reuse on a financial services platform that meant the CAPTCHA provided exactly zero protection. I’ve found MFA OTP brute force on a healthcare portal with no rate limiting on the OTP entry form. These aren’t exotic attacks — they’re systematic testing of controls that developers implemented incorrectly. Here are the five that pay most consistently.
🎯 What You’ll Know After This
How to test X-Forwarded-For header injection for rate limit bypass — a 5-minute check on every login form
CAPTCHA token reuse testing — one request to confirm, no solving service needed
Username enumeration via timing difference — finding valid accounts before brute force starts
Account lockout bypass patterns that appear on real bug bounty programmes
MFA OTP brute force and race condition techniques in authorised testing contexts
⏱️ 25 min read · applicable to your next bug bounty session ### 📋 How Hackers Brute Force Modern Login Pages – Contents 1. Bypass 1 — Rate Limit via IP Header Injection 2. Bypass 2 — CAPTCHA Token Reuse 3. Bypass 3 — Username Enumeration via Timing 4. Bypass 4 — Account Lockout Logic Flaws 5. Bypass 5 — MFA OTP Rate Limiting Absence 6. Chaining: Enumeration + Bypass = Account Takeover ## Bypass 1 — Rate Limit via IP Header Injection Rate limiting should track failed attempts by account, not by IP. But a lot of implementations track by source IP — because it’s simpler to implement. That implementation choice creates the bypass: if the application respects the X-Forwarded-For header as the source IP, rotating that header value resets your attempt counter.
The test takes two minutes. Add an X-Forwarded-For header with a fake IP to your login request. Confirm the application accepts it (no error). Then change the IP value and retry a failed attempt — does the failed attempt counter reset? If yes, the rate limiting is bypassable by anyone who can send custom headers. In Burp Intruder, use a Pitchfork attack type with one payload on the password field and one on the X-Forwarded-For value.
RATE LIMIT BYPASS — IP HEADER INJECTIONCopy
Test 1: Does the application accept X-Forwarded-For?
POST /login HTTP/1.1
Host: target.com
X-Forwarded-For: 10.0.0.1
X-Real-IP: 10.0.0.1
username=test&password=wrong
Test 2: Does changing the value reset the rate limit?
Send 4 failed attempts with IP = 10.0.0.1
Change X-Forwarded-For to 10.0.0.2
If attempt counter resets → rate limit bypass confirmed
Burp Intruder Pitchfork automation
Payload set 1 (password): wordlist.txt
Payload set 2 (X-Forwarded-For): sequential IPs
Result: unlimited password attempts without triggering lockout
Other headers to test for same bypass
X-Real-IP: 10.0.0.2
X-Originating-IP: 10.0.0.2
X-Client-IP: 10.0.0.2
True-Client-IP: 10.0.0.2
Bypass 2 — CAPTCHA Token Reuse
Most developers implement CAPTCHA by integrating Google reCAPTCHA or hCaptcha and checking that the response token is valid. What many don’t implement: checking that the token hasn’t been used before. A valid solved token should be single-use. If the server accepts the same token on multiple requests, CAPTCHA provides no protection against automated testing — you solve it once manually and replay that token indefinitely.
The test is trivial. Solve the CAPTCHA once normally, capture the g-recaptcha-response parameter in Burp, and replay the login request with that same value multiple times. If subsequent requests succeed despite the token being “used,” token reuse is confirmed.
CAPTCHA TOKEN REUSE TESTCopy
Step 1: Solve CAPTCHA normally in browser
Step 2: Capture login POST in Burp — find g-recaptcha-response
POST /login
username=testuser&password=wrong&g-recaptcha-response=03ANYolqt…
Step 3: Send to Repeater — replay same request multiple times
Keep the g-recaptcha-response value identical
Change only the password field
Expected (secure): 2nd request returns CAPTCHA error
Vulnerable: 2nd, 3rd, 10th request all return “wrong password”
(wrong password = CAPTCHA accepted, password just incorrect)
Other CAPTCHA bypass tests
Test: Remove g-recaptcha-response parameter entirely
→ If accepted: CAPTCHA not enforced server-side at all
Test: Send empty string: g-recaptcha-response=
→ If accepted: trivial bypass, no solving needed
securityelites.com
Login Protection Bypass Decision Tree
Rate Limiting Present?
YES → Test X-Forwarded-For header rotation → resets counter? = bypass
NO → Test without any bypass → unlimited attempts
CAPTCHA Present?
YES → Test token reuse (replay same g-recaptcha-response)
YES → Test empty/missing token parameter
Account Lockout Present?
YES → Test lockout per-IP vs per-account → IP bypass via header?
YES → Test password spraying (1 password per account) — avoids lockout
MFA Present?
YES → Test OTP rate limiting separately → brute force 6-digit OTP?
YES → Test OTP reuse within validity window
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)