What two things must ASM know about a page before it can run brute-force protection on it?

Correct: b. ASM must know the login URL and which parameters carry the username and password. Without the username/password parameter mapping it cannot tell a success from a failure, so it cannot count failed logins.

Priya sees legitimate users getting CAPTCHA'd during a marketing launch. The login isn't under attack. Best first move?

Correct: a. A burst of real traffic crossed the distributed failed-login rate threshold. Raise the detection threshold / tune the trigger for the launch window (or use Client-Side Integrity first), rather than disabling protection entirely (c), which leaves the login exposed.

You want brute-force protection that adapts to each user session, not just per-IP. Which detection criteria should you enable?

Correct: c. Session-based (device-ID) detection tracks failed logins per client session/device, catching an attacker who rotates IPs but reuses one browser/device — a gap that pure source-IP counting misses.

After enabling brute-force protection, the Brute Force Attacks report shows 'Detected' but never 'Mitigated'. Why?

Correct: b. The policy is likely in Transparent mode or the mitigation action is set to Alarm only. ASM detects and logs the attack but isn't enforcing a blocking/challenge action — switch the policy to Blocking and set a mitigation response.

An engineer proposes blocking the source IP for 24 hours after 10 failed logins, with no CAPTCHA. What's the risk for a large enterprise behind a NAT/proxy?

Correct: c. Many real users can share one egress IP behind corporate NAT or a carrier proxy. A blanket source-IP block punishes everyone behind that IP. Prefer escalating challenges (Client-Side Integrity → CAPTCHA) and session-based detection so you isolate the actual attacker.

For an internet bank login hit by both a single noisy IP and a slow global botnet, what's the most complete design?

Correct: c. Enable source-based mitigation (for the noisy IP), distributed mitigation (for the botnet), escalating Client-Side Integrity → CAPTCHA challenges, plus leaked-credential detection for stuffing — defense in depth, validated in the Brute Force Attacks report. A single source threshold (a) misses the distributed half.

What two things must ASM know about a page before it can run brute-force protection on it?

Correct: b. ASM must know the login URL and which parameters carry the username and password. Without that mapping it can't tell a success from a failure, so it can't count failed logins.

Priya sees legitimate users getting CAPTCHA'd during a marketing launch. The login isn't under attack. Best first move?

Correct: a. A burst of real traffic crossed the distributed failed-login rate threshold. Raise/tune the detection trigger for the launch window (or use Client-Side Integrity first), rather than disabling protection (c), which leaves the login exposed.

You want brute-force protection that adapts to each user session, not just per-IP. Which detection criteria should you enable?

Correct: c. Session-based (device-ID) detection tracks failed logins per client session/device, catching an attacker who rotates IPs but reuses one browser/device — a gap that pure source-IP counting misses.

After enabling brute-force protection, the Brute Force Attacks report shows "Detected" but never "Mitigated". Why?

Correct: b. The policy is likely in Transparent mode or the mitigation action is set to Alarm-only. ASM detects and logs the attack but isn't enforcing a blocking/challenge action — switch the policy to Blocking and set a mitigation response.

An engineer proposes blocking the source IP for 24 hours after 10 failed logins, with no CAPTCHA. What's the risk for a large enterprise behind a NAT/proxy?

Correct: c. Many real users can share one egress IP behind corporate NAT or a carrier proxy. A blanket source-IP block punishes everyone behind that IP. Prefer escalating challenges (Client-Side Integrity → CAPTCHA) and session-based detection so you isolate the actual attacker.

For an internet bank login hit by both a single noisy IP and a slow global botnet, what's the most complete design?

Correct: c. Enable source-based (for the noisy IP), distributed (for the botnet), escalating Client-Side Integrity → CAPTCHA challenges, plus leaked-credential detection for stuffing — defense in depth, validated in the Brute Force Attacks report. A single source threshold (a) misses the distributed half.

F5 ASM Brute Force & Credential Stuffing — Protect the Login Before It Falls

Q: Advanced WAF brute-force protection isn't triggering even under an obvious password-spray. What's the most likely cause?

