A customer reports their account was taken over — they didn't log in and their email/password were changed. How do you respond?
Expected Points
- ✓Immediately restore the victim's access: verify their identity out-of-band (secondary email, phone, KYC data), override the attacker's email change, and force-reset the password.3
- ✓Invalidate all active sessions for that account to evict the attacker.2
- ✓Review the account's auth logs: source IPs of the login, email-change, and password-change events. Determine if MFA was bypassed, if it was enabled at all, and whether the login came from a known credential-stuffing IP range.3
- ✓Check for horizontal spread: are other accounts showing similar patterns in the same time window? A cluster of ATOs suggests credential stuffing or a breach, not a targeted attack.3
- ✓If systemic: escalate, block the attacking IP ranges/ASNs, rate-limit login attempts, and consider enforcing MFA or CAPTCHA temporarily.2
- ✓Notify the victim of what happened, what you're doing, and whether any data was accessed by the attacker. Comply with breach notification regulations if applicable.2
- ✓Root cause: evaluate whether the takeover was due to reused/breached passwords (credential stuffing), weak reset flow, session fixation, or a vulnerability. Drive the systemic fix.2
Account takeover (ATO) incidents require immediate containment for the victim, then investigation to determine whether this is isolated or systemic (breach vs. credential stuffing vs. insider access).