Password Spraying Attack Response Playbook: Detection, Lockouts and Hardening

A password spray is a campaign against the whole directory, not an attack on one account, so the response has to answer a question per-account playbooks never ask: of the thousands of accounts that were tried, which ones did the attacker actually get into? This playbook template gives [Organisation] the run sheet for that answer, from the first alert through the sweep for successful sign-ins, containment of the accounts that fell, handling of lockout storms, communications and the hardening that closes the gap. It is written for SOC analysts, identity engineers and incident managers, with Microsoft Entra ID and AD FS as the worked examples because Microsoft publishes a detailed spray investigation playbook; the same steps apply to other identity providers and to VPN and SSH login points. The attack patterns, detection signals and preventive controls are explained in the Password Spraying and Credential Stuffing Defence Guide; this page is what the team does when a spray is under way. Replace every [placeholder] before use.

How to use this template

• Adopt it as a sub-playbook of [Organisation]'s incident response plan. See the Incident Response Plan Template.
• Hand off single accounts. Once the sweep in section 4 identifies a compromised account, run the Account Takeover Response Playbook for it. This playbook manages the campaign; that one cleans each account.
• Fill in platform specifics: where successful and failed sign-ins are logged for each login point, who can block an IP range at each layer, and who can approve a forced password reset for a population.
• Keep the decision lines. Each "Decision" names who decides and on what evidence. Record the decision and the time in the incident ticket.
• Defensive use only. Do not run spray tests against production to "reproduce" an incident without written authorisation; use the evidence already in the logs.

1. Scope and triggers

This playbook applies when one account or a few accounts are tried with many passwords (handled as brute force under the same steps) or, more typically, when many accounts are tried with a few common passwords (ATT&CK T1110.003 Password Spraying). It covers workforce identity providers, federation services, VPN and remote access gateways, and internet-facing SSH. Customer login stuffing is handled by [Fraud team] under its own runbook. See Credential Stuffing vs Password Spraying for the distinction.

Use [Organisation]'s severity matrix to set the final level; see the Incident Severity Classification Matrix Template. Any confirmed successful sign-in from an attacker source raises the incident to [High] at minimum.

2. Roles and contacts

3. Detection and triage (first hour)

1. Confirm it is a spray. Look for the low and slow signs Microsoft lists in its password spray investigation playbook: failures in address book order, a repeated user agent, target application or IP block, and regular timing between attempts. A single user mistyping does not look like this.
2. Find out where sign-ins are logged. For each targeted domain, record whether authentication is managed (cloud, password hash sync or pass-through) or federated. Microsoft's playbook notes that for federated domains successful sign-ins appear in Entra ID while failures stay with the identity provider (AD FS), so a sweep of one log alone misses half the picture.
3. Build the indicator list. Start time, source IPs and ranges, ASNs, user agents, target applications and client apps (legacy protocols in particular). Mark it version 1 and update it as the sweep finds more.
4. Preserve evidence now (see section 9). Sign-in log retention may be short on lower licence tiers, and AD FS logs roll over.
5. Check whether lockouts are hurting users. If the help desk is seeing a lockout surge, open section 5.3 in parallel: the spray may be causing a denial of service even if no account has fallen.

Decision (SOC lead, within [60] minutes): spray confirmed or not; incident severity; whether to start temporary source blocks (section 5.1) before the sweep completes.

4. Sweep for successful sign-ins

This is the step that decides the size of the incident. Query every login point for the indicator list over the window from [first attempt minus 7 days] to now, then sort accounts into the priority order Microsoft's playbook uses.

Run these sweep checks for every priority 1 and 2 account:

• Legacy protocols: filter sign-ins on client app. Successful IMAP, POP or SMTP AUTH sign-ins bypass MFA and are a direct compromise even if the account is MFA registered. See the Legacy Authentication and ROPC Retirement Guide.
• Short sessions: Microsoft notes that a sign-in and sign-out within the same second can indicate an attacker testing a guessed password.
• MFA events: look for unexpected MFA prompts, approvals at odd hours and new authentication methods registered after the first attempt.
• Non-human accounts: service accounts, shared mailboxes and other accounts excluded from MFA are the most likely to fall to a spray. Treat any success on them as priority 1. See How to find shared mailboxes and service mailboxes with sign in enabled.
• Persistence and impact: mailbox forwarding and inbox rules, added mailbox delegates, OAuth consents, file access and any admin role use since the first success. See How to Investigate a Compromised Entra ID Account.

Decision (incident manager): number of compromised accounts; whether any privileged or non-human account is among them, which raises severity and pulls in [Tenant compromise] procedures.

5. Containment

5.1 Reduce the attack in progress

1. Block sources at the right layer. For cloud authentication, a named location with a Conditional Access block policy; for federated authentication, AD FS banned IPs (Set-AdfsProperties -AddBannedIps) or the firewall in front of AD FS; for VPN and SSH, the edge device. Microsoft cautions that attackers change IPs, so blocks buy time but are not containment on their own.
2. Block legacy authentication through Conditional Access if it is not already blocked. Run the policy in Report-only for the shortest time the business can accept, then switch On; record the exceptions that remain. See the Conditional Access Guide.
3. Require MFA for any targeted population that does not have it, starting with administrators.