Correct: c. Brute Force protection only runs once ASM has correctly detected the login URL plus the username and password parameters. If the login page wasn't configured (or auto-detection failed), there is no login to protect and nothing triggers. SSL/decryption (a) is a separate concern, and a high threshold (b) would slow detection, not stop it entirely.

Q: One IP sends 400 failed logins a minute; meanwhile 4,000 botnet IPs each try 2 logins. Which mitigation mode catches the second attack?

Correct: b. The botnet is a distributed brute force — no single IP crosses a source threshold. Distributed mitigation watches the failed-login rate for the login URL as a whole, so it catches the low-and-slow swarm that source-based mitigation misses.

Q: Why does Advanced WAF prefer Client-Side Integrity (a JavaScript challenge) before showing a CAPTCHA?

Correct: a. Client-Side Integrity silently proves the client can run JavaScript, which most simple bots can't — it stops them with zero friction for real users. CAPTCHA is escalated only if the attack continues, because it adds friction for humans.

Q: Credential stuffing succeeds with valid username/password pairs and low per-IP volume. Which ASM feature is designed for exactly this?

Correct: d. Credential-stuffing / leaked-credential detection checks submitted credentials against a database of known-breached credentials, so it flags logins that are technically valid but use stolen pairs — something a failed-login threshold alone never sees.

Most engineers think…

"I turned on Brute Force Protection, so login attacks are handled."

Wrong — and this is the #1 reason a WAF "doesn't stop the attack". Brute-force protection only runs once ASM knows the page is a login: the login URL, and which form parameters carry the username and password. Without that mapping, ASM can't tell a successful login from a failed one — so it can't count failures, and nothing triggers. And even with detection on, a single per-IP threshold misses a distributed botnet entirely. Real login protection is three instincts: see the login, tell a noisy IP from a slow swarm, and escalate friction only when you must.

Picture a bank branch where the guard counts how many times each person fails the ID check at the counter. That only works if the guard knows which counter is the ID counter and what a failed check looks like. ASM is the same: before it can count failed logins, it must know the login URL and which parameters carry the username and password.

This is the single most-missed step. BIG-IP Advanced WAF (formerly ASM) can auto-detect login pages during policy building, but on custom apps and APIs you almost always configure it by hand under Security ▸ Application Security ▸ Sessions and Logins ▸ Login Pages. You tell ASM: this is the login URL, this parameter is the username, this parameter is the password, and here is how a successful vs failed login looks (an HTTP redirect, a string in the response, or a status code). Get this right and ASM can finally count failures. Get it wrong and brute-force protection silently does nothing.

👉 So far: ASM must know the login URL + username/password params + what failure looks like, or it can't count a single failed login. Next, see exactly where this check sits on the path.

Figure 1 — A login attempt only gets counted once ASM knows it's a login

The order matters: identify the login → judge success vs failure → count failures → mitigate over threshold. Skip step 1 and the rest can't run.

Sneha at Infosys faces this

Sneha enabled Brute Force Attack Prevention, then ran a test password-spray against the app's login. Nothing triggered. The feature "doesn't work".

Likely cause

ASM never detected the login page. The app is a custom SPA that posts to /api/auth, and auto-detection missed it — so there's no login URL and no username/password mapping for ASM to count failures against.

DiagnosisSecurity ▸ Application Security ▸ Sessions and Logins ▸ Login Pages → is /api/auth listed?

Fix

Add the login page manually: URL /api/auth, username parameter uname, password parameter pword, and a failed-login criterion (e.g. HTTP 401 or response string "Invalid credentials").

Verify

Re-run the spray. Security ▸ Reporting ▸ Application ▸ Brute Force Attacks now shows detections counting up against the login URL.

▶ Watch a login attempt get counted — then watch ASM go blind

Rahul at TCS sends a wrong password to /login. Press Play for the login-aware path, then Break it to see what happens when the login URL was never configured.

① POST203.0.113.7 POSTs uname=admin&pword=Spring2026! to /login

▼

