Cloud account takeover response plan: sessions, methods, devices and grants, then what they read

What this plan is for

Somebody signed in as one of your users, and it was not the user. You found out from a risky sign-in alert, from the user noticing a login they did not make, from an MFA prompt they did not start, or from mail they did not send.

The first minutes are covered by the first 15 minutes checklist for an unrecognised sign-in and the first hour by the cloud account compromise playbook. This is the plan around them: the order of eviction, the scoping, and the evidence the write-up will need.

If the account moved money or was used to ask somebody else to, run the business email compromise plan alongside this one. The fraud has its own clock.

First, work out how they got in

The way in decides what eviction has to remove, so it is worth ten minutes before anything irreversible. The sign-in logs usually settle it.

What the sign-in logs show	What it most likely was	What that means for eviction
Many failures across many accounts from the same addresses, then one success (error 50126 before it)	Password spray or stuffing	The password is known. Check whether MFA was satisfied, and how
A burst of MFA prompts the user denied or ignored (error 500121), then one approved	MFA fatigue	The password is known and the user eventually approved. Their other methods may be fine
A successful interactive sign-in with MFA satisfied, from an unfamiliar network seconds after the user's own sign-in	Adversary in the middle: a phishing proxy relayed the user's own MFA	The session cookie was stolen. A password reset does not end a session that already exists
Non-interactive sign-ins from a new address carrying the same session as the user's real sign-ins, with no interactive sign-in from that address	Token or cookie replay	Same as above, and look for the infostealer on the user's device
Authentication protocol shown as device code	Device code phishing	A refresh token was issued to the attacker's device. Revoke it, then block the flow
An audit event for consent to an application, and activity by that application rather than by the user	Consent phishing	The grant survives everything done to the user. Remove the grant

Several can be true at once. A stolen session is commonly followed by a new MFA method, so that access survives when the session is revoked.

Phase 1: evict, in this order

Goal: close every route back in, in the order that stops each one being reused to reopen the others.

1. Revoke sessions. In the Entra admin centre, or with Revoke-MgUserSignInSession. This invalidates refresh tokens and session cookies. Access tokens already issued remain valid until they expire, by default somewhere between 60 and 90 minutes after issue, unless the application supports continuous access evaluation.
2. Disable the account if the attacker is active right now. Disabling stops new tokens being issued while you work. Re-enable once the steps below are done.
3. Remove authentication methods the user did not add. List them first. An authenticator app, phone number or passkey registered during the compromise window is the attacker's, and it survives every password reset.
4. Remove devices the user did not register. A device registered to the account can hold a primary refresh token, which is a long-lived way to request new tokens without a password.
5. Reset the password. For a hybrid identity, reset it where the password is mastered, on premises, and confirm it has synchronised.
6. Review consent grants and application ownership. Applications the user consented to, and applications or service principals the user owns or added credentials to during the window.
7. Check mailbox rules, forwarding and delegates, if the account has a mailbox. Export before removing. Rules are evidence of what they wanted to hide.
8. Check role assignments and group changes. Anything the account granted to itself or to another account during the window.

Only then re-enable the account and re-register the user's own MFA with them, through a channel you have verified.

Phase 2: scope

Goal: a timeline from the first malicious sign-in to eviction, and an honest statement of what the attacker could read and what they did.

Question	Where the answer is
When it started	The earliest sign-in from the attacker's addresses, networks or user agent. Pivot on those across the whole tenant, not only this account
Where they signed in from	Sign-in logs: IP address, autonomous system, location, device detail and user agent. The sign-in log field reference covers what each field proves
What they changed in the directory	Entra audit logs: security info registered, device registered, consent to application, role and group membership changes
What they did in mail	The unified audit log: inbox rule creation, forwarding changes, and MailItemsAccessed where your licence records it
What they read or took from files	The unified audit log: FileAccessed, FileDownloaded and sharing link creation in SharePoint and OneDrive
Whether other accounts are involved	The same addresses, user agent, application ID or lure against every other user

Retention decides how much of this you can answer. Entra sign-in and audit logs are kept for 7 days on the free tier and 30 days with Entra ID P1 or P2. The unified audit log is kept for 180 days on Audit (Standard) and longer on Audit (Premium). Export what you need on the first day, because the start of the window is the part that ages out first.

Phase 3: find the others

An account takeover is rarely one account. Before closing:

• Search sign-ins for every address and network the attacker used, across all users, successful and failed.
• Search for the same user agent string. Phishing kits and scripts often have a distinctive one.
• Search for other consent grants to the same application ID.
• Search mail for the lure that caught this user, delivered to anybody else, and for messages this account sent to colleagues during the window. Internal phishing from a trusted sender is the most common next step.
• For token theft, examine the user's own device. Session cookies are usually stolen by infostealer malware on the endpoint, and the same malware took every other saved credential in the browser.

Phase 4: recover and harden

The controls that stop the common versions of this:

• Phishing-resistant MFA (FIDO2 security keys, passkeys or Windows Hello for Business) for administrators first, then for everyone who handles money or sensitive data. Push and code-based methods are relayed by phishing proxies.
• Conditional access that requires a compliant or registered device for sensitive applications. A stolen cookie replayed from the attacker's own machine then fails.
• Block the device code flow with a conditional access authentication flows policy, except for the devices that genuinely need it.
• Restrict user consent to verified publishers and low-risk permissions, with an admin approval workflow for the rest.
• Number matching and additional context in authenticator push prompts, which makes fatigue attacks far less effective.
• Alert on security info registration from a new location, which is the step most intrusions take within minutes of getting in.

What the write-up needs

• The way in, with the sign-in events that show it.
• Every eviction step with the time it was completed and who did it.
• The window, from the first malicious sign-in to eviction, and what was reachable during it.
• What was read, changed or sent, or where that cannot be established, a statement of why not.
• The other accounts checked, and how.
• The control that would have stopped it, and whether it is now in place.