Skip to main content
Brute forcing a login form means throwing credentials at it until one works, either guessing a single user’s password (brute force) or trying one weak password across many usernames (password spraying, far less likely to trigger a lockout).

Brute Force

Many passwords against one username. Fast but loud, and the first thing a lockout policy is designed to catch.

Password Spraying

One or two common passwords against many usernames. Slower and stealthier, stays under most per-account lockout thresholds.
Login brute forcing is noisy and can lock out real accounts, especially in spraying mode against an AD-backed login. Confirm it’s in scope and, where possible, confirm the lockout threshold first.

​
Hydra

Hydra is the default choice for form-based login brute forcing, it handles both GET and POST-based forms and HTTP Basic Auth out of the box. HTTP Basic Auth doesn’t need a form definition, just the protected path.
POST form brute forcing needs the login path, the POST body with ^USER^/^PASS^ placeholders, and a condition string that tells Hydra what a failed attempt looks like. S= matches on success (e.g. a redirect status), F= matches on failure (e.g. an error string in the response body).
A fixed username against a specific login path, matching on an error string instead of a status code, useful when the app always returns 200 regardless of outcome.
If the app sets a session cookie before the login POST (common with CSRF-token-protected forms), pass it with the H=Cookie:... field at the end of the module string. You’ll usually need to grab a fresh cookie/token with curl first, since Hydra can’t do that itself.
Useful flags for tuning speed and output.
FlagPurpose
-t NNumber of parallel tasks (lower this against a lockout policy or a fragile target)
-fStop on first valid credential pair found
-vVVerbose, show every attempt as it happens
-o results.txtSave found credentials to a file
-IIgnore an existing restore file instead of resuming

​
FFUF for Login Forms

FFUF works just as well as Hydra for POST-based login brute forcing, and it’s often easier to tune since you can filter directly on response size or status, handy when the failure condition isn’t a clean string match.
Spraying one password across many usernames swaps which field FUZZ sits in, and needs two wordlists fuzzed together with FFUF’s multi-wordlist syntax.

​
Medusa

Medusa is a solid Hydra alternative, especially for HTTP Basic/Digest auth, and tends to be noticeably faster on large wordlists against simple auth schemes.

​
Burp Suite Intruder

Burp Intruder is the right tool once a form has CSRF tokens, multi-step logins, or anti-automation checks that Hydra and FFUF can’t handle cleanly. It replays through the same browser session, so tokens, cookies, and redirects all stay intact automatically.
Use Sniper mode with a single payload position on the password field for a standard brute force, or Pitchfork mode with two payload lists (usernames + passwords) wired to run in lockstep for password spraying, pairing each username with the same password per round instead of every combination.
Once you’ve fingerprinted the CMS (see Passive Information Gathering), a purpose-built tool usually beats a generic form brute force since it already knows the login endpoint and field names.
  • Password spraying instead of brute forcing keeps attempts-per-account low enough to stay under most lockout thresholds.
  • Rotating source IPs or X-Forwarded-For sometimes defeats an IP-based rate limit if the app trusts that header for its own logging/limiting (test this, don’t assume it).
  • Slowing down requests (-t 1, a sleep between Burp Intruder requests) avoids tripping a request-rate WAF rule, at the obvious cost of speed.
  • CAPTCHA-protected forms usually aren’t worth brute forcing directly, look instead for a parallel endpoint (an old API, a password reset flow) that skips the CAPTCHA entirely.

​
Quick Reference Tools

SecLists

Username and password wordlists, including common-credentials and breach-derived lists.

Hydra

The default tool for HTTP Basic Auth and form-based login brute forcing.

FFUF

Flexible fuzzer, also solid for login brute forcing with response-based filtering.

WPScan

WordPress-specific vulnerability scanner with built-in login brute forcing.
Only run these against targets you’re explicitly authorized to test. Account lockouts, especially against AD-backed logins, can cause real outages, confirm scope and lockout policy before starting.