Playbook: Responding to a Compromised Privileged Account

A privileged account can change the rules it is judged by. It can add administrators, register applications, alter conditional access, change federation and read secrets. An attacker who holds one has usually used it, or will, to build a second way back in. Response therefore has two jobs: remove the attacker’s hold on the account, and remove everything the account was used to create.

This playbook sets out that sequence for a cloud or hybrid environment. It assumes a Microsoft Entra ID tenant, on-premises Active Directory and a security team that can act on both. The principles hold for other identity providers, but the commands and log names will differ.

Before you act: set the first hour

Step 1. Contain the account

Do these together, not one after another. Each closes a different door.

1. Disable the account. In a hybrid setup, disable it in Active Directory so synchronization does not undo the change.

2. Reset the password, twice if compromise is not ruled out. Microsoft’s guidance for hybrid environments recommends two resets with random values to reduce pass-the-hash risk when on-premises replication is delayed.

3. Revoke refresh tokens and sign-in sessions. In Entra ID this stops the user from obtaining new tokens. Access tokens already issued can keep working for about an hour by default, and application session cookies may last longer, because the application has to end its own session. Continuous Access Evaluation can cut the delay for supported apps.

4. Review and remove authentication methods and devices. Attackers who hold a password often register their own second factor or device to keep access. MITRE tracks these as Multi-Factor Authentication (T1556.006) and Device Registration (T1098.005). Remove any method or device you cannot tie to the owner, and disable the account’s registered devices.

5. Pull the account out of privileged groups and eligible roles, so that a missed step does not leave elevation available.

For app sessions, look at each critical application the account could reach. If the application keeps its own session, ask its owner to terminate it, or rely on provisioning to disable the user there. Microsoft notes that provisioning runs on a cycle, so the delay can be tens of minutes.

Step 2. Find what the account did

Pull every action taken by the account, and every action taken from its sessions, from the earliest time you believe it was compromised. Start at the first anomalous sign-in and go back further than feels comfortable. Check the places below. They are the usual places an attacker leaves a second door.

If you cannot show what the account did, you cannot show that you removed everything it did. Gaps in logging become gaps in the closure statement. Record them as findings.

Step 3. Decide how far credential reset has to go

Reset scope follows the account’s reach, not only its name.

• Other privileged accounts the attacker could have read or reset. Reset them, and review their authentication methods.

• Service account passwords and application secrets the account could read. Rotate in an order that does not take down production, and check each for use during the compromise window.

• The Kerberos ticket-granting account (krbtgt), when the compromise reached Domain Admin or equivalent rights. Microsoft’s procedure resets the password twice, because the account keeps a history of two passwords, and waits between resets. The documented wait is 10 hours, matching the default maximum ticket lifetimes, and it should be longer if you changed those settings.

Two judgment points apply to the krbtgt reset. First, check Active Directory replication health before you start. Second, do it only when you are confident the attacker is out. Resetting while the attacker still holds access spends a major action and teaches them you are on to them. If you are not yet confident, contain what you can, keep monitoring, and schedule the reset behind the eviction work.

Step 4. Restore trust in privileged access

• Re-issue the administrator’s access through a verified process, on a managed and clean device.

• Move to phishing-resistant authentication for privileged roles where you can. Passwords and push approvals were the weak point in many identity-led intrusions.

• Replace standing privilege with time-limited elevation where your platform supports it, so a stolen account does not carry permanent power.

• Test your break-glass accounts. Confirm they are intact, monitored and not used during the incident.

• Compare privileged role and group membership with the last approved list, and clear anything unexplained.

Step 5. Prove it is closed

Do not close on “the user is back at work”. Close on evidence against a short list.

Step 6. Learn how the account was taken

The cause tells you whether this was one account or a method that works elsewhere. Common routes include password spray or reuse, phishing that captured a session, MFA fatigue, stolen tokens from an infected device and weak access to a legacy or test account. Identify the route, then ask one question: which other privileged accounts share the same weakness? Fix that class of weakness, not only the account.

Then record what shortened or lengthened the response. Examples: no inventory of privileged accounts, no log of authentication method changes, no clean workstation for administrators, no pre-agreed authority to disable an admin. Each is a specific improvement item.

Where this response goes wrong

• Stopping at the password reset. The attacker’s persistence is somewhere else.

• Discussing the response in channels the attacker can read. Move to a clean path first.

• Resetting krbtgt too early, or only once. Both waste effort and leave risk.

• Deleting evidence while cleaning up. Export before removing.

• Treating the account as the only victim. What it reset, read or created is part of the incident.

Use this to contain identity-driven incidents: agree the first-hour roles today, keep the Step 2 table ready as a checklist, and confirm now that you can disable an administrator without waiting for permission.

Sources

• Microsoft Learn: Revoke user access in Microsoft Entra ID — disabling accounts, two password resets for hybrid, token revocation, access token lifetime, Continuous Access Evaluation and application deprovisioning.

• Microsoft Learn: Reset the krbtgt password — two resets and the wait between them.

• MITRE ATT&CK: Multi-Factor Authentication (T1556.006)

• MITRE ATT&CK: Device Registration (T1098.005)

• MITRE ATT&CK: Trust Modification (T1484.002) — federation and trust changes.

• MITRE ATT&CK: Additional Cloud Roles (T1098.003) — roles granted to maintain access.

• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management — incident response aligned to CSF 2.0.