Compromised Microsoft 365 account response runbook

This is the runbook for the moment the alert is no longer "suspicious" but confirmed: someone other than the user is signed in. It is deliberately ordered. The order matters more than the speed, because the two most common mistakes — resetting the password before revoking sessions, and cleaning up before recording evidence — both make the incident longer.

If the account is a mailbox being used for fraud, the BEC response playbook covers the money side. If you are still deciding whether it is compromised at all, start with the sign-in log investigation runbook. This guide assumes you already know.

Before you touch anything: thirty seconds of evidence

Two things, and only two, before containment:

• Note the time (UTC) you declared the incident and the user principal name. Everything you search later is anchored on these.
• Open the user's sign-in logs in the Entra admin center and leave the tab open. You will filter it later; right now you just want the last 24 hours in front of you before anything you do adds noise.

Do not export mailboxes, do not screenshot every rule, do not start a Word document. Containment first.

The first fifteen minutes: containment

Run these in this order. Each step assumes the previous one is done.

1. Disable the account. Entra admin center, or Update-MgUser -UserId user@contoso.com -AccountEnabled:$false. This stops new token issuance. It does not stop tokens already issued — hence step 2.
2. Revoke sessions. Revoke-MgUserSignInSession -UserId user@contoso.com. This invalidates refresh tokens, so every client has to reauthenticate — and cannot, because the account is disabled. Access tokens already in hand live until they expire, which is typically about an hour for most Microsoft 365 workloads; Continuous Access Evaluation shortens that dramatically for Exchange, SharePoint and Teams.
3. Reset the password to a long random value the user does not know yet. Do this after revocation: a reset alone does not kill existing refresh tokens on every client type.
4. Mark the user as compromised in Entra ID Protection (Risky users → Confirm compromised). This raises the user's risk to High so any risk-based Conditional Access policy bites immediately, and it teaches the detection engine.
5. Reset MFA. Entra admin center → user → Authentication methods → Require re-register multifactor authentication, then delete any method you do not recognise. Attackers who have been in for more than a few minutes almost always register their own Authenticator or a new phone number.
6. If the user is an admin, remove all role assignments and PIM eligibilities now, and check whether any other admin account was touched from the same session. An attacker in a Global Administrator account for an hour can leave persistence you will not find in the user's own mailbox.

If you run Defender XDR with automatic attack disruption enabled, steps 1, 2 and 4 may already have happened. Check the incident before repeating them — but repeating them is harmless.

The first hour: persistence hunting

The attacker's goal in the first hours of any compromise is to survive the password reset. Check every one of these — not the ones you think are likely.

Mailbox

• Inbox rules: Get-InboxRule -Mailbox user@contoso.com | Format-List Name,Enabled,Description. Look for rules that delete, move to RSS Feeds or Archive, or forward. Rules with blank names are a classic tell.
• Forwarding: Get-Mailbox user@contoso.com | Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward.
• Delegates and Send As: Get-MailboxPermission and Get-RecipientPermission on the mailbox. Remove anything added in the window.
• Mailbox audit: Search-UnifiedAuditLog (or the Purview audit search) for the user over the incident window — look for New-InboxRule, Set-Mailbox, Add-MailboxPermission, MailItemsAccessed, and SearchQueryInitiated events. The last two tell you what the attacker read and searched for.

Identity

• OAuth consents: Get-MgUserOauth2PermissionGrant -UserId user@contoso.com. Any grant to an app you do not recognise, particularly one requesting Mail.Read, Mail.Send, Files.ReadWrite.All or offline_access, is persistence. Revoke it, and then check whether the same app has grants from other users.
• Registered devices: Entra admin center → user → Devices. A newly registered or joined device you do not recognise gets deleted, and if it was joined it also gets a look in Intune.
• Authentication methods: already reset in containment, but confirm that the list is now empty apart from what the user will re-register.
• Application-level: if the user owned any app registrations, check whether new client secrets or certificates were added. This is the most commonly missed persistence mechanism.

Collaboration

• SharePoint and OneDrive sharing: audit log operations SharingSet, AnonymousLinkCreated, SharingInvitationCreated for the user. An attacker who has read the mailbox often shares a folder externally as a second exit.
• Teams: check for new external chats, new apps installed to the user's scope, and any meeting join links sent out.

Record what you find as you go. A short bullet list with timestamps is enough; you are writing for the person doing the post-incident review, not a court.

Scope: was it only one account?

Take the attacker's IP addresses and user agents from the sign-in log and search all sign-ins for them over the last 30 days. In Defender XDR, AADSignInEventsBeta and EmailEvents in advanced hunting answer this in one query; in Entra alone, the sign-in log filter on IP address works. Every account that shares an indicator goes through this runbook too.

Then look at what the compromised account sent: message trace from the mailbox over the window, and any outbound messages with attachments or links. Recipients inside your organisation who clicked are your next candidates.

Handing the account back

Do not re-enable until every one of these is true:

• Persistence checks above are complete and everything found is removed.
• The user has been spoken to — by phone or in person, not email — and knows a new password and MFA registration are coming.
• MFA re-registration happens with a human from IT present or on a call. Attackers have been known to sit in the re-registration window.
• Any device the attacker signed in from that belongs to the user has been reviewed, or wiped if you cannot prove it is clean.
• A Conditional Access policy that requires MFA — ideally phishing-resistant — actually applies to this user. If the account was compromised because it was excluded from CA, fix the exclusion before re-enabling.

Then: enable the account, set the password to a value delivered out of band, have the user sign in and register methods, and watch the sign-in log for the next 48 hours. Clear the Risky user flag only after the user's first clean sign-ins.

What needs support, and what needs downtime

Nothing in this runbook requires Microsoft support. The one exception is if the compromised account was the only Global Administrator and the attacker changed the recovery details — that becomes a tenant-recovery case with Microsoft, and it is slow, which is why break-glass accounts exist.

Downtime is limited to the affected user, for however long persistence hunting takes. Resist pressure to shorten that window. An account re-enabled with an inbox rule still in place is the start of the next incident, not the end of this one.