Credential Stuffing Attack Response Playbook

A credential stuffing attack is an incident twice over: a flood of automated logins against your service, and a smaller set of customer accounts that the attacker actually opened. Credential stuffing (ATT&CK T1110.004) replays username and password pairs stolen from other sites, so your own systems may be uncompromised while your customers' accounts are not. This playbook template gives [Organisation] a live response for customer-facing login attacks: confirming the attack, slowing the flood without locking out real customers, finding and securing the accounts that were opened, watching for fraud, and deciding whether to notify regulators and customers. It is written for security operations, the customer identity (CIAM) team, fraud operations, customer support and privacy. Prevention and detection engineering are covered in the Password Spraying and Credential Stuffing Defence Guide; this page is the response runbook. Replace every [Organisation] 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.
Run two tracks in parallel. Track A (traffic) slows and blocks the automated login flood. Track B (accounts) finds every account with a successful attacker login and secures it. Teams that only run Track A stop the noise and miss the harm.
Pre-agree thresholds: values in square brackets, such as login failure ratios and rate limits, are illustrative. Set them from your own baseline before an incident, not during one.
Keep decision points explicit. Each "Decision" line names who decides and on what evidence. Record every decision with a timestamp; regulators and courts ask for this record.
Prepare the levers in advance: know how to switch your bot defence to a stricter mode, force a password reset for a list of accounts, revoke customer sessions and send bulk customer messages. If any of these needs a code change, fix that before you need it.

1. Scope and triggers

1.1 This playbook applies to automated login attacks against any [Organisation] customer-facing authentication surface: web login, mobile app login APIs, legacy and partner APIs, password reset and account recovery flows, and any endpoint that reveals whether a username exists.

1.2 Related attacks and the playbook to use:

Pattern	ATT&CK	Distinguishing signal	Use
Credential stuffing	T1110.004 Credential Stuffing	Many usernames, roughly one attempt each, high share of unknown usernames, low but non-zero success rate	This playbook
Password spraying	T1110.003 Password Spraying	Many valid usernames, a few common passwords each	This playbook, Track B weighted to accounts with weak passwords
Session cookie theft (infostealer, adversary in the middle)	T1539 Steal Web Session Cookie	No failed logins; sessions appear from new devices	The Account Takeover Response Playbook
Single high-value account takeover	T1078 Valid Accounts	One account, often after phishing or support social engineering	Account Takeover Response Playbook
Volumetric denial of service on login	Not applicable	Volume with no plausible credential pairs	The DDoS Response Playbook

1.3 Triggers. Any one of these opens a case; two together declare an incident:

Login failure ratio above [3x] the baseline for the hour and day of week, or failed logins for unknown usernames above [x] per minute.
A sharp rise in logins from hosting provider or residential proxy address ranges, or from one connection fingerprint presenting many user agents.
A bot defence or web application firewall rule firing at an unusual rate, or CAPTCHA solve rates that are abnormally high (the OWASP Credential Stuffing Prevention Cheat Sheet notes that high solve rates can indicate automated solving).
Customer contacts about password reset emails they did not request, unknown logins, changed delivery addresses or spent loyalty points or balances.
Fraud signals: a burst of stored payment method use, gift card redemption or address changes on long-dormant accounts.
A third party, researcher or law enforcement agency reporting a combination list containing your customers' email addresses.

2. Roles and contacts

Role	Named lead	Responsibilities
Incident lead	[Name, phone]	Declares the incident, sets severity, owns the decision log and timeline
SOC analyst	[Rota]	Traffic analysis, attacker infrastructure, success list (Track B)
CIAM or authentication engineer	[Name, phone]	Changes login policy, step-up rules, forced resets, session revocation
Edge and bot defence owner	[Name, phone]	Rate limits, bot management mode, WAF rules, CDN configuration
Fraud operations lead	[Name]	Monitors payments, refunds, loyalty and address changes on affected accounts; reverses fraud
Customer support lead	[Name]	Scripts, staffing for contact spikes, identity checks for account recovery
Privacy and legal	[Data protection officer, counsel]	Notification decisions, regulator contact, evidence handling
Communications	[Name]	Customer notices, media statement, website status page
Executive sponsor	[Name]	Approves customer-visible friction and any service restriction

