How can security teams detect dictionary-based password attacks?

How dictionary attacks show up in authentication data

Dictionary-based password attacks usually stand out less by a single failed login and more by a pattern. The useful signal is repeated authentication failure against one or many accounts, where the attempted passwords look like common words, breached passwords, or trivial variants. Teams should treat this as an authentication abuse pattern, not just routine user error, because the attacker is testing large password sets efficiently.

Good detection starts with baselining normal failure rates by portal, user population, geography and time of day. A sudden rise in failed logins against the same exposed login path, especially when attempts cluster across many usernames, is often more meaningful than a spike against one account. Low-and-slow attacks can be harder to see, so long observation windows and per-user aggregation matter as much as real-time alerts.

Correlation improves the signal. Joining identity logs with source IP, device fingerprint, user agent, timestamp and account target helps distinguish a person mistyping a password from a distributed campaign. If the same source or small source set cycles through a large account list, or if many sources hit the same few accounts, that often indicates automation rather than ordinary friction. For a practical control baseline, Password Security and Password Manager Guide is useful because it covers breached-password blocking and credential attack patterns that often underpin these events.

Signals that matter more than raw failure counts

Raw login failures alone are too noisy. Better signals include repeated attempts that share the same password family, bursts of failures followed by short pauses, unusual geography for the target population, and timing that does not match real human retry behaviour. A dictionary attack often produces a steady cadence, while legitimate mistakes usually cluster around a single account, a single user, or a short burst immediately after a password change or session expiry.

Teams should also watch for “fan-out” and “fan-in” patterns. Fan-out is one source trying many accounts with the same word or variation. Fan-in is many sources trying one account or a small set of accounts, which can indicate distributed infrastructure, proxy use, or a campaign trying to avoid rate limits. Either pattern becomes more suspicious when the failures come from authentication portals exposed to the internet, especially if the target is a high-value application or privileged user population.

Attackers also reuse known password lists, so successful detection often depends on recognising structure in the guess set. Username-plus-common-word combinations, seasonal variants, predictable substitutions and simple number suffixes are all signs that the attempt stream is derived from a dictionary rather than generated ad hoc. That is why event enrichment and sequence analysis are more useful than a basic threshold on failed logins.

What to tune in your detection and response workflow

The most effective detections usually combine identity telemetry with rate, geography and repetition logic. Alerting should key off repeated failures across multiple accounts, repeated failures from a narrow source set, and unusual concentrations on a single application or tenant. Teams that rely only on lockout thresholds often miss low-and-slow activity and may also create avoidable user disruption.

Response should be aligned to the pattern, not just the count. If the activity appears distributed and systematic, treat it as attempted credential abuse and look for follow-on signs such as successful logins from the same sources, MFA prompts that correlate with the failures, or account enumeration behaviour. CISA cyber threat advisories are a useful external reference point for current attack patterns and defensive priorities, especially when attacks shift toward credential-based access paths.

Detections are strongest when they feed into throttling, step-up authentication, IP reputation checks and temporary challenge controls. But teams should be careful not to overfit on one pattern, because attackers change cadence, source distribution and wordlists to avoid simple heuristics. The goal is to detect systematic guessing early enough to prevent successful compromise, then confirm whether any account was actually taken over.

Practitioner Guidance

What to prioritise: Tune detections around repeated failures across many accounts, not just single-account lockout noise. The highest-value alert is usually the one that combines failure repetition, shared source characteristics and an exposed authentication surface.

What to verify: Confirm whether your logs preserve enough context to correlate source, user, device and time. Without that joinable data, dictionary attacks often look like generic authentication noise and are much harder to separate from user mistakes.

Decision rule: If the same pattern shows up across many accounts or from a narrow set of sources, treat it as active password guessing and escalate for containment review, even if no account has yet succeeded. If the pattern is isolated to one user and one short window, start with user-behaviour validation before broadening the response.

Practitioner takeaway: Effective detection is less about counting failures and more about recognising repeatable guessing behaviour, source concentration and cross-account patterns before an attacker finds a valid password.

Related resources from NHI Mgmt Group

• How should security teams detect browser-based copy-paste attacks before they execute locally?
• How should security teams detect identity-based attacks that move through email and login paths?
• What should security teams monitor to detect trust-based email attacks earlier?
• How should security teams detect and respond to browser-based identity attacks before attackers turn stolen credentials into account takeover?