Resetting a password does not end an account takeover: the attacker's sessions, refresh tokens, registered MFA methods and any persistence they created all survive it. Account takeover (ATO) is the use of a legitimate account by someone who is not its owner, whether a workforce user whose password was sprayed or phished, or a service account whose secret leaked. This playbook template gives [Organisation] a response that removes every form of attacker access in the right order, with named roles, decision points and evidence to keep. It covers workforce and service accounts in identity providers such as Microsoft Entra ID and Okta and in SaaS platforms; customer account takeover follows the same logic but is run by the fraud team. Replace every [Organisation] placeholder before use. For prevention, see the Account Takeover Prevention Guide.
How to use this template
- Adopt it as a sub-playbook of [Organisation]'s incident response plan and SOC runbooks. See the Incident Response Plan Template and the SOC Guide.
- Use the two tracks. Steps marked U apply to human user accounts, steps marked S to service accounts and other non-human identities. Many incidents need both: an attacker in a user account often reaches the tokens and keys that user manages.
- Fill in the identity platform specifics: admin roles, the exact console paths and scripts for session revocation, and who can act out of hours.
- Keep decision points explicit. Each "Decision" line names who decides and on what evidence.
- Drill it. Run the revocation steps against a test user and a test service account every quarter and time them.
1. Scope and triggers
1.1 This playbook applies to any [Organisation] identity (workforce user, administrator, contractor, service account, workload identity, API key or OAuth application) where there is evidence that someone other than the owner or the intended workload is using it.
1.2 Common entry routes and the techniques to record in the case:
| Entry route | ATT&CK | What it means for response |
|---|---|---|
| Password spraying or credential stuffing | T1110.003 Password Spraying | Often many accounts at once; check every account that saw a success |
| Phished or infostealer-stolen password used to sign in | T1078 Valid Accounts, T1078.004 Cloud Accounts | Treat the user's device as compromised too |
| Stolen session cookie (adversary in the middle, infostealer) | T1539 Steal Web Session Cookie | MFA was satisfied; a password reset alone does nothing |
| MFA push fatigue | T1621 Multi-Factor Authentication Request Generation | Move the user to phishing-resistant MFA |
| Stolen API key or OAuth token for a service or app | T1550.001 Application Access Token | Revoke and rotate the credential; follow the S track |
| Help desk social engineering of an MFA or password reset | T1078 Valid Accounts | The recovery process itself is the weakness |
1.3 Triggers: an identity protection risk detection such as "Anomalous token" or "Attacker in the Middle" in Entra ID Protection; impossible travel or a new country; a new MFA method registered and used within minutes; a user reporting an MFA prompt they did not start; a service account signing in interactively or from a new network; a leaked credential report; a third party reporting activity from an [Organisation] account.
1.4 Related playbooks: leaked secrets with no evidence of use follow the Leaked Credential Response Playbook; cloud access keys used in IaaS follow the Cloud Credential Compromise Playbook; mailboxes used for payment fraud follow the Business Email Compromise Response Playbook.
2. Roles and contacts
| Role | Named lead | Responsibilities |
|---|---|---|
| Incident lead | [Name, phone] | Declares the incident, sets severity, owns the timeline and decision log |
| SOC analyst | [Rota] | Triage, log collection, scoping across other accounts |
| Identity administrator (Privileged Authentication Administrator or equivalent) | [Name, phone] | Disables accounts, revokes sessions, resets MFA, reviews identity provider changes |
| Service or application owner | [From service account inventory] | Rotates service credentials, restores dependent workloads, confirms normal behaviour |
| Endpoint team | [Name] | Isolates and investigates the user's device for infostealers or session theft |
| Help desk lead | [Name] | Verifies the user's identity through an out-of-band route before MFA re-registration |
| Legal and privacy | [Name] | Notification decisions if data was accessed |
2.1 Every service account needs a named owner before an incident. Without one, step S tasks stall. See the Service Account Inventory Template.
3. Detection and triage
3.1 Confirm with the owner. (U) Contact the user through a known phone number, not the possibly compromised email or chat. (S) Ask the service owner whether the source IP, user agent and actions match the workload.
3.2 Collect the first evidence set: sign-in logs for the account for at least [30] days, audit logs of changes the account made, MFA registration history, OAuth consents and app grants, and token issuance logs. Export them now in case retention runs out.
3.3 Scope the blast radius. Check what the account can reach: admin roles, group memberships, applications, secrets in vaults it can read, and service accounts or API keys it manages.
3.4 Look for the attacker's changes (persistence):
- New MFA methods or devices: T1556.006 Multi-Factor Authentication and T1098.005 Device Registration.
- New accounts or role assignments: T1136.003 Cloud Account and T1098 Account Manipulation.
- Mail forwarding and inbox rules: T1114.003 Email Forwarding Rule.
- New credentials on apps or service principals, OAuth consents and personal access tokens.
3.5 Rate severity. Critical: privileged or admin account, identity provider admin, or a service account with production or data platform access. High: user with access to sensitive data, or evidence of data access. Medium: standard user, no sign of data access or persistence.
3.6 Decision (incident lead): confirm takeover and contain now, or dismiss the risk with recorded evidence. Dismissal requires the owner's confirmation and no unexplained activity.
4. Containment
4.1 Order matters. Block first, revoke second, reset third. Resetting a password while the attacker still holds a refresh token or a registered MFA method leaves them in.
| Step | User account (U) | Service account or NHI (S) |
|---|---|---|
| 1. Block | Disable the account (Entra ID: clear Account enabled; Okta: suspend the user) | Disable the account or deactivate the key, after the owner confirms impact on the workload |
| 2. Revoke | Revoke sessions and refresh tokens (Entra ID: Revoke sessions or Revoke-MgUserSignInSession); disable registered devices | Revoke tokens, OAuth grants and any certificates or secrets on the app registration |
| 3. Reset | Reset password; on hybrid Active Directory, reset twice | Issue a new credential through the vault with minimum scope |
| 4. Re-secure factors | Remove all MFA methods not verified with the user; re-register with phishing-resistant MFA | Replace static secrets with workload identity or short-lived credentials where possible |
| 5. Isolate source | Isolate the user's device if session theft or infostealer is suspected | Check the host or pipeline where the secret lived |
4.2 Token lifetime. Microsoft documents that access tokens stay valid for about an hour after refresh tokens are revoked, and that application session cookies are issued by the application, so Entra ID cannot revoke them directly. Use continuous access evaluation where supported, and revoke sessions inside critical SaaS applications as well. See the Token and Session Security Guide.
4.3 Decision (incident lead and service owner): disable or rotate in place. Disabling a production service account stops the attacker and the business at once. Choose disable when there is evidence of active misuse; choose an immediate rotation with tight monitoring when the outage cost is higher and the evidence shows only exposure.
4.4 Other accounts. If the entry route was spraying or stuffing, reset every account that recorded a successful sign-in from the attacker's infrastructure. See the Password Spraying and Credential Stuffing Defence Guide.
5. Eradication
5.1 Remove every persistence item found in 3.4: rogue MFA methods, devices, inbox rules, OAuth consents, new users, role assignments and credentials on applications.
5.2 Rotate any secret the account could read, such as vault entries, CI/CD variables or keys in shared documents. The Cloudflare breach followed credentials left unrotated after an earlier identity provider incident.
5.3 Clean the user's device or rebuild it if an infostealer is confirmed. Every password and session cookie on that browser is exposed, including personal ones the user should change. See the Infostealer Threat Guide.
5.4 Investigate what the attacker did: files and mail read, data exported, applications accessed. This determines notification.
6. Recovery
6.1 (U) Re-enable the account only after the help desk has verified the user out of band and the user has enrolled phishing-resistant MFA. Use a temporary access pass or a supervised enrolment rather than email links. See the Account Recovery and Help Desk Security Guide.
6.2 (S) Restore the workload with its new credential and confirm it authenticates from expected networks only. Add network restrictions or Conditional Access for workload identities where your platform supports them.
6.3 Monitor the account closely for [14] days: alerts on new MFA registration, new device, new location and failed sign-ins.
6.4 Remove the account from any temporary exclusions created during the incident.
7. Communication and notification
| Audience | Owner | When |
|---|---|---|
| Account owner and line manager | Incident lead | At containment, with instructions for re-enrolment |
| Executive sponsor | Incident lead | For Critical and High severity, at declaration |
| Data protection regulator | Privacy lead | If personal data was accessed and the breach is notifiable; 72 hours under GDPR Article 33 |
| Customers or partners | Legal and account owners | If their data or systems were reached, or contracts require it |
| Staff | Security awareness | If a campaign targeted many accounts, warn others of the lure |
8. Post-incident review
8.1 Within [10] working days, record the timeline: first malicious sign-in, detection, containment, and full eradication.
8.2 Root cause questions: Was MFA in place and phishing-resistant? Was the account covered by risk-based Conditional Access? Did a service account use a password where a key pair or federation was possible? The Snowflake breach combined infostealer passwords, no MFA, no rotation and no network allow lists.
8.3 Track: mean time to revoke sessions after detection, percentage of accounts with phishing-resistant MFA, percentage of service accounts with an owner and no static password, and repeat takeovers of the same account.
Implementation guidance
- Script the containment steps for each identity platform and store them with the playbook. Automate them in SOAR with human approval for admin and production service accounts. See the ITDR Guide.
- Use risk-based remediation. In Entra ID Protection, user risk policies can require a secure password change after MFA; mark confirmed cases as "Confirm compromised" so the signal feeds the risk engine, and use "Dismiss" only after investigation.
- Size by organisation. A small organisation can keep one runbook for its identity provider and its two or three critical SaaS platforms. A large organisation needs per-platform runbooks, an identity on-call rota and a service account inventory linked to owners.
- Fix the recovery path. Many takeovers succeed through the help desk; require verified identity before any MFA reset.
| Playbook section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| 3. Detection and triage | RS.AN-03 | AU-6, IR-4 | A.5.25 |
| 4. and 5. Containment and eradication | RS.MA-01 | IR-4, AC-2, AC-2(3) | A.5.26, A.5.17 |
| Evidence handling | RS.AN-06 | IR-4 | A.5.28 |
| 6. Recovery | RC.RP-01 | IR-4 | A.5.26 |
| 7. Communication | RS.CO-02 | IR-6 | A.5.26 |
| 8. Review | RS.AN-03 | IR-4 | A.5.27 |
References: NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management · Microsoft: Revoke user access in an emergency in Microsoft Entra ID · Microsoft: Remediate risks and unblock users in Entra ID Protection · MITRE ATT&CK: T1078 Valid Accounts · MITRE ATT&CK: T1539 Steal Web Session Cookie
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Account Takeover Prevention Guide · Identity Incident Response Playbook · Service Account Security Guide · Phishing-Resistant MFA Guide · Incident Response Guide