3. Detection and triage

3.1 Confirm automation. Compare the last [24] hours with the same period in previous weeks: total login attempts, failure ratio, share of unknown usernames, distinct source IP addresses, autonomous system numbers and connection fingerprints. Credential stuffing tools distribute requests across large proxy pools, so a per-IP view alone understates the attack; the OWASP cheat sheet recommends correlating traffic with proxy and hosting provider intelligence and considering both burst and long, low-volume patterns.

3.2 Map every surface. Check web, mobile API, partner API, legacy endpoints and password reset separately. Attackers move to the surface with the weakest controls, often an old mobile API version that skips the bot defence.

3.3 Build the success list (Track B starts here). Extract every account with a successful password verification from attacker infrastructure or fingerprints during the attack window, including logins that then failed a second factor. Record for each: first successful attacker login, actions taken in the session, and whether stored value, payment methods or sensitive personal data were reachable.

3.4 Preserve evidence now: raw authentication logs, edge and WAF logs, bot defence verdicts, session issuance logs, account change and transaction logs for the success list. Export them before retention runs out and keep a hash of each export.

3.5 Rate severity.

Severity	Criteria (example, adapt)
Critical	Successful logins with access to payment methods, stored value, health, financial or other special category data, or [over 1,000] accounts opened
High	Successful logins with personal data exposure, or any confirmed fraud
Medium	Attack confirmed, small success list, no evidence of actions in sessions
Low	Attack fully absorbed by existing defences, no successful attacker logins

3.6 Decision (incident lead): declare an incident and severity, or log as an absorbed attack with the metrics that show no successful logins.

4. Containment

Track A: slow and block the flood

4.1 Raise friction where the attack is, not for everyone. Apply challenges or blocks to traffic from hosting ranges, known proxy networks and suspect connection fingerprints first; the OWASP cheat sheet gives the example of requiring every request from a hosting provider to solve a CAPTCHA.

4.2 Rate limit on several keys at once: per IP, per subnet or autonomous system, per connection fingerprint, per device, per username and globally per endpoint. Per-account lockout alone does little against stuffing, because each credential pair is usually tried once. NIST SP 800-63B-4 section 3.2.2 caps consecutive failed attempts per authenticator at 100 and lists bot detection challenges as one way to reduce lockouts of legitimate users.

4.3 Close side doors. Put the same controls on mobile and partner APIs, retire or block deprecated login endpoints, and make login and password reset responses identical for valid and invalid usernames so the attack does not double as username enumeration.

4.4 Keep blocks temporary. The OWASP cheat sheet advises that IP mitigations should be temporary, with a process to release addresses as abuse stops; residential proxies mean today's attacker IP is tomorrow's customer.

Track B: secure the accounts that were opened

4.5 For every account on the success list, in this order:

Revoke sessions and refresh tokens issued since the first attacker login, on web and mobile, so the attacker loses access immediately.
Force a password reset at next login. NIST SP 800-63B-4 section 3.1.1.2 says verifiers shall force a change when there is evidence the authenticator has been compromised. Set the new password check against a blocklist of compromised passwords, as section 3.1.1.2 requires.
Freeze value-moving actions for [72] hours or until the customer re-verifies: payouts, gift cards, loyalty redemption, new payment methods and delivery address changes.
Undo attacker changes: email, phone, address, recovery options, linked devices, API keys or connected apps the attacker added.
Offer or require a second factor or passkey at re-entry. See the Passwordless and Passkeys Guide.

4.6 Decision (incident lead with executive sponsor): extend resets beyond the success list? Choose a wider reset (for example all accounts targeted with a password that matched) when logs are incomplete or a large share of targeted usernames are yours; keep it narrow when logs reliably show which logins succeeded. Wider resets cost support load and customer drop-off; record the reasoning either way.

5. Eradication

5.1 Credential stuffing has no implant to remove; eradication means removing the conditions that let it succeed. Check that every authentication surface now enforces the Track A controls and that no endpoint bypasses the bot defence.

5.2 Check new and reset passwords against a compromised password service. OWASP points to Pwned Passwords as a free option that can be self-hosted. See the Breached password checks guide.

