What to Do If a Microsoft 365 Account Gets Compromised

A Microsoft 365 account compromise can mean many things - a user handing over their password to a phishing page, credentials leaked in a data breach, a session token stolen through malware, or a brute-force attack against a weak password. What matters in the first few minutes is not understanding exactly how it happened. What matters is stopping access and assessing the damage before it gets worse.

This is a practical checklist of exactly what to do, in order.

Account Response Checklist

Work through each phase in order. Tick steps as you complete them - progress is saved in your browser.

Immediate: Kill Access

1. 1
   Revoke all sessions

   entra.microsoft.com›Users›[User]›Revoke sessions

   This invalidates every active access token immediately. Any open browser session, mobile app, or desktop client using the account will be signed out.
2. 2
   Reset the password

   Reset via the admin portal and communicate the new password through a secure out-of-band channel (phone call, SMS to a verified number, in person). Do not send it by email to the compromised account.
3. 3
   Block sign-in (temporarily)

   In Entra ID, set the account's sign-in status to Blocked. This prevents any login while you investigate, even with the correct new password. Re-enable once you have completed the checks below.
4. 4
   Force MFA re-registration

   Go to the user's authentication methods in Entra ID and delete all registered MFA methods. The attacker may have registered their own device. When you unblock sign-in, the user will need to set up MFA fresh.

Find and Remove Attacker Persistence

Attackers in a compromised M365 account typically try to maintain access even after a password reset. Check each of these:

Inbox rules

The most common persistence mechanism. Check for rules that forward email externally, move emails from IT or security to deleted items (to hide alerts), or delete emails matching certain keywords.

Get-InboxRule -Mailbox "user@domain.com" | Select Name, ForwardTo, RedirectTo, DeleteMessage, MoveToFolder

Delete any rules that were not created by the user, particularly any with external forwarding addresses.

Registered MFA methods and trusted devices

Check Entra ID › Users › [User] › Authentication methods. Remove any device or phone number you do not recognise. Also check Entra ID › [User] › Devices for any devices you do not recognise and remove them.

OAuth app permissions

Attackers may grant a third-party OAuth app access to the mailbox. This survives a password reset because it uses a separate token. Check:

Remove any app permissions you do not recognise, especially apps with Mail.Read, Mail.ReadWrite, or Files.Read permissions.

Email aliases and forwarding at the mailbox level

Check the Exchange Admin Centre › Mailboxes › [User] › Email address to see if aliases were added, and › Manage mail flow settings › Email forwarding to check for SMTP forwarding added at the mailbox level (separate from inbox rules).

Check the Audit Trail

Run an audit search for the compromised user covering the suspected compromise window. Key activities to look for:

• MailItemsAccessed - which emails were read (requires E5 or Compliance add-on)
• FileDownloaded, FileAccessed - SharePoint and OneDrive file access
• New-InboxRule, Set-InboxRule - any inbox rules created
• Add app role assignment - OAuth permissions granted
• UserLoggedIn - all successful sign-ins with IP, location, and device
• SendAs, Send on behalf - if the attacker sent emails

Export the results and document the timeline. This is your evidence trail for the post-incident review and any potential regulatory notification.

Assess Data Exposure

Based on the audit log, determine what data the attacker had access to. Consider:

• What emails did they read? Did those emails contain personal data, financial information, or credentials?
• What files did they access or download from SharePoint/OneDrive?
• Did they access any shared mailboxes or have delegate access to other accounts?
• Did they send any emails on behalf of the user that may have impersonated them to colleagues or customers?

Harden Before Re-enabling

Before unblocking sign-in and returning the account to the user:

• Confirm MFA is configured on the account (by the user, not just your admin re-registration)
• Confirm all attacker persistence mechanisms have been removed
• Consider requiring a Conditional Access compliant device for this user going forward
• Brief the user on what happened and what to watch for (follow-up phishing targeting the same user is common)
• Monitor the account's sign-in logs for the next 2-4 weeks

If an Admin Account Was Compromised

An admin compromise is categorically more serious. A Global Admin or Security Admin can create backdoor accounts, grant themselves permanent access, disable security controls, delete audit logs, and read all mailboxes in the tenant. Treat it as a full tenant compromise and:

• Engage your incident response process immediately and notify senior management
• Check whether new admin accounts were created during the compromise window
• Check whether any Conditional Access policies were modified or disabled
• Check whether audit logging was modified
• Review the full audit log for all admin operations during the window, not just the compromised account's actions
• Consider whether a complete credential reset across the tenant is necessary
• Engage Microsoft Support if you have a support contract - they have access to additional telemetry