DisasterLab
PlaybooksCustomer accounts under credential-stuffing attack
Accesscritical45 minutes to prepare

Customer accounts under credential-stuffing attack

Automated attackers are testing stolen username and password pairs against customer accounts.

01DetectConfirm the signal
02ContainStop more damage
03RecoverRestore control
04VerifyProve it works

What do you need right now?

Prepare before it happensRecover from this now

Your preparation

0 of 0 safeguards ready
0%
Continue the prevention checklist
Incident worksheet

Make the next decision with evidence

Reduce successful account takeover without locking out legitimate customers, then identify which accounts and downstream actions were affected.

EvidenceDecisionActionProof

Capture before evidence disappears

  • Preserve authentication attempts with account ID, normalized IP, ASN, device signal, user agent, outcome, MFA result, session ID, and reset activity.
  • Separate attempted accounts, successful logins, new sessions, password changes, MFA changes, exports, purchases, and profile or payout changes.
  • Record rate-limit, WAF, bot, CAPTCHA, and identity-provider decisions so you can see which control failed or was bypassed.
  • Capture customer reports and known breached-credential alerts without collecting plaintext passwords.

Decisions that change the response

QuestionAct whenAction
Block traffic or challenge it?Requests share reliable abusive signals and false positives are measurable.Rate-limit or block the cluster; challenge uncertain traffic and monitor legitimate failure rates.
Reset passwords?An account had a confirmed hostile login, sensitive action, or password reuse is strongly indicated.Revoke sessions and require a reset for affected accounts; avoid a global reset without evidence.
Notify customers?An attacker accessed an account or performed actions, even if your own systems were not breached.Tell affected users what happened, what changed, and which actions they should review.

Proof that recovery worked

  • Attack success drops while legitimate login and recovery completion remain within an agreed range.
  • Every confirmed account has hostile sessions revoked, risky changes reversed, and an owner-visible event history.
  • Replayed stolen credentials cannot bypass the new rate, bot, MFA, or risk controls.
  • Support can distinguish takeover recovery from ordinary password-reset requests.

Controls to put in place

  • Check passwords against a privacy-preserving breached-password service at creation and reset.
  • Offer passkeys or strong MFA, and require step-up verification for exports, payout, email, and security changes.
  • Rate-limit by account and network while detecting distributed low-and-slow attempts.
  • Notify customers of new devices and high-risk changes with a direct session-revocation path.
Tabletop drill

Replay a controlled set of invalid logins against test accounts from several networks. Measure detection, customer friction, session revocation, support recovery, and whether one successful login triggers the correct response.

Escalate when

Bring in the identity provider and security specialists when success continues despite controls, privileged accounts are affected, automation is highly distributed, or account access exposed personal or financial data.

What this means

Valid customer passwords reused from other breaches may be succeeding at scale. The incident can expose customer data or allow purchases, withdrawals, and account changes.

Warning signs

  • Login volume, failures, or password resets jump suddenly.
  • Many accounts are accessed from shared IP ranges or unusual devices.
  • Customers report changes or transactions they did not make.
  • Support receives many lockout or takeover reports.

Recover now

First 15 minutes

  1. Preserve authentication logs and establish the attack window.
  2. Rate-limit or challenge suspicious traffic. Avoid blocking every customer by country or network without evidence.
  3. Suspend risky actions for affected sessions. Require reauthentication for payments, exports, and profile changes.
  4. Revoke sessions for confirmed accounts and notify their owners through a trusted channel.

Today

  1. Identify successful logins, not only failed attempts.
  2. Force password resets only for accounts in scope and invalidate their sessions.
  3. Check whether customer data or money was accessed.
  4. Add breached-password checks, bot controls, MFA, and unusual-login alerts.

Verify recovery

  • Attack volume is controlled without excessive legitimate lockouts.
  • Confirmed compromised sessions and tokens no longer work.
  • Affected customers have recovered accounts.
  • High-risk actions require fresh authentication.

Prepare now

Access

  • Administrators and high-risk customers can use MFA or passkeys.
  • Passwords are checked against known breached-password datasets.

Backups and evidence

  • Authentication, session, and high-risk action logs have useful retention.

Contacts and ownership

  • Support has an account-takeover verification script and escalation owner.

Practice

  • A test account can have every session revoked within minutes.

Common mistakes

  • Counting only failed logins. The dangerous attempts may succeed.
  • Resetting passwords without revoking sessions.
  • Using CAPTCHA as the only control. Automated attacks adapt.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.