Account takeover spike

Detection signals

• Successful logins from new devices, impossible-travel geographies, or new ASNs
• Bursts of email/password/MFA changes shortly after login
• Spike in support tickets about locked-out accounts or unrecognized activity
• Fraudulent transactions or payout changes clustered in time

Likely root causes

• Credential stuffing or phishing that harvested valid credentials
• Weak or bypassable MFA, or SIM-swap against SMS OTP
• Session or token theft (see the token-theft playbook)

Containment

1. 1Invalidate active sessions and refresh tokens for affected accounts
2. 2Require step-up MFA and re-verification for sensitive changes (email, password, payout)
3. 3Temporarily lock accounts showing confirmed takeover
4. 4Freeze money movement / high-risk actions pending verification

Customer communication

• Contact affected users through a verified channel, not just the compromised email
• Walk them through secure re-verification and re-enrollment of MFA
• Be specific about what changed on the account and what you have reversed

Forensics & logging

• Timeline each account: login, device, IP, and every subsequent change
• Preserve logs before any bulk remediation
• Identify the common entry vector across affected accounts

Post-incident hardening

• Move off SMS OTP toward passkeys / phishing-resistant MFA
• Add continuous risk scoring and step-up on sensitive actions
• Harden account recovery against social engineering

FAQ

What's the first containment step for an ATO spike?

Invalidate active sessions and refresh tokens for affected accounts and require step-up re-verification for sensitive changes (email, password, payout). Then lock confirmed-takeover accounts and freeze money movement.

How do I contact users if their email may be compromised?

Use a verified secondary channel, not just the account email, which the attacker may control. Walk users through secure re-verification and MFA re-enrollment.