② MATCH LOGINASM recognises /login as the login URL and reads the username/password params

▼

③ JUDGEResponse is 401 → ASM marks it a failed login, increments the counter

▼

④ THRESHOLDCounter crosses the threshold → mitigation begins, event logged

Press Play to step through the login-aware detect path. Then press Break it.

Quick check · Q1 of 10

Advanced WAF brute-force protection isn't triggering even under an obvious password-spray. What's the most likely cause?

a) SSL inspection / decryption is off b) The detection threshold is set too high c) ASM never detected the login URL + username/password parameters, so it can't count failures d) The pool member is down

Correct: c. Brute-force protection only runs once ASM has detected the login URL plus the username and password parameters. No login mapping means it can't tell a success from a failure, so it counts nothing and never triggers. A high threshold (b) would slow detection, not silence it completely.

Pause & Predict

A single IP hammers your login 400 times a minute — easy to spot and block. But the next attacker spreads 8,000 attempts across 4,000 IPs, 2 each. A per-IP threshold of "10 failures" never trips on any single IP. What kind of detection would catch this swarm? Type your guess.

Answer: Distributed brute-force mitigation. Instead of counting failures per source IP, it watches the overall failed-login rate for the login URL. When the page-wide failure rate spikes — even though no single IP is noisy — ASM treats it as a distributed attack and mitigates. That's exactly Path 2.

② Source-based vs distributed — one noisy IP vs a slow swarm

There are two completely different shapes of brute force, and ASM has a separate mitigation for each. Mix them up and you'll block the easy attacker while the dangerous one walks straight through.

Source-based brute force is the loud one: a single IP fires hundreds of failed logins. ASM counts failures per source IP and, when one IP crosses the source threshold, mitigates that IP. Easy.

Distributed brute force is the quiet, dangerous one: thousands of botnet IPs each try only 2–3 logins. No single IP ever looks suspicious. So ASM watches the overall failed-login rate for the login URL — when the page-wide failure rate spikes, it mitigates the attack as a whole, even though every individual IP is "innocent".

Analogy: source-based is one person trying 500 keys on one door — the guard spots them instantly. Distributed is 500 people each trying one key — no single person looks suspicious, but the guard watching the door notices it's being jiggled non-stop.

Pro tip — turn on BOTH, plus session-based

A real internet login gets both shapes of attack. Enable source-based (for the noisy IP), distributed (for the botnet), and where available session-based / device-ID detection (tracks failures per client session, catching an attacker who rotates IPs but reuses one browser). Source-IP alone is the classic gap: it misses the distributed swarm and over-blocks shared NAT egress IPs.

👉 So far: source-based counts per IP; distributed watches the whole login URL's failure rate. Next, see why one threshold can't cover both — side by side.

Figure 2 — Before / after: a source-only threshold vs source + distributed

Source-based earns its place on the loud attacker; distributed earns its place on the quiet one. The breach lives in the gap between them.

Priya at Flipkart faces this

Priya configured a source-based threshold of 20 failed logins. The SOC still sees account takeovers, but the Brute Force report shows almost no blocked IPs.

Likely cause

The attack is distributed. Each botnet IP makes 3–4 attempts and stays under 20, so source-based never fires. Only distributed detection — watching the login URL's overall failure rate — can catch it.

DiagnosisSecurity ▸ Application Security ▸ Brute Force Attack Prevention → is "Distributed Brute Force" detection enabled?

Fix

Enable distributed mitigation alongside source-based, set a sensible page-wide failed-login rate trigger, and add session-based detection so IP-rotating bots are tracked by device.

Verify

Re-run the distributed test. The Brute Force Attacks report now shows a "Distributed attack — mitigated" entry with the challenge action applied.

F5 ASM — L7 DoS & Behavioral F5 ASM — Bot Defense F5 Simulator Lab

Quick check · Q2 of 10

One IP sends 400 failed logins a minute; meanwhile 4,000 botnet IPs each try 2 logins. Which mitigation mode catches the second attack?

