Identity Compromise Response Plan: The First Hour After a Stolen Login

When an account is compromised, revoke its sessions and tokens first, then reset the password, remove anything the attacker registered, and save the logs. Then ask the question that decides how big this is: what could this identity reach? A password reset on its own is the most common mistake in identity incidents. Modern phishing does not just steal passwords; it steals the signed-in session, and that session keeps working after the password changes. This guide is the identity playbook in the master plan and playbooks structure. The incident response hub has the rest.

What counts as an identity compromise?

Any case where someone other than the owner can act as a user, service or admin account. The common routes are:

• Relay (adversary-in-the-middle) phishing. A fake login page passes the real sign-in through and keeps the session cookie. Push MFA and one-time codes do not stop it.
• MFA fatigue. Repeated push prompts until someone taps approve.
• Help-desk social engineering. A caller convinces support to reset MFA or the password.
• Consent phishing. The user grants a malicious app access to their mail or files. No password is stolen at all.
• Stolen credentials and tokens from infostealer malware or leaked files, including API keys and service-account secrets.
• Privileged account takeover. Any of the above, on an admin.

What should you do in the first hour?

1. Declare under the master plan and record the first-detection time.
2. Export the evidence: sign-in logs, directory audit logs and mailbox audit logs for the account. Default retention is often 7 to 30 days.
3. Revoke all sessions and refresh tokens. In most identity providers this is a separate action from a password reset.
4. Reset the password and any app passwords.
5. Remove what the attacker added: MFA methods and devices registered recently, OAuth consents, API keys, app registration secrets.
6. Check the mailbox for forwarding and hiding rules. Export them before deleting them; they show intent.
7. Work out reach (next section) and set the severity.

The Identity Compromise Response Checklist has each step with owners and sample answers. For leaked secrets rather than a phished person, the leaked credential response guide covers rotation.

Why doesn’t a password reset fix it?

Because the attacker rarely needs the password again. After a successful relay phish they hold a session cookie and often a refresh token, which lets them get new access tokens without signing in. Depending on the provider and settings, those survive a password change. Attackers also add their own way back in within minutes: their own authenticator app, a registered device, an app password, or consent for an app they control. Each of these is independent of the password.

The reliable order is: revoke sessions, remove attacker-added methods and grants, then reset. And check again 24 hours later, because some access tokens remain valid until they expire.

How do you work out the blast radius of a compromised identity?

Severity in an identity incident depends almost entirely on reach. List:

• Group memberships and admin roles, including roles assigned “temporarily” and never removed.
• Applications the account can open through single sign-on, especially cloud consoles, finance systems, HR systems and code repositories.
• Cloud roles the identity can assume through federation.
• Data: mailboxes, shared drives and databases it can read.
• Delegated access: other people’s mailboxes or calendars, and anything a service account it owns can do.

If the account can reach a cloud console, open the cloud playbook. If it can read personal data in bulk, start the data breach playbook’s scoping. If it is a mailbox used for payments, open the email and BEC playbook. The Identity Blast Radius Estimator turns those answers into a reach score and the playbooks to open.

Where do attackers hide after an account takeover?

Hunt for persistence before you call the account clean. The usual places:

• A new MFA method or registered device.
• Inbox rules that forward mail or move messages containing words like “invoice”, “payment” or “security”.
• OAuth apps granted access, and new secrets or certificates on app registrations or service principals.
• New user accounts, or guest accounts invited from outside.
• Changes to conditional access policies, trusted locations or federation settings. An attacker with admin rights who adds a federated domain or identity provider can sign in as anyone.
• API keys and personal access tokens created in SaaS tools the account could reach.

Look across the whole window, from the first suspicious sign-in, not from when the alert fired.

What changes when the compromised account is an admin?

Assume the tenant itself may be compromised. Move incident communications to a channel that does not depend on it. Use break-glass accounts that are stored offline and monitored. Review every admin role assignment, federation setting and conditional access change across the attacker’s window, not just the one account. Rotate credentials of other admins, since an admin can reset them. The Admin Account Takeover Lab rehearses these decisions in order, and the account takeover lab covers the user-account version.

When does an identity incident become something else?

Most identity incidents end as identity incidents. The ones that do not are the expensive ones. Raise severity under the master plan and open the next playbook when:

• the account assumed a cloud role or created keys (cloud playbook);
• the account downloaded or exported personal or confidential data (data breach playbook);
• the mailbox sent payment instructions or changed supplier details (email and BEC playbook);
• the account touched build pipelines or code signing (DevSecOps playbook).

The Cascade Incident Lab follows exactly this path: a phished finance analyst whose group could reach the cloud console.

How do you stop it happening again?

• Phishing-resistant MFA (FIDO2 keys, passkeys or certificate-based authentication) for admins and anyone with console access first.
• No standing admin rights: just-in-time elevation with approval and expiry.
• Restrict user consent to apps from verified publishers, with admin review for the rest.
• Help-desk identity checks that do not rely on information an attacker can find.
• Forward identity logs to your own store with retention measured in months.

Checklist: identity compromise response

• Incident declared and first-detection time recorded.
• Sign-in, audit and mailbox logs exported.
• All sessions and refresh tokens revoked.
• Password and app passwords reset.
• Attacker-added MFA methods, devices, OAuth consents and keys removed.
• Inbox rules exported and removed.
• Reach listed: groups, roles, apps, cloud roles, data, delegations.
• Persistence hunted across the full window, including federation and conditional access.
• Next playbooks opened where reach requires it.
• Re-checked after 24 hours.

Frequently asked questions

Is resetting the password enough after an account compromise? No. Attackers who use relay phishing pages capture the session cookie or refresh token, which stays valid after a password change. You also need to revoke all sessions and refresh tokens, remove any MFA method, app password, OAuth consent or API key the attacker added, and check for inbox rules and new accounts.

How do I know what a compromised account could access? List its group memberships and admin roles, the applications assigned to it through single sign-on, any cloud console roles it can assume, mailboxes and files it can open, and any delegated or shared access. The answer sets the severity: an account that can reach a cloud console or customer data is a potential cloud or data breach, not just an identity incident.

What persistence do attackers leave after an account takeover? Common ones are a new MFA method or registered device, mailbox forwarding or hiding rules, consent granted to a malicious OAuth app, new credentials added to an app registration or service principal, new user accounts, changes to conditional access or federation settings, and API keys created in SaaS tools the account can reach.

How long are identity provider sign-in logs kept? It depends on the provider and licence tier. Default retention for sign-in and audit logs is often between 7 and 30 days, sometimes longer on premium tiers. Export them at the start of an investigation, or forward them to your own log store all the time, so evidence is not lost while you investigate.

What is phishing-resistant MFA? MFA that cannot be relayed by a fake login page, because the credential is bound to the real website. FIDO2 security keys, passkeys and certificate-based authentication are phishing-resistant. Push approvals, SMS codes and one-time passwords are not, because a user can be tricked into approving or typing them into an attacker’s page.