Password Spraying: Detection and Response Guide

Model the attack across identities, services, and time

Password spraying detection finds a small password set tested against many accounts. The attacker may throttle attempts below lockout thresholds, distribute them across proxies, rotate services, or wait a day between attempts. Per-user failure alerts alone miss this shape.

MITRE ATT&CK T1110.003 notes targeting of SSO, mail, SSH, SMB, databases, and management services. Build one identity view across cloud and on-premises authentication, including Windows authentication evidence, rather than treating each protocol as an unrelated event.

Normalize every authentication outcome before correlating

Capture event and ingestion time, normalized account and tenant, source IP and infrastructure label, service, protocol, client application, device, location, user agent, result, failure reason, password-validation outcome when available, MFA requirement and result, conditional-access decision, and session ID.

Preserve raw provider codes. “Failed” can mean unknown user, wrong password, correct password but failed MFA, blocked legacy authentication, or policy denial. Microsoft’s Entra risk signal can indicate successful password validation without successful resource access; do not collapse those states.

Run fast, slow, distributed, and success-followed-by-failure analytics

Aggregate distinct accounts per source and source cluster, then distinct sources per targeted account population. Add sliding windows for bursts and multi-day low-and-slow behavior. Correlate similar user agents, ASN, geolocation, protocol, failure code, and account ordering when IPs rotate.

Prioritize any correct-password signal, successful sign-in, MFA prompt, or session creation after the failures. Join MFA fatigue attack detection. Exclude documented health checks and migration tools by identity, owner, service, and expiry—not source IP alone.

Separate targeted accounts from actually exposed credentials

Preserve authentication and risk evidence, block or challenge active infrastructure where useful, and identify four populations: unknown-user probes, failed-password targets, correct-password-but-blocked identities, and successful sessions. The latter two require immediate credential and session response.

Reset exposed passwords through a trusted channel, revoke identity tokens and sessions, require strong MFA, investigate mailbox and data access, and hunt the same source cluster across services. Blocking one IP is temporary containment, not eradication.

Remove weak passwords and reduce exposed authentication paths

Block known weak and organization-themed passwords, require phishing-resistant MFA for privileged and remote access, disable legacy authentication, constrain external services, use risk-based access policies, and monitor dormant or service identities. Lockout policy alone can create denial of service and does not stop slow distributed attempts.

Exercise correlation with synthetic identities

Next step: create disposable test identities and send one authorized invalid attempt across them through a test authentication path. Verify normalization, breadth correlation, suppression, escalation on a simulated successful validation, and evidence handoff. Never spray production users or test real passwords.