Containing account takeover the right way
Resetting the password is not enough — attackers persist through sessions, tokens, app passwords, and MFA methods. The full containment playbook for a compromised credential.
The core lesson
Revoke sessions, don't just reset the password. A password reset alone leaves the attacker's active session tokens, refresh tokens, app passwords, OAuth grants, mail rules, and rogue MFA methods fully working. Containment means invalidating every form of persistent access, then hunting for what the attacker set up while inside.
The most common incident-response mistake with a compromised account is to reset the password, breathe out, and move on. Modern authentication issues long-lived session and refresh tokens that survive a password change, and an attacker who was inside has usually planted persistence. Effective containment addresses every path back in.
Contain: cut every path of access
- **Reset the password** — necessary, but only the first step.
- **Revoke all active sessions and refresh/access tokens** — this is the step that actually logs the attacker out. Without it, existing tokens keep working after the reset.
- **Review and reset MFA methods** — attackers add their own phone/authenticator/security key so they can re-authenticate. Remove any factor you didn't expect and re-enroll the user cleanly.
- **Revoke app passwords and OAuth/third-party grants** — legacy app passwords and consented apps are tokens that ignore the new password and often ignore MFA.
- **Disable the account** outright if compromise is severe or ongoing, buying time to investigate.
- **Rotate any secrets the account could access** — API keys, shared credentials, keys in reach of that identity.
"We reset the password" is not containment
If you only reset the password, the attacker's existing session token, refresh token, app password, or added MFA method still works — they never had to log in again. Session/token revocation is the non-negotiable step. Verify it actually happened in the identity provider.
Hunt: find what they did and left behind
Assume the attacker acted during their access. Look for persistence and lateral movement before declaring the incident closed.
- **Mailbox rules and forwarding** — a classic BEC persistence trick: auto-forward or hide-and-delete rules that exfiltrate mail or conceal replies. Remove them and check for external forwarding.
- **Delegate/mailbox permissions and added recovery info** — attacker-added alternate email/phone for future resets.
- **New OAuth app consents and service-principal credentials** — app-based persistence that survives user remediation.
- **Sent items, sharing activity, and downloads** — scope what was accessed or exfiltrated for breach-notification decisions.
- **Lateral movement** — did the identity access other systems, or send internal phishing? Check sign-in logs across resources.
Recover and learn
- Restore the user to clean access: verified identity, fresh strong password, re-enrolled phishing-resistant MFA.
- **Notify** per policy and legal/regulatory obligations if data was exposed.
- **Determine root cause** — phished credential, reused password from a breach, malware, helpdesk social engineering — and close that gap (e.g. push phishing-resistant MFA, harden helpdesk verification).
- Feed detections back into monitoring so the next instance is caught faster.
Pre-build the one-click containment
During an active takeover you don't want to assemble these steps by hand. Prepare a runbook or automation that, given an account, resets the password, revokes all sessions/tokens, strips unrecognized MFA methods and app passwords, revokes risky OAuth grants, and pulls a report of mail rules and recent activity — in one action.
Post-incident evidence
Record: time from detection to session/token revocation (not just password reset), MFA methods and app passwords found and removed, mail rules / OAuth grants remediated, scope of data accessed, root cause, and the preventive change made. Confirm no residual valid tokens remain for the account.