5.3 Review the sessions of the success list for persistence an attacker could reuse: long-lived mobile tokens, connected third-party apps, saved devices marked as trusted, and API keys created in the account.

5.4 Investigate what the attacker did in each session: data viewed or exported, orders placed, messages sent. This feeds fraud reversal and the notification decision.

6. Recovery

6.1 Step down Track A friction in stages, watching the failure ratio and challenge rate after each step. Keep stricter rules on hosting ranges for [14] days, since attackers often return with a new proxy pool.

6.2 Restore customers through a verified recovery path. Support staff must not accept knowledge questions that the attacker may now know from the account; use the registered email or phone confirmed before the attack window, or document checks.

6.3 Reverse fraud: refund or reinstate stored value, cancel fraudulent orders and inform payment partners of affected payment methods.

6.4 Lift value-moving freezes per account once the customer has reset the password and confirmed their contact details.

7. Communication and notification

Audience	Owner	When and what
Affected customers (success list)	Communications with privacy	As soon as Track B containment is done: what happened, that their password was reused from another breach, what was reset, what to do (unique password, enable passkey or MFA, check other sites using the same password)
Data protection regulator	Privacy lead	If personal data was accessed and the breach is notifiable: under GDPR and UK GDPR Article 33, within 72 hours of becoming aware. Account access by an unauthorised party is a personal data breach even though your systems were not hacked
Individuals at high risk	Privacy lead	Article 34 notification where the breach is likely to result in a high risk, for example when payment, health or genetic data was reachable
US state regulators and individuals	Counsel	Per state breach notification law; see the Breach Notification Laws by Country Guide
Payment partners and card schemes	Fraud lead	When stored payment methods were used or exposed, per contract
Support staff	Support lead	Before customer notices go out: script, escalation route, identity checks

7.1 Do not tell customers "we were not breached" as the main message. Regulators have treated weak login protection as a security failure of the service; on 17 June 2025 the UK Information Commissioner's Office fined 23andMe £2.31 million after a 2023 credential stuffing attack, citing the lack of mandatory MFA, weak monitoring and a slow response, including an August 2023 data theft claim dismissed as a hoax. See the 23andMe Breach 2023 analysis. Use the Customer Breach Notification Letter Template for wording.

8. Post-incident review

8.1 Within [10] working days, record the timeline: attack start, first successful attacker login, detection, Track A containment, Track B completion and notification.

8.2 Root cause questions: which surface had the weakest control, how long the attack ran before detection, whether MFA or passkeys were offered and how many customers used them, whether compromised password checks were in place at sign-up and reset, and whether support could recover accounts safely under load.

8.3 Metrics to track from this and later incidents:

Time to detect: attack start to case opened.
Attacker success rate: successful attacker logins divided by attempts, before and after containment.
Time to secure: first successful attacker login to session revocation for that account (median and worst case).
Fraud loss per incident and share reversed.
Customer impact: legitimate login challenge rate and failed legitimate logins during containment.
Phishing-resistant or MFA coverage of active customer accounts.

Implementation guidance

Instrument first. The OWASP cheat sheet recommends that every defence produce detected and mitigated volume metrics; without per-surface login dashboards you cannot run section 3. See the Bot Management Guide and the Rate Limiting and API Abuse Guide.
Script Track B. A tested job that takes a list of account IDs and revokes sessions, forces a reset and sets a value freeze turns hours into minutes.
Notify on risky events. OWASP suggests telling the user when a login used the correct password but failed the second factor, so they can change it.
Exercise it twice a year with a simulated success list and a support surge. Include the fraud and privacy teams.
Reduce the prize: passkeys, step-up authentication for value-moving actions, and compromised password checks at sign-up shrink what a stuffing attack can win. See the Customer IAM (CIAM) Guide.

Playbook step	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Detection and triage	DE.CM-03, RS.MA-02	SI-4 System Monitoring
Track A login throttling	PR.AA-03	AC-7 Unsuccessful Logon Attempts
Track B forced resets	PR.AA-01, RS.MI-01	IA-5 Authenticator Management
Incident handling and reporting	RS.MI-02, RS.CO-02	IR-4 Incident Handling, IR-6 Incident Reporting

Credential Stuffing Attack Response Playbook: Contain Login Floods and Protect Customer Accounts