Recovering IAM and PAM After Ransomware or Domain Compromise: Rebuild Trust in the Right Order

After ransomware or a domain compromise, the systems you would normally use to recover (the directory, the identity provider, the PAM vault, the sync servers) may be the systems the attacker controls. Restoring servers before you have regained trust in identity simply hands the attacker a clean estate to walk back into. This guide covers the decisions and sequence for recovering the identity control plane: deciding what to trust, recovering or rebuilding the privileged access management (PAM) platform, rotating human and non-human credentials in an order that actually evicts the attacker, and proving the result. It goes beyond the forest recovery steps in the Identity Recovery Guide and is written for incident commanders, IAM and PAM owners, and recovery teams.

Key takeaways

• Assume the identity plane is compromised until proven otherwise: human-operated ransomware usually involves privilege escalation through stolen accounts, so recovery starts with regaining administrative control, not with restoring files.
• Recover from a known-good root of trust: an out-of-band admin path, clean admin workstations and cloud-only emergency accounts that the attacker could not reach.
• The PAM vault is Tier 0 evidence and Tier 0 risk: it may hold every credential the attacker needs, so decide early whether you are restoring it, rebuilding it or treating all its secrets as burned.
• Sequence matters more than speed: resetting user passwords while krbtgt, sync accounts and federation keys are still known to the attacker achieves nothing.
• Non-human credentials are where re-entry hides: service accounts, sync accounts, API keys, app secrets and automation tokens outnumber people and are the usual way back in.

Decide what you can trust

Microsoft's guidance on human-operated ransomware stresses that these attacks require "complete adversary eviction" and that recovery follows regaining full administrative control. Before any restore, the incident commander needs an explicit trust decision for each identity component, recorded in the incident log.

In the Storm-0501 hybrid cloud attacks, operators with Domain Admin extracted Entra Connect Sync credentials, added a rogue federated domain to forge SAML tokens (T1484.002 Trust Modification) and reached Microsoft 365 before deploying ransomware. A recovery that restored the domain but missed the federated domain would have left the attacker a working door.

Establish a clean recovery foothold

1. Out-of-band coordination: CISA's #StopRansomware Guide recommends out-of-band communication such as phone calls so the attacker does not learn they have been detected. Do not coordinate on the compromised tenant's email or chat.
2. Clean admin workstations: freshly imaged devices, not joined to the compromised domain, used only for recovery. CISA advises rebuilding with pre-configured standard images where possible.
3. Emergency cloud access: Microsoft recommends at least two cloud-only emergency access accounts on the *.onmicrosoft.com domain, not federated or synchronised, with phishing-resistant authentication (FIDO2 passkey or certificate-based) and credentials kept in separate physical safes. If these exist and their sign-ins were never seen during the incident, they are your root of trust in the cloud. See the Break-Glass Account Guide.
4. Isolated recovery network: a clean room where restored domain controllers and PAM components can be validated before reconnecting. See the Cloud Recovery and Clean Room Guide.
5. Preserve evidence first: export IdP audit logs, PAM audit logs and sync server images before rebuilding, because retention may be short and the rebuild destroys them.

Recovering the PAM platform

A PAM vault is both the best record of what privileged credentials exist and a complete set of keys for the attacker if it was reached. Three questions decide the path.

• Was the vault itself accessed? Review vault audit records for retrievals, safe membership changes and new administrators during the dwell time. If the audit trail is missing or disabled, assume access.
• Is a pre-compromise backup available and verifiable? NIST CSF 2.0 RC.RP-03 requires verifying the integrity of backups before restoring. A vault restored from a backup taken after the attacker added themselves restores the attacker too.
• Are the recovery keys safe? Vault platforms rely on master, recovery or unseal key material held outside the system. If those were stored on a compromised file share or in the same domain, the vault cannot be trusted even if restored.

