After a major breach, "reset everything" is the right instinct and the wrong plan: done in the wrong order it hands the attacker the new passwords, breaks production overnight and floods the help desk with calls that attackers can join. A mass reset has to be sequenced so that the identities which control other identities are reset first, non-human credentials are rotated alongside people, and every session and token is cut, not just the password. This playbook covers when a mass reset is justified, the triage questions that decide its scope, the order of waves from Tier 0 to everyday users and SaaS, help desk capacity and verification, staff communications, evidence and notification. It is written for incident commanders, identity and Active Directory engineers, service desk leads and communications staff. Investigating and evicting the attacker from Active Directory is covered in the Active Directory Domain Compromise Response Playbook, and the krbtgt procedure in detail in the krbtgt account guide; this page is about sequencing the whole reset.
Key takeaways
- Contain before you reset. If the attacker still holds administrative access or can read new hashes from a domain controller, every reset is wasted; reset after access is cut, or as part of the same coordinated move.
- Reset in waves, top down. Emergency and Tier 0 accounts first, then privileged service accounts and machine credentials, then all users, then SaaS and third party accounts.
- A password reset is not a session reset. Revoke refresh tokens and sessions too; in Microsoft Entra ID, access tokens issued before the reset stay valid for about an hour unless the app supports continuous access evaluation.
- Non-human credentials cause the reinfection. Service accounts, API keys and integration tokens that are "believed unused" and skipped are how attackers come back.
- The help desk is now an attack surface. A reset wave produces exactly the urgent calls that social engineers imitate, so tighten caller verification before the first announcement.
How the incident shows up
A mass reset is a response decision, not an alert. It is triggered by evidence that credentials were exposed at scale or that an attacker could have harvested them.
| Trigger | Evidence | Typical scope |
|---|---|---|
| Domain compromise | DCSync activity (ATT&CK T1003.006), NTDS.dit copied, domain admin used from unknown hosts | Every AD account including krbtgt, service and computer accounts |
| Forged Kerberos tickets | Golden Ticket indicators (T1558.001), tickets with abnormal lifetimes | krbtgt double reset plus Tier 0 |
| Identity provider tenant compromise | New federation settings, rogue admins, MFA method changes | All cloud admins, app secrets, federated trust, then users |
| Password store or vault exposure | PAM vault, password manager or secrets store breached | Every secret held in that store |
| Credential dump in the wild | Corporate credentials in an infostealer log or leak site | Named users plus any shared or service credentials found |
| Upstream supplier breach | A provider says credentials or tokens you issued it were exposed | All credentials issued to that provider |
The attacker behaviour behind these triggers is usually T1078.002 Domain Accounts or T1078.004 Cloud Accounts for access, and T1098 Account Manipulation for persistence. The reset only works if it removes both the stolen secrets and the persistence the attacker built with them.
Triage questions
- Is the attacker still in? If eviction is not complete, coordinate the reset with containment so it happens in one window, rather than days before the attacker loses access.
- Which credential stores were exposed? AD database, Entra ID or another identity provider, a vault, local SAM databases, browser stores, configuration files or CI/CD variables. Each store defines a scope.
- Were hashes or tickets taken, or only some passwords? Hash or krbtgt exposure means every account in the domain is in scope, not just those seen in logs.
- Is MFA trustworthy? If the attacker could register or reset MFA methods, plan MFA re-registration as well as password changes.
- Which non-human identities depend on these credentials? List service accounts, scheduled tasks, application pools, integration users, API keys and certificates, with an owner for each.
- What breaks if we reset? Identify applications with hard-coded credentials, devices that cache passwords and systems that cannot easily take a new secret.
- Can we communicate safely? If email or chat may be monitored, set up the channels in the Out-of-Band Communications for Incident Response Guide first.
- Can the help desk cope? Estimate call volume, staff hours and self-service coverage before setting the timetable.
Containment priorities
Reset in waves. Finish and verify each wave before starting the next, because a later wave depends on the identities reset in the earlier one.
| Wave | Accounts and credentials | Key actions | Check before moving on |
|---|---|---|---|
| 0. Prepare | Incident team identities, out-of-band channels, clean admin workstations | Issue new credentials to responders from clean devices; freeze non-essential changes | Responders can work without the suspect environment |
| 1. Tier 0 and emergency access | Break-glass accounts, Domain and Enterprise Admins, built-in Administrator, Directory Services Restore Mode passwords, identity provider global admins, PAM and vault administrators | Reset, review membership, remove unknown admins and MFA methods, first krbtgt reset | Admin group membership matches an approved list |
| 2. Privileged non-human identities | Service accounts with admin rights, sync and federation accounts, application secrets and certificates, cloud access keys, CI/CD secrets, SSH keys | Rotate with owners present; move to managed identities or gMSA where possible | Dependent services start and authenticate with the new secret |
| 3. Second krbtgt reset | krbtgt in every affected domain | Reset again after more than the maximum ticket lifetime (10 hours by default) | Replication healthy; no Kerberos failures beyond expected |
| 4. All users | Every human account in scope | Force change at next sign-in, revoke sessions and refresh tokens, require MFA re-registration if MFA was exposed | Reset completion rate tracked daily |
| 5. Everything else | Remaining service accounts, computer accounts, local administrator passwords, SaaS accounts not behind single sign-on, shared and vendor accounts, API keys issued to partners | Rotate by owner and system, including local admin passwords via LAPS where deployed | Inventory shows every in-scope credential rotated or disabled |
Why the order matters
- Tier 0 first: resetting users while an attacker holds a domain admin password lets them read or reset the new user passwords too.
- krbtgt twice, with a wait: Microsoft's forest recovery guidance says to reset krbtgt twice and wait 10 hours between resets, because the account keeps a password history of two; if ticket lifetime policies are longer than the default, wait longer than the configured value.
- Disable before reset for suspect accounts: for accounts the attacker controlled, Microsoft's revoke access guidance is to disable the account, reset the password twice in AD to mitigate pass-the-hash, and revoke Entra sessions with
Revoke-MgUserSignInSession. - Sessions and tokens: revoking refresh tokens stops new tokens, but Entra access tokens last about an hour and application session cookies are enforced by each application. Plan for a short tail and use continuous access evaluation where apps support it.
Eradication
Eradication makes sure the reset removed the attacker's options, not just their known passwords.
- Remove persistence tied to identities: unknown admin accounts, added MFA methods, new application credentials, delegated permissions, federation trusts and mailbox rules. A reset leaves all of these working.
- Rotate secrets with owners, not around them: for each service account or key, have the system owner update the dependent application in the same change window, then test. See the Leaked Credential Response Playbook for per-type rotation, the Azure Entra Client Secrets Security Guide for app registrations, and the SSH Key Compromise Response Playbook for keys.
- Do not skip "unused" credentials: if nobody can show it is unused, rotate or disable it. Disabling is a quick test: anything that breaks has just identified its owner.
- Replace rather than reset where possible: convert eligible AD service accounts to group managed service accounts, which rotate their own passwords (see the Group Managed Service Accounts (gMSA) Guide), and replace long-lived cloud keys with workload identity federation.
- Apply current password rules: NIST SP 800-63B Revision 4 says verifiers shall not require periodic password changes but shall force a change when there is evidence of compromise, and new passwords shall be checked against a blocklist of commonly used, expected or compromised values. Use the reset to switch on blocklist checking if it is not already enforced.
Recovery
Help desk capacity and verification
- Self-service first: push users to self-service password reset where it exists, with MFA, so agents handle only exceptions.
- Stronger verification, not weaker: during a reset wave agents are under pressure to "just reset it". Require a verification method that public information cannot pass, such as a manager call-back or in-person check for privileged users. The Help Desk Identity Verification Policy Template gives a policy you can apply immediately.
- Staffing: plan extended hours for the first 48 hours, scripts for the common questions and a fast path to identity engineers for service account breakages.
- Alert on abuse: monitor for MFA method resets, password resets by help desk agents for privileged accounts and sign-ins from new locations right after reset.
Staff communications
- Announce through a trusted channel: a message from a known executive, intranet banner or manager briefing, not only email if email is suspect.
- Say what will happen, when, and what staff must do, in a few short lines.
- State plainly that IT will never ask for a password and that reset links will only come from a named portal; attackers send fake reset notices during real ones.
- Tell staff to change the same password anywhere else they reused it, including personal accounts.
- Give a support route and expected wait times, and update daily.
Return to normal
Track completion by wave, disable accounts that have not reset by the deadline, and keep heightened monitoring of authentication logs for at least the period the attacker was present. Lift change freezes only after the inventory shows every in-scope credential rotated or disabled.
Evidence to preserve
| Evidence | Source | Why it matters |
|---|---|---|
| Copy of AD and identity provider state before reset | Admin group membership exports, AD replication metadata, Entra audit logs | Shows attacker changes that a reset could overwrite |
| Authentication logs | Domain controller security logs, identity provider sign-in logs, VPN and SaaS logs | Scopes which accounts were used and when |
| Credential inventory with rotation record | Reset tracker by wave, owner and time | Proves completeness to auditors, insurers and regulators |
| Help desk records | Ticketing system, call recordings where lawful | Detects social engineering during the reset |
| Communications sent | Copies of staff and customer messages with timestamps | Evidence of timely, accurate notice |
Export logs before mass changes; a reset generates a large volume of events that can push older records out of short retention windows.
Notification triggers
A mass reset is not itself a notifiable event, but the breach behind it often is, and the reset is part of what you report as mitigation.
- Personal data regulators: under UK GDPR and EU GDPR Article 33, a personal data breach likely to result in a risk to individuals is notified to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. Credentials are personal data, and directory exposure usually includes names, emails and other attributes.
- Individuals: Article 34 requires telling individuals without undue delay where the risk is high. Where customer passwords were exposed, a forced reset plus a clear notice is usually expected, along with advice to change reused passwords elsewhere.
- Other regimes: sector, contract, insurance and listed-company rules may apply. Use the Data Breach Notification Checklist and the Breach Notification Laws by Country Guide.
- Suppliers and partners: tell partners when credentials they hold for you, or that you hold for them, are rotated, so integrations are updated and they can check their own logs.
Lessons from incidents
- Unrotated service credentials: in the Cloudflare Thanksgiving Breach 2023, one service token and three service accounts exposed in the October 2023 Okta breach were not rotated because they were believed to be unused. An attacker used them in November 2023, and Cloudflare's remediation then rotated more than 5,000 production credentials. The lesson is to include every non-human credential in the reset inventory and prove disuse before skipping one.
- Help desk impersonation: the MGM Resorts Breach 2023 page records the attackers' own account, not confirmed by MGM, that they identified an employee online and called the IT help desk posing as them. During a mass reset those calls are expected and harder to spot, so verification must get stricter, not looser.
Framework mapping
| Activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ATT&CK addressed |
|---|---|---|---|
| Inventory and manage all credentials, human and machine | PR.AA-01 | IA-5 Authenticator Management, IA-4 Identifier Management | T1078.002, T1078.004 |
| Review and remove privileged access | PR.AA-05 | AC-2 Account Management | T1098 |
| Execute coordinated response | RS.MA-01 | IR-4 Incident Handling | T1003.006, T1558.001 |
| Revoke sessions and tokens | PR.AA-01 | IA-5 | T1550.001 Application Access Token |
| Communicate recovery to staff | RC.CO-03 | IR-4 | None |
Common failure patterns
- Resetting users before admins. The attacker watches the new passwords arrive.
- One krbtgt reset, or two in quick succession. Forged tickets survive or legitimate authentication breaks across the domain.
- Passwords changed, sessions left alive. Refresh tokens, application sessions and API tokens keep the attacker signed in.
- Service accounts left for later. Later never comes, and a privileged account with an old password stays usable.
- Announcing by email from a compromised tenant. The attacker reads the plan and phishing follows the real notice.
- Loosening help desk checks to clear the queue. Volume pressure becomes the attacker's way back in.
Practitioner checklist
- Keep a current inventory of Tier 0 accounts, emergency accounts and privileged service accounts with named owners.
- Pre-write the reset wave plan, staff announcement and help desk scripts, and store them outside the production environment.
- Confirm krbtgt reset tooling and the ticket lifetime values for each domain before you need them.
- Include session and refresh token revocation in every reset step, and know which applications support continuous access evaluation.
- Map each service account and API key to the systems that use it so rotation can happen with the owner present.
- Enforce compromised password blocklist checks on all new passwords.
- Tighten help desk verification for the duration of the reset and alert on MFA and privileged resets.
- Track completion by wave and disable accounts that miss the deadline.
Standards and references
- Microsoft Learn: AD Forest Recovery, Resetting the krbtgt password
- Microsoft Learn: Revoke user access in Microsoft Entra ID
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- CISA: CISA Releases Open Source Eviction Strategies Tool for Cyber Incident Response
- legislation.gov.uk: UK GDPR Article 33, Notification of a personal data breach
- legislation.gov.uk: UK GDPR Article 34, Communication of a personal data breach to the data subject
Related NHI Mgmt Group resources: Identity Incident Response Playbook, Identity Provider Tenant Compromise Playbook, Break-Glass Account Guide, Help Desk Social Engineering Incident Playbook.