When an attacker holds a valid password, session token or cloud key, disabling one account rarely ends the incident: refresh tokens keep working, service principals carry new secrets, and the same credential sits in three other systems. This template is a ready-to-adopt identity incident response playbook for compromised accounts: triage, severity, containment for workforce users, compromised service accounts and cloud identities, a persistence sweep, evidence collection and recovery, each with an owner and a target time. It follows NIST SP 800-61 Rev. 3 and uses Microsoft Entra ID, Active Directory, AWS and Google Cloud as worked examples. It is for security operations, IAM and cloud teams who need a runbook the on-call responder can follow at 3am. Replace the bracketed values and approve it under your incident response plan.
How to use this template
- Replace text in square brackets, such as [Organisation], [SOC lead] and [30 minutes], with your own teams, tools and targets. Target times run from incident declaration.
- "Must" is mandatory; "should" is recommended and may be skipped with a recorded reason.
- This playbook sits under your [Incident Response Plan], which sets overall severity, escalation and notification rules. See the Incident Response Plan Template.
- The detection side of identity attacks, and how identity threat detection and response fits your tooling, is covered in the ITDR Guide. This page is the runbook for when an alert has become an incident.
- Commands and log names are examples for named platforms. Map each step to your own identity provider, directory, cloud and SaaS estate before you need it.
1. Purpose
This playbook sets out how [Organisation] triages, contains, eradicates and recovers from identity incidents: any event in which an attacker has obtained, or may have obtained, the ability to act as one of our identities. Its aims are to cut off every access path the attacker holds (passwords, sessions, refresh tokens, keys, certificates and delegated grants), find and remove persistence, preserve evidence and restore service without letting the attacker collect the new credentials. It implements [Incident Response Plan] section [X] and supports NIST SP 800-53 IR-4 (Incident Handling) and AC-2 (Account Management).
2. Scope
- Workforce identities: employee, contractor, guest and administrator accounts in [Entra ID / Active Directory / other identity provider], including their MFA methods, registered devices and sessions.
- Non-human identities: service accounts, managed service accounts, service principals and app registrations, cloud IAM users, roles and service accounts, Kubernetes service accounts, API keys, OAuth clients and tokens, SSH keys, certificates and AI agents.
- Cloud identity incidents: misuse of identities in [AWS organisation], [Google Cloud organisation] and [Azure tenant], including federated and cross-account access.
- Out of scope: leaked secrets found before any evidence of use follow the Leaked Credential Response Playbook; phishing intake follows the Phishing Incident Response Playbook. Both hand over to this playbook once attacker use is suspected.
MITRE ATT&CK files this behaviour as T1078 Valid Accounts, with sub-techniques T1078.001 Default Accounts, T1078.002 Domain Accounts, T1078.003 Local Accounts and T1078.004 Cloud Accounts. Persistence after the first sign-in usually takes the form of T1098 Account Manipulation, for example T1098.001 Additional Cloud Credentials, T1098.003 Additional Cloud Roles and T1098.005 Device Registration.
3. Roles and responsibilities
| Role | Responsibilities in an identity incident |
|---|---|
| [SOC analyst] | First responder. Validates the alert, runs triage (section 5), opens the record, executes pre-approved containment |
| [Incident manager] | Declares the incident, sets severity, approves disruptive containment, keeps the decision log |
| [Identity lead] (IAM team) | Runs sections 6 and 8: disables accounts, revokes sessions, resets credentials and MFA, sweeps for persistence. Protects Tier 0 (domain controllers, identity provider, federation, sync servers) |
| [Cloud lead] | Runs section 7 for cloud keys, roles and service accounts; reviews cloud audit logs across all accounts, projects and regions |
| [Service owner] / [NHI owner] | Confirms what a compromised service account or app does, approves rotation windows, tests the service after rotation |
| [Service desk lead] | Holds identity-verified resets for affected users; blocks phone and chat resets for named accounts during the incident |
| [Legal] and [DPO] | Assess personal data exposure and notification duties under the [Incident Response Plan] |
4. Triggers and severity
Typical triggers include: an identity provider risk detection or confirmed compromised user; impossible travel or sign-ins from anonymising infrastructure; MFA method or device registration followed by sensitive activity; a new credential added to a service principal; a new tenant-wide OAuth consent; cloud API calls from an access key at an unfamiliar network; a service account logging on interactively; a user report or service desk call; or a provider notification (for example, an exposed key alert from [cloud provider]).
| Severity | Criteria (any one) | Example | Contain within |
|---|---|---|---|
| SEV1 Critical | Tier 0 or Global Administrator, root or organisation admin compromised; federation or token signing material exposed; attacker-created admin accounts; production service principal with directory-wide permissions abused | New federation trust added; attacker grants itself a cloud administrator role | [30 minutes] |
| SEV2 High | Confirmed attacker use of a privileged user, a production service account or a cloud key; tenant-wide consent to an unknown app; several users compromised | Cloud access key calling IAM APIs from an unknown network; password spray with successful sign-ins | [1 hour] |
| SEV3 Medium | One standard user confirmed compromised, no privileged access, no evidence of lateral movement or data access | Password entered on a phishing page, sign-in blocked by Conditional Access | [4 hours] |
| SEV4 Low | Attempted compromise with no successful authentication | Spray from one IP address, all attempts failed | [1 business day] |
Rate on what you know and assume the worst for privileged and non-human identities: a compromised service account often has standing access to many systems and no MFA to slow the attacker.
5. Identity incident triage
| Step | Action | Owner | Target |
|---|---|---|---|
| T1 | Confirm the identity: account type (user, admin, service account, service principal, cloud key, agent), owner, privileges and the systems it can reach. Use the [NHI inventory] for non-human identities. | [SOC analyst] | [15 min] |
| T2 | Establish where authentication happens. Microsoft's password spray playbook notes that for federated domains successful sign-ins are in Entra ID but failed sign-ins are in the identity provider (for AD FS, event IDs 411, 342 and 516 for failures and lockout, 412 for success). | [SOC analyst] | [15 min] |
| T3 | Pull sign-in history for [30 days]: source IPs and networks, devices, user agents, client apps (legacy protocols), MFA results and Conditional Access results. Prioritise successful, then interrupted, then failed sign-ins from known attacker IPs. | [SOC analyst] | [30 min] |
| T4 | Pull change history: MFA method and device registrations, password resets (and who requested them), role and group changes, new app credentials, consents and mailbox rules. | [Identity lead] | [30 min] |
| T5 | For cloud identities, pull API activity for the principal in every account or project and region (section 7). | [Cloud lead] | [45 min] |
| T6 | Decide: confirmed compromise, suspected, or benign. Set severity (section 4), declare, and record the time of awareness in UTC. | [Incident manager] | [1 hour] |
A help desk reset that precedes suspicious activity is itself a trigger: in the Storm-2949 Azure attack, a fake IT support reset turned one Entra ID account into a cloud-wide data theft. See the Account Recovery and Help Desk Security Guide.
6. Containment: compromised user accounts
Containment must cover four things for every user in scope: the account, its credentials, its live sessions and tokens, and anything the attacker registered. Disabling the account alone is not enough. Microsoft states that after the account is disabled and sessions revoked "the user can't gain new tokens", but existing access tokens last 1 hour by default unless the app supports Continuous Access Evaluation, and Entra ID "can't directly revoke a session token issued by an application".
| Step | Action (Entra ID and AD examples) | Owner | Target |
|---|---|---|---|
| C1 | Disable the cloud account (Update-MgUser -AccountEnabled:$false) and mark it compromised in Microsoft Entra ID Protection. | [Identity lead] | [15 min] |
| C2 | Revoke refresh tokens and sessions (Revoke-MgUserSignInSession, or Revoke sessions in the admin centre) and disable the user's registered devices. | [Identity lead] | [15 min] |
| C3 | Hybrid accounts: Disable-ADAccount, then reset the password twice. Microsoft recommends two resets "to mitigate the risk of pass-the-hash, especially if there are delays in on-premises password replication". | [Identity lead] | [30 min] |
| C4 | Remove MFA methods, passkeys and devices registered during the suspected window; require re-registration through an identity-verified process. | [Identity lead] | [30 min] |
| C5 | Terminate sessions in SaaS applications that issue their own session tokens (for example [CRM], [code repository], [ticketing]), and revoke personal access tokens the user created. | [Application owners] | [1 hour] |
| C6 | Block attacker source IPs at the identity provider or Conditional Access, accepting that attackers rotate infrastructure. Block legacy authentication if it was used. | [Identity lead] | [1 hour] |
| C7 | Privileged accounts: rotate from a clean privileged access workstation and escalate to [CISO] for any Tier 0 involvement (sync server, federation, token signing). | [Identity lead] | [30 min] |
For token and session behaviour across protocols, see the Token and Session Security Guide.
7. Containment: compromised service account and cloud identity
Non-human identities cannot be "logged out" and often cannot be disabled without an outage. The [Incident manager] decides between immediate disablement and staged rotation, and records the business impact. Microsoft's compromised application playbook makes the same point: weigh "the security impact and the business impact of disabling an application" before acting.
| Identity type | Contain | Rotate and verify | Logs to review |
|---|---|---|---|
| AD service account | Restrict logon to known hosts (LogonWorkstations); deny interactive logon; disable if the service can stop | Reset password twice; update every consumer; alert on failed logons with the old password | Security log 4624 (logon type), 4625, 4769 for its SPN |
| Entra service principal or app | Disable the service principal (accountEnabled = false). Disable rather than delete a malicious app: Microsoft notes a disabled app "can't obtain new tokens" | Add the new credential, then remove every old one (removePassword, removeKey) on both application and service principal objects; rotate Key Vault secrets it could read | Service principal sign-ins; audit "Certificates and secrets management" updates on the application, "Add app role assignment to service principal", "Consent to application" |
| AWS IAM user access key | Deactivate the key (AWS advises "Don't delete the original access key during this step"); confirm the AWSCompromisedKeyQuarantineV2 policy if AWS attached it | Issue a replacement or, better, move the workload to a role; delete the old key once consumers work | CloudTrail by access key ID across all regions; credential report |
| AWS IAM role | Revoke active sessions, which attaches the AWSRevokeOlderSessions deny policy using aws:TokenIssueTime; fix the trust policy that let the attacker assume it | Review who and what can assume the role; remove unknown principals | CloudTrail AssumeRole events and the sessions they created |
| Google Cloud service account | Disable the account or apply an IAM deny policy; revoke Service Account Token Creator from unexpected principals | Create and deploy a new key, disable then delete the old one; prefer attached accounts or federation over keys | Cloud Audit Logs for the principal, including serviceAccountDelegationInfo for impersonation |
| Kubernetes service account | Remove RoleBindings and ClusterRoleBindings; delete legacy token Secrets | Redeploy workloads to obtain new bound tokens | API server audit log for the service account username |
| API keys, OAuth clients, PATs, SSH keys | Revoke at the issuer | Reissue through [secrets manager]; search code, CI variables and logs for copies | Issuer audit logs; source IP of use |
| AI agent | Suspend the agent; revoke its credentials and delegated grants | Re-register with a fresh identity after review | Agent action logs and tool calls |
Two cloud facts change the order of work. Google Cloud states that service account access tokens "are bearer tokens and remain valid until their expiration time", so disabling the account (and waiting at least 60 minutes before re-enabling it) is what stops them. AWS role session revocation does not touch long-term IAM user keys, and cannot be used on service-linked roles. The Dropbox Sign breach shows the stakes: a compromised back-end service account exposed API keys, OAuth tokens and MFA secrets.
8. Persistence sweep and eradication
CISA's federal playbooks warn that "Threat actors often have multiple persistent backdoor accesses into systems and networks". Rotate after removing persistence, or the attacker collects the new secret. The identity lead must check, for the incident window plus [7 days] before first known activity:
- New or modified MFA methods, passkeys, authenticator apps and registered devices (T1098.005).
- New credentials on applications and service principals, and new federated identity credentials (T1098.001).
- New role assignments and group memberships in the directory and every cloud (T1098.003, T1098.007), and new Kubernetes cluster role bindings (T1098.006).
- OAuth consents, especially tenant-wide grants (ConsentType AllPrincipals) and high-risk scopes such as
Mail.*,Files.*,Directory.AccessAsUser.All,Application.ReadWrite.AllandRoleManagement.ReadWrite.Directory. - Mailbox forwarding rules, inbox rules and delegate permissions (T1098.002).
- New federation trusts, custom domains, identity provider configuration and Conditional Access exclusions.
- New IAM users, access keys, roles and trust policy changes in AWS; new service account keys, user accounts and project-level SSH keys in Google Cloud; resources in regions you do not use.
- Personal access tokens, deploy keys and CI/CD secrets created by the compromised identity.
The Midnight Blizzard breach combined password spraying of a legacy test tenant account with abuse of an OAuth application, which is why steps 2 and 4 are mandatory even when the first alert is a simple sign-in. Then close the entry point: enforce MFA, block legacy authentication, fix the reset process, remove the exposed secret from code.
9. Evidence collection
| Source | Export | Note |
|---|---|---|
| Identity provider | Sign-in logs (interactive, non-interactive, service principal, managed identity), audit logs, risk detections | Export before retention expires; extend retention for the incident |
| Active Directory | Domain controller security logs (4624, 4625, 4720, 4728, 4738, 4769), AD FS logs | Collect from every domain controller, not only the authenticating one |
| AWS | CloudTrail for all accounts and regions, IAM credential report, access last-used data | Use the organisation trail if one exists |
| Google Cloud | Admin Activity and Data Access audit logs | Data Access logs need the Private Logs Viewer role |
| SaaS and email | Unified audit log, mailbox rules, OAuth grants, app audit trails | Record consent grant timestamps |
| Endpoints | Memory and disk image of devices used by the compromised identity | CISA: "capture a memory and disk image for evidence preservation" |
Hash exported files, record who collected them and when (UTC), and store them in [evidence store]. See the Digital Forensics (DFIR) Guide.
10. Recovery and return to service
- Re-enable users only through verified identity: in person or by video with [ID check], new password, fresh phishing-resistant MFA registration, and a new device trust where needed.
- Bring services back in dependency order: rotate, deploy, test with the [service owner], then remove the old credential. Confirm no consumer still presents it.
- Replace rather than restore where you can: move compromised long-lived keys to managed identities, roles or federation.
- Restore removed access deliberately: privileged roles come back through the normal request and approval path, not by undoing the incident changes.
- Watch for re-entry: alert on any use of revoked credentials, the attacker's infrastructure and the identities in scope for [30 days].
Declare the incident closed when the [Incident manager] confirms: all in-scope credentials are revoked or rotated, the persistence sweep is complete, the entry point is closed and monitoring is in place. Incomplete rotation is a classic failure: in the Cloudflare Thanksgiving breach, four credentials left unrotated after an earlier Okta compromise let a nation-state attacker in.
11. Post-incident review and metrics
Hold a blameless review within [10 business days] for SEV1 and SEV2. Track these measures across incidents:
- Time to revoke: declaration to last session or token revoked for the identity in scope (target [1 hour] for SEV1).
- Rotation completeness: credentials rotated divided by credentials in scope (target 100% before closure).
- Persistence found: number of attacker-added credentials, grants or roles found by the sweep, and how many were found only after closure.
- Owner reach time: time to reach the owner of a compromised non-human identity.
- Re-compromise rate: incidents reopened within 90 days for the same identity.
See the Identity Security Metrics Guide.
12. Framework mapping
| Playbook section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ATT&CK |
|---|---|---|---|
| 4 and 5 Triage and severity | DE.AE, RS.MA, RS.AN | IR-4, IR-5 | T1078 |
| 6 and 7 Containment | RS.MI | IR-4, AC-2, IA-5 | T1078.002, T1078.004 |
| 8 Persistence sweep | RS.MI | AC-2, AC-6, CM-3 | T1098 and sub-techniques |
| 9 Evidence | RS.AN | AU-6, AU-9, IR-4 | |
| 10 Recovery | RC.RP | IR-4, CP-10 | |
| 11 Review | ID.IM | IR-4, IR-8 |
Implementation guidance
- Pre-approve containment: agree which actions the [SOC analyst] may take alone (revoke sessions for a standard user, deactivate a cloud key with no production consumers) and which need the [Incident manager] (disabling a production service principal).
- Script the first hour: build tested automation for C1 to C3 and the cloud key and role steps. Run it in a test tenant and account first, then on a sacrificial account in production. Keep manual steps documented as the fallback.
- Know your owners before the incident: section 7 depends on knowing what each service account and app does. If your non-human identity inventory has gaps, close them first. See the Service Account Security Guide.
- Exercise: rehearse one user compromise, one service principal compromise and one cloud key compromise each [year], time each step and update the targets. See the Tabletop Exercise Guide.
- Roll back safely: if a rotation breaks production, re-enable the old credential only with the [Incident manager]'s approval, for a fixed window, with monitoring on its use, while the consumer is fixed.
Small and large organisations: a small team can merge the identity and cloud lead roles and rely on a retainer for forensics, but should still pre-approve containment and keep a written owner list for every service account. A large or multi-cloud organisation should split the playbook into platform runbooks owned by each team and drive them from a SOAR platform, keeping this document as the single source for severity, sequencing and closure criteria.
Common failure patterns
- Disable without revoke: the account is disabled but refresh tokens, app sessions and personal access tokens keep working.
- Rotate before evicting: new secrets are deployed while the attacker still has a foothold to read them.
- Deleting the malicious app: deletion loses evidence and, per Microsoft, a deleted app can return if another user consents again. Disable it first.
- Single-region cloud review: AWS advises checking resources "in all AWS Regions, even in Regions that you didn't launch resources".
- Trusting the reset channel: the attacker calls the service desk again and is given a new password.
Standards and references
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
- MITRE ATT&CK: T1078 Valid Accounts
- Microsoft Learn: Revoke user access in Microsoft Entra ID
- Microsoft Learn: Compromised and malicious applications investigation
- Microsoft Learn: App consent grant investigation
- AWS: Revoke IAM role temporary security credentials
- Google Cloud: Handle compromised Google Cloud credentials
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: ITDR Guide · Incident Response Plan Template · Leaked Credential Response Playbook · Cloud Incident Response Guide · Token and Session Security Guide