For self-hosted HashiCorp Vault, recovery mode (started with the -recovery flag) gives direct storage access when Vault cannot start, issues a single non-persisted recovery token and shrinks an Integrated Storage cluster to one node, so it is a repair tool for a failed node, not a way to clean a compromised one. Whatever the product, recovery keys and break-glass vault administrator credentials must live outside the estate they protect, ideally in physical safes, as with cloud emergency accounts. See the HashiCorp Vault Guide and the PAM Buyer's Guide.

Credential reset sequence

The order below closes the attacker's persistence routes from the most powerful down. Each step assumes the previous one has completed and replicated.

1. Remove attacker objects and trust changes: rogue federated domains, new identity providers, unauthorised Global or super administrators, new service principal credentials, new GPOs and scheduled tasks (T1098 Account Manipulation).
2. Directory root secrets: reset krbtgt twice on writable domain controllers. Microsoft's forest recovery guidance waits 10 hours between resets (the default maximum ticket lifetime) because password history is 2, and says not to delete RODC krbtgt_<number> accounts if RODCs are being recovered. This invalidates forged Golden Tickets (T1558.001).
3. Tier 0 human accounts: Domain and Enterprise Admins, built-in Administrator, cloud Global Administrators and IdP super admins. Prefer new accounts over resetting old ones, and remove standing membership.
4. Hybrid and federation secrets: reset the Entra Connect AD DS connector account (sync fails with Event ID 6000 "credentials were invalid" until the new password is entered in Synchronization Service Manager and the Microsoft Entra ID Sync service restarts); roll the Seamless SSO AZUREADSSO Kerberos key with Update-AzureADSSOForest, once per forest; issue new AD FS token-signing certificates if federation stays.
5. PAM integration and Tier 0 service accounts: vault connector accounts, rotation service accounts, backup service accounts, hypervisor management accounts (ESXi, vCenter) and anything with replication rights.
6. Revoke cloud sessions: Microsoft Graph revokeSignInSessions invalidates a user's refresh tokens and browser session cookies, takes a few minutes to apply and does not cover external users. Do the same in other IdPs and SaaS admin consoles.
7. Application and workload secrets: app registration secrets and certificates, API keys, CI/CD tokens, database passwords and cloud access keys. Use the Leaked Credential Response Playbook pattern per family.
8. Everyone else: CISA's guide places password resets for affected systems after systems are cleaned and rebuilt. Force reset at next sign-in and re-register MFA where registration may have been tampered with.

Rollback: most of these steps cannot be undone (an old krbtgt key should never come back), so roll forward instead: keep a change log of every reset with time, operator and verification result, so a broken service can be fixed by updating its credential rather than restoring the old one.

Where identity fits: non-human identities during recovery

Service accounts with static passwords, scheduled tasks running as domain accounts, and secrets in scripts are the common re-entry route after a "complete" reset. Build the rotation list from three sources and reconcile them: the PAM vault inventory, the directory (accounts with servicePrincipalName set, accounts with passwords that never expire), and cloud app registrations and service principals. Where you have to rebuild a service account anyway, move it to a managed identity or group managed service account so the next recovery has fewer static secrets. Prioritise by blast radius: accounts with replication rights, hypervisor and backup administration, and anything that can write to Tier 0 groups come first, followed by accounts that hold cloud roles through federation or sync. Record which applications broke after each rotation, and test that the old credential is rejected: if it still authenticates, the rotation never took effect. See How to convert AD service accounts to gMSA and the Secrets Rotation Runbook Template.

Small versus large organisations

• Small organisation, single domain and Microsoft 365: rebuilding the domain is often faster than proving it clean. Move to cloud-only identity where possible, use emergency accounts to clean the tenant, and treat any on-premises password vault as exposed.
• Large or multi-forest organisation: forest recovery from backup, staged per forest, with a dedicated identity recovery team separate from server restore teams, and a written order of restoration that puts identity and PAM before business applications. See the Minimum Viable Company and Critical Service Recovery Order Guide.
• Hybrid with federation: consider converting federated domains to cloud authentication during recovery to remove AD FS from the trust chain, if your applications allow it.

Detection and measurement