5.2 Contain compromised accounts

1. Reset the password and, where the user cannot be reached safely, block sign-in until a verified reset can be done.
2. Revoke sessions. In Entra ID, revokeSignInSessions invalidates refresh tokens and browser session cookies. Microsoft notes there may be a delay of a few minutes, so record the time and verify. See How to Revoke All Sessions for a Compromised User.
3. Mark the user compromised in the identity protection tool so risk policies apply. See Microsoft Entra ID Protection.
4. Remove MFA methods registered after the first attacker sign-in, after confirming with the user.
5. Service accounts: rotate the credential, update every consumer in the same change, and confirm the old secret is rejected. Where the account has no business need to sign in interactively, block that path. See the Service Account Security Guide.

5.3 Lockout storms

A spray against an on-premises directory can lock out large numbers of real users, which is a denial of service in its own right. Do not respond by setting the lockout threshold to zero during an attack.

• Find the path. Lockouts through AD FS or a VPN mean the spray is reaching Active Directory; extranet lockout settings at the federation layer should trip before the domain threshold does.
• Unlock in bulk only after the source is blocked, otherwise accounts lock again within minutes.
• Protect break-glass and service accounts by confirming they are not reachable from the sprayed login point.

Threshold ordering between cloud smart lockout, AD FS extranet lockout and the domain policy is set out in the Account Lockout and Brute-Force Protection Guide.

Decision (identity engineer with incident manager): whether to force a password reset for the whole targeted population. Choose a population reset when the sprayed password is known and widely used, when priority 2 counts are high, or when the logs do not cover the full window. Otherwise reset priority 1 and 2 accounts and add the sprayed passwords to the banned list.

6. Eradication

• Remove persistence found in the sweep: inbox rules, forwarding, delegates, OAuth grants, new devices and app passwords.
• Ban the sprayed passwords in the custom banned password list for the cloud directory and on-premises AD, and confirm that the policy applies to both.
• Close the entry point: the legacy protocol, MFA exclusion or exposed login page the attacker relied on.
• Re-run the sweep with the final indicator list over the full window, because sources found late often reveal earlier successes.

7. Recovery and hardening

Keep the attacker indicators tagged in the SIEM and identity protection tools with an alert on any future activity. For federated estates, see the AD FS Security Guide.

8. Communication and notification

• Targeted users (priority 3): short message that their account was tried, no action needed beyond reporting unexpected MFA prompts. Never include links to reset pages in the message.
• Compromised users (priority 1 and 2): contacted by a known channel, reset verified by the service desk, told what was accessed if known.
• All staff, if a population reset is forced: what happens, when, how to get help, and a reminder that IT will not ask for passwords.
• Regulators: if a compromised account gave access to personal data, the DPO decides on notification. Under UK GDPR the ICO states that a notifiable breach must be reported without undue delay and not later than 72 hours after becoming aware of it, that individuals must be told directly where the risk to them is high, and that all breaches must be recorded whether reported or not. Other jurisdictions differ; see the Breach Notification Laws by Country Guide.
• Third parties: customers, partners and law enforcement as required by contract or as decided by legal.

9. Evidence to preserve

Hash exported files and record who exported them. Event ID detail is in the Windows Event Log Guide.

10. Post-incident review

• Timeline: first attempt, first detection, first success, containment complete. The gap between first attempt and first detection is the headline lesson.
• Metrics to report: accounts targeted, priority 1 and 2 counts, time from detection to last compromised account contained, number of successes through legacy protocols or MFA-excluded accounts, and lockout tickets raised.
• Control review: which hardening item in section 7 would have stopped the attack, with an owner and date for each.
• Framework references: ATT&CK T1110.003 and T1078.004; NIST SP 800-53 AC-7 and IA-5; NIST CSF 2.0 DE.AE-02 and RS.MI-01.
• Case study: the Microsoft Midnight Blizzard breach began with a spray against a legacy test tenant account that had no MFA, which is why non-production and excluded accounts belong in the sweep.

Implementation guidance

1. Prepare the queries before the incident. Save the sweep searches for each login point with the indicator list as a parameter, so section 4 runs in minutes.
2. Raise logging now. Verbose AD FS auditing, sign-in log export with retention beyond [90] days, and domain controller Kerberos and credential validation auditing.
3. Agree pre-approved changes: Conditional Access source blocks, legacy authentication block and bulk session revocation, so the identity engineer does not wait for a change board during an attack.
4. Exercise it. Run a tabletop twice a year using a past incident's logs; time the sweep and the population reset decision.
5. Review the template after each use and record the version in the incident ticket.

Standards and references

• Microsoft Learn: Password spray investigation
• Microsoft Learn: user revokeSignInSessions
• MITRE ATT&CK: T1110.003 Password Spraying
• ICO: Personal data breaches, a guide

Related NHI Mgmt Group resources: Password Spraying and Credential Stuffing Defence Guide · Account Takeover Response Playbook · Account Lockout and Brute-Force Protection Guide · Storm-0940 Password Spray Botnet Profile Guide