a) Source-based — it counts failures per IP b) Distributed — it watches the login URL's overall failed-login rate c) Neither — 2 attempts per IP is always benign d) A higher source threshold

Correct: b. The botnet is a distributed brute force — no single IP crosses a source threshold. Distributed mitigation watches the failed-login rate for the login URL as a whole, so it catches the low-and-slow swarm that source-based mitigation misses.

Pause & Predict

ASM has decided this is an attack. It could just block immediately — but blocking everyone risks punishing real users behind a shared NAT IP. What's a low-friction first step ASM can take that stops a dumb bot but is invisible to a real human? Type your guess.

Answer: A Client-Side Integrity challenge — ASM sends a small JavaScript puzzle the browser must solve and echo back. A real browser solves it silently (the user sees nothing). A simple script bot can't run the JS, so it fails and is stopped — with zero friction for humans. CAPTCHA only escalates if the attack continues. That's Path 3.

③ The escalation stack — friction only when you must

Once ASM decides a login is under attack, it doesn't go straight to a hard block. It escalates through a mitigation stack, adding friction one rung at a time so legitimate users feel the smallest possible interruption.

1. Client-Side Integrity — a silent JavaScript challenge. The browser solves a small puzzle and echoes it back. Humans see nothing; script-only bots fail here. This is the preferred first response — it filters the cheap bots at zero cost to real users.
2. CAPTCHA — if the attack persists (often the better bots that do run JS), ASM presents a CAPTCHA. It adds real friction, so it's escalated, not led with.
3. Blocking / drop — the hard stop. For a clearly malicious source or a sustained distributed attack, ASM drops the request. Reserve this for the cases where challenges aren't enough, and prefer scoping it (per source / per session) over a blanket IP ban.

Analogy: a metro gate. First it just checks your card silently (Client-Side Integrity). If something's off, a guard asks you a quick question (CAPTCHA). Only if you clearly can't pass does the gate physically lock (block). You don't lock the gate on every passenger — you escalate.

👉 So far: ASM escalates JS challenge → CAPTCHA → block, lightest friction first. Next, watch the escalation run, and see the real screen where you set it.

Figure 3 — The escalating mitigation stack, lightest friction first

Each rung adds friction. The art of brute-force defense is stopping the attacker on the lowest rung that works.

🖥️ This is the screen you'll use — Security ▸ Application Security ▸ Brute Force Attack Prevention ▸ Login Page. (Recreated for clarity — your console matches this.) Pins ①–④ mark the fields this lesson sets.

https://10.10.20.4/tmui · BIG-IP® Advanced WAF — Configuration utility

Local Traffic

Security ▸

Application Security ▸

Sessions and Logins

Brute Force Attack Prevention

Reporting ▸

Brute Force Attack Prevention : Configuration

Current edited security policy app_pol (Blocking) — changes are staged until you click Apply Policy

① Login Page	`/login` (user=`uname`, pass=`pword`)
② Source-Based Protection	Enabled Failed logins ≥ 20 / min per IP
③ Distributed Protection	Enabled Page failed-login rate ≥ 100 / min
④ Mitigation (escalation)	Client-Side Integrity → CAPTCHA → Drop
Credential Stuffing	Leaked-credential check ON

▶ Watch mitigation escalate — then watch it over-block

Karthik at Wipro's login is under attack. Play the healthy escalation, then Break it to see the over-blocking trap.

① DETECTEDFailed-login burst crosses the threshold for /login

▼

② JS CHALLENGEClient-Side Integrity puzzle sent — real browsers pass silently, dumb bots fail

▼

③ CAPTCHASmarter bots persist → ASM escalates to a CAPTCHA challenge

▼

④ BLOCKSustained malicious source → scoped drop, logged in the Brute Force report

Press Play for the healthy escalation. Then press Break it.

The four mitigation mechanics — tap each card

Each card front names the mechanic; the back gives you the "so what" — when to reach for it.

🧩

Client-Side Integrity

tap to flip

Silent JS challenge the browser solves automatically. So what: your zero-friction first filter — stops script bots without a real user ever noticing.

🤖

CAPTCHA