Watch the rebuilt environment harder than the old one: attackers often try stored credentials within days.

• Alerts: any emergency account sign-in (Microsoft recommends a Severity 0 alert on their object IDs), new federated domains or identity providers, new Tier 0 group members, krbtgt-encrypted tickets with abnormal lifetimes, DCSync from non-DC hosts, vault retrievals outside change windows, sync connector failures (Event ID 6000) after resets.
• Verification: confirm each reset with the system's own last-changed timestamp, not with the ticket status.

Preparing before an incident: a phased plan

1. Phase 1, foundations: cloud-only emergency accounts with FIDO2, offline copies of PAM recovery keys, offline export of the privileged account inventory, and out-of-band contact lists.
2. Phase 2, backups that restore identity: immutable directory and vault backups with documented restore procedures; test a forest restore and a vault restore in isolation at least annually.
3. Phase 3, reduce what must be rotated: remove standing Tier 0 membership, move service accounts to gMSA or workload identity, retire AD FS where possible.
4. Phase 4, rehearse: tabletop the full reset sequence with timings and owners, then run a technical exercise in an isolated lab. NIST SP 800-184 recommends recovery playbooks and testing to make recovery realistic.

Common failure patterns

• Restoring before evicting: servers come back on a directory the attacker still controls, and encryption starts again.
• Resetting krbtgt once, or twice in quick succession: both leave old tickets valid. Follow the two resets with the documented wait.
• Missing the cloud side of a hybrid compromise: rogue federated domains, service principal credentials and cloud admins created from on-premises accounts survive a forest rebuild.
• Keeping vault recovery keys in the domain: a file share or password manager inside the compromised estate makes the vault unrecoverable or untrustworthy.
• Re-enabling identity sync too early: in the MGM Resorts breach, attackers reportedly held administrator rights in the Okta and Azure tenants and MGM shut down its Okta Sync servers. Reconnect sync only after both sides are clean.
• Forgetting the help desk: social engineering of the service desk was the entry route in the MGM case, and recovery creates a flood of reset requests that attackers can exploit. Use the Account Recovery and Help Desk Security Guide controls during recovery.

Framework mapping

ISO/IEC 27001:2022 Annex A controls A.5.26 (response to information security incidents), A.5.29 (information security during disruption) and A.8.13 (information backup) apply, as do CIS Controls v8.1 Control 5 (Account Management), Control 11 (Data Recovery) and Control 17 (Incident Response Management).

Practitioner checklist

• Record an explicit trust decision for AD, cloud IdP, sync servers, federation and PAM before restoring anything.
• Coordinate out of band and use freshly imaged admin workstations outside the compromised domain.
• Use cloud-only emergency accounts with phishing-resistant MFA as the cloud root of trust.
• Remove rogue federated domains, identity providers, admins and service principal credentials first.
• Reset krbtgt twice with the documented wait, then Tier 0 accounts, then sync and federation secrets.
• Decide whether the PAM vault is restored, rebuilt or treated as burned, and rotate accordingly.
• Revoke cloud sessions and refresh tokens after password resets.
• Reconcile service accounts from vault, directory and cloud inventories and rotate every one.
• Keep vault recovery keys and emergency credentials offline, outside the estate they protect.
• Rehearse the full sequence at least annually in an isolated lab.

Standards and references

• CISA: #StopRansomware Guide
• NIST: SP 800-184 Guide for Cybersecurity Event Recovery
• Microsoft Learn: AD Forest Recovery, resetting the krbtgt password
• Microsoft Learn: Human-operated ransomware
• Microsoft Learn: Manage emergency access admin accounts in Microsoft Entra ID
• Microsoft Learn: Microsoft Entra Seamless single sign-on FAQ
• Microsoft Learn: user revokeSignInSessions
• HashiCorp: Vault recovery mode

Related NHI Mgmt Group resources: Identity Recovery Guide · Domain Registrar Compromise Playbook · Ransomware Response and Recovery Guide · Break-Glass Account Guide