tap to flip

Human-only challenge. So what: escalate to it only when the silent challenge isn't enough — it adds real friction for humans.

🌐

Distributed

tap to flip

Watches the login URL's overall failure rate, not per-IP. So what: the only mode that catches a slow botnet where no single IP looks bad.

🔑

Leaked-Cred Check

tap to flip

Compares submitted credentials to a breached-credential database. So what: catches credential stuffing — valid-but-stolen logins a failure counter never sees.

Quick check · Q3 of 10

Why does Advanced WAF prefer Client-Side Integrity (a JavaScript challenge) before showing a CAPTCHA?

a) It silently proves the client can run JS — stopping simple bots with zero friction for real users; CAPTCHA is escalated only if needed b) CAPTCHA doesn't work on mobile c) JavaScript challenges are more secure than any CAPTCHA d) They are the same mechanism with different names

Correct: a. Client-Side Integrity silently proves the client can run JavaScript, which most simple bots can't — it stops them with zero friction for real users. CAPTCHA is escalated only if the attack continues, because it adds friction for humans.

Pause & Predict

A botnet uses valid username/password pairs leaked from another site's breach. Each login succeeds, so a failed-login counter never fires. How could ASM possibly flag these technically-valid logins as malicious? Type your guess.

Answer: Leaked-credential / credential-stuffing detection. ASM checks the submitted username/password against a database of known-breached credentials. If the pair appears in that breach corpus, ASM flags or challenges the login even though it's technically valid — because a stuffing bot is reusing stolen pairs. That's Path 4.

④ Credential stuffing & validating — the stolen-key attack, proven

Credential stuffing is the attack that breaks a pure failed-login defense. The attacker isn't guessing — they're replaying real pairs from another site's breach, betting users reused passwords. Most attempts succeed on the first try, so there are no failures to count.

ASM answers this with leaked-credential detection: it compares the submitted credentials against a known-breached-credentials database. A match means "this pair is in the wild" — so even a valid login gets flagged or challenged. Pair this with the escalation stack and session-based detection, and you stop the stuffing bot while real users sail through.

Build it — the configuration

You wire all of this on one screen. Here's the order: map the login, enable both detection shapes, set the escalation, then turn on leaked-credential checks.

tmsh — confirm the login page mapping for the policy

tmsh list asm policy app_pol login-pages
# expected: a login URL with username/password parameter mapping

(tmui) Security ▸ Application Security ▸ Sessions and Logins ▸ Login Pages
  URL:                 /login
  Username parameter:  uname
  Password parameter:  pword
  Login result:        Failed = HTTP status 401  |  Successful = redirect to /dashboard

Expected output

Login page "/login" found for policy app_pol.
  username-parameter uname
  password-parameter pword
# If this returns empty → ASM has no login to protect. Add it before anything else.

Brute Force Attack Prevention — enable both detections + escalation

Security ▸ Application Security ▸ Brute Force Attack Prevention ▸ Login Page = /login
  Source-Based Protection:      Enabled   Failed logins  >= 20 / min  per source IP
  Distributed Protection:       Enabled   Login-URL rate >= 100 / min (page-wide)
  Session-Based Protection:     Enabled   (track failures per device/session)
  Mitigation (escalating):      Client-Side Integrity  ->  CAPTCHA  ->  Drop
  Credential Stuffing:          Enabled   (Detect leaked credentials)
Apply Policy

Expected output

Policy "app_pol" applied. Brute Force Attack Prevention active on /login.
  source-based ON (20/min/IP) · distributed ON (100/min) · session ON
  mitigation: client-side-integrity -> captcha -> drop
  credential-stuffing leaked-credential check: ON

The trap behind a "working" config

Don't start with a hard Drop and a blanket source-IP block. Many real users share one egress IP behind corporate NAT or a carrier proxy — a 24-hour IP ban after 10 failures punishes everyone behind that IP. Lead with Client-Side Integrity, escalate to CAPTCHA, and use session-based detection so you isolate the actual attacker's device instead of a whole NAT pool. Tune thresholds during a known traffic spike (a sale, a launch) so a real burst doesn't get CAPTCHA'd.

👉 So far: leaked-credential checks catch stuffing; escalation + session detection avoid over-blocking. Next, prove it in the report — never trust the config screen.

▶ Watch a credential-stuffing login get caught

Aditya at HCL's login is hit with a valid-but-stolen pair. Play the leaked-credential catch, then Break it to see what slips through without the check.

① STUFFBot POSTs a valid pair uname=priya&pword=<leaked> to /login

▼

② NO FAILURELogin would succeed — a failed-login counter sees nothing

▼

③ LEAKED CHECKASM matches the pair against the breached-credential DB → flagged

▼

④ MITIGATEChallenge / step-up applied, event logged as credential stuffing

Press Play for the leaked-credential catch. Then press Break it.

Verify it worked — the report that ends the argument

Never claim brute-force protection works from the config screen. Run a safe test (a controlled spray from a lab IP, or a distributed test tool), then open Security ▸ Reporting ▸ Application ▸ Brute Force Attacks. Read the columns: was the attack Detected, and crucially Mitigated? Which mitigation action fired (challenge / CAPTCHA / block)? Source-based or distributed? If you see "Detected" but never "Mitigated", the policy is likely in Transparent mode or the action is Alarm-only — switch to Blocking.

Brute Force Attacks report — confirm detection AND mitigation

Security ▸ Reporting ▸ Application ▸ Brute Force Attacks
  Filter:  Policy = app_pol   ·   Login URL = /login   ·   last 1 hour
  Columns: Attack Type · Detection Mode · Mitigation · Action · Source

Expected output

2026-06-02 02:14  /login   Distributed brute force   Detected + Mitigated
   Action: Client-Side Integrity -> CAPTCHA   (page rate 240/min > 100)
2026-06-02 02:15  /login   Source brute force        Detected + Mitigated
   Action: Drop   Source: 203.0.113.7  (412 fails/min > 20)
2026-06-02 02:16  /login   Credential stuffing       Detected + Mitigated
   Action: Challenge   (submitted pair matched leaked-credential DB)
# "Detected" but never "Mitigated"? → policy is Transparent or action is Alarm-only. Switch to Blocking.

Quick check · Q4 of 10

Credential stuffing succeeds with valid username/password pairs and low per-IP volume. Which ASM feature is designed for exactly this?

a) A higher source-based failed-login threshold b) SSL inspection c) URL filtering d) Credential-stuffing / leaked-credential detection — it matches submitted pairs against a known-breached database

Correct: d. Credential-stuffing / leaked-credential detection checks submitted credentials against a database of known-breached credentials, so it flags logins that are technically valid but use stolen pairs — something a failed-login threshold alone never sees.

Figure 4 — Brute-force protection build cheat-sheet (screenshot this)

Six steps, six decisions, one golden rule. Screenshot this — it's the card you'll glance at while building the policy.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from F5 BIG-IP Advanced WAF docs + community Q&A, scoped to Brute Force & Credential Stuffing. For a live prod issue, paste your Brute Force Attacks export into chat.techclick.in.

🧠 In your own words

Type one line: why does a source-based failed-login threshold completely miss a distributed botnet? Then compare to the expert version.

Expert version: A source-based threshold counts failures per source IP. In a distributed attack, thousands of botnet IPs each make only 2–3 attempts, so no single IP ever crosses the threshold — every IP looks innocent. Distributed mitigation fixes this by watching the failed-login rate for the login URL as a whole, so the page-wide spike is caught even though no individual IP is noisy. If your answer mentioned "no single IP crosses the threshold", you've got it.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on F5 ASM brute-force protection at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

Login URL: The exact URL of your login form (e.g. /login, /api/auth). ASM must know it before it can watch for brute force.
Username / password parameters: The form-field names ASM maps to the username and password. Without this mapping ASM can't tell a successful login from a failed one.
Source-based brute force: Brute force from a single IP. ASM counts failed logins per source IP and mitigates that IP at the source threshold.
Distributed brute force: Brute force spread across thousands of IPs, each with only a few attempts. ASM watches the login URL's overall failed-login rate instead of per-IP counts.
Session-based detection: Tracks failed logins per client session/device, catching an attacker who rotates IPs but reuses one browser — and avoiding NAT over-blocking.
Client-Side Integrity: A silent JavaScript challenge the browser solves automatically. Real browsers pass invisibly; simple bots that can't run JS fail. The preferred first mitigation.
CAPTCHA: A human-only challenge. ASM escalates to it only when the silent challenge isn't enough, because it adds friction for real users.
Credential stuffing: Replaying username/password pairs stolen from one breach against other sites. Logins succeed, so failed-login counters don't fire.
Leaked-credential detection: ASM compares submitted credentials against a database of known-breached pairs; a match is flagged/challenged even on a technically valid login.
Brute Force Attacks report: The reporting screen (Security ▸ Reporting ▸ Application) showing whether each attack was Detected and Mitigated, and which action fired. The proof, not the config screen.

📚 Sources

F5 — BIG-IP Advanced WAF / ASM: Configuring Brute Force Attack Prevention · Detecting and Preventing Brute Force Attacks · Source-Based, Distributed & Session-Based detection · Login Page configuration. techdocs.f5.com / clouddocs.f5.com
F5 — About Credential Stuffing & Leaked Credentials Detection · Mitigating Credential Stuffing · F5 Distributed Cloud / Advanced WAF credential-protection. techdocs.f5.com
F5 — Client-Side Integrity & CAPTCHA mitigation · Configuring Login Pages and Login Enforcement (failed/successful login criteria). techdocs.f5.com
F5 DevCentral community — "Brute force protection not triggering" / "Login page not detected" / "Distributed brute force tuning" threads (login-mapping gotchas, NAT over-blocking, transparent-mode pitfalls). community.f5.com
OWASP — Credential Stuffing Prevention Cheat Sheet · Blocking Brute Force Attacks (escalating challenges, leaked-credential checks, why source-IP blocking over-blocks shared egress). owasp.org
F5 Certified 303 — BIG-IP ASM Specialist blueprint: brute-force & credential-stuffing mitigation, login enforcement, reporting (exam objectives). f5.com/education
Practitioner reference — "Have I Been Pwned" / breached-credential corpora and how WAFs use them for credential-stuffing detection; F5 Labs credential-stuffing reports. f5.com/labs

What's next?

You can now make ASM see the login, tell a noisy IP from a slow swarm, escalate friction sensibly, and catch credential stuffing — then prove it in the report. Next, see how ASM masks sensitive data in responses and blocks OWASP-class leaks with DataGuard.

Next · F5 ASM OWASP & DataGuard → Practice on exam.techclick.in →

F5 ASM Brute Force & Credential Stuffing — Protect the Login Before It Falls

🎯 By the end you will be able to

Pick where you want to start

See the Login First

Source vs Distributed

The Escalation Stack

Stuffing & Validate

▶ Watch a login attempt get counted — then watch ASM go blind

② Source-based vs distributed — one noisy IP vs a slow swarm

③ The escalation stack — friction only when you must

▶ Watch mitigation escalate — then watch it over-block

The four mitigation mechanics — tap each card

④ Credential stuffing & validating — the stolen-key attack, proven

Build it — the configuration

▶ Watch a credential-stuffing login get caught

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?

F5 ASM Brute Force & Credential Stuffing — Protect the Login Before It Falls

🎯 By the end you will be able to

Pick where you want to start

See the Login First

Source vs Distributed

The Escalation Stack

Stuffing & Validate

① See the login first — URL + username + password

▶ Watch a login attempt get counted — then watch ASM go blind

② Source-based vs distributed — one noisy IP vs a slow swarm

③ The escalation stack — friction only when you must

▶ Watch mitigation escalate — then watch it over-block

The four mitigation mechanics — tap each card

④ Credential stuffing & validating — the stolen-key attack, proven

Build it — the configuration

▶ Watch a credential-stuffing login get caught

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?