How to block a compromised account in Microsoft 365

Blocking a compromised Microsoft 365 account is four actions done within minutes — block sign-in, revoke sessions, reset the password, reset MFA — followed by removing the persistence an attacker typically leaves behind. Doing only the first one is the most common mistake: a blocked account with live tokens is still an open door for up to an hour, and a mailbox rule keeps working regardless.

This page is the containment step in isolation. The full investigation, scoping, and hand-back are in the compromised account runbook; if the compromise was used for invoice fraud, continue with the BEC response playbook.

Prerequisites

• Roles: User Administrator (block sign-in, reset password), Authentication Administrator or Privileged Authentication Administrator (MFA methods), Exchange Administrator (rules and forwarding), and Security Operator or higher in the Defender portal if you use the one-click actions there. Rehearse who holds these at 3 a.m.; if it is nobody, fix the admin role design before the next incident.
• Exchange Online PowerShell and the Graph PowerShell SDK installed on an admin workstation that is itself not the suspect device.
• A ticket. Every action below is audited and you will want a single place to record what was done and when.

Steps

1. Block sign-in

Microsoft 365 admin center → Users → Active users → the user → Block sign-in, or in Entra: Users → the user → Edit properties → Account enabled: No.

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
Update-MgUser -UserId user@contoso.com -AccountEnabled:$false

2. Revoke sessions

This is the action that ends an active session. In Entra on the user's Overview choose Revoke sessions, or:

Revoke-MgUserSignInSession -UserId user@contoso.com

For Exchange, SharePoint, and Teams, Continuous Access Evaluation enforces this within minutes. Other apps honour it at token expiry.

3. Reset the password

Reset to a long random value; do not hand it to the user yet. If the account is synced from on-premises AD, reset it in AD and force a sync (Start-ADSyncSyncCycle -PolicyType Delta) or the cloud value will be overwritten — see Entra Connect vs Cloud Sync for which sync path applies.

4. Reset MFA and check registered methods

Open Authentication methods for the user. Delete any method you do not recognise — attackers routinely register their own Authenticator app so they survive a password reset — then Require re-register MFA. The step-by-step is in how to reset MFA for a user.

5. Remove mailbox persistence

Connect-ExchangeOnline
# Inbox rules — look for delete/move/forward rules with innocuous names like "."
Get-InboxRule -Mailbox user@contoso.com | Format-List Name,Description,Enabled
# Forwarding
Get-Mailbox user@contoso.com | Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward
Set-Mailbox user@contoso.com -ForwardingAddress $null -ForwardingSmtpAddress $null
# Delegates and Send As granted during the compromise window
Get-MailboxPermission user@contoso.com | Where-Object {$_.User -notlike "NT AUTHORITY*"}
Get-RecipientPermission user@contoso.com

Remove anything created inside the compromise window. Also review Mail flow → Rules for tenant-level transport rules an attacker with admin rights might have added.

6. Remove OAuth consents and registered devices

Entra → Users → the user → Applications lists apps the user consented to; revoke anything unfamiliar or anything consented during the window. Attacker-consented apps keep Graph access after a password reset, which is the whole point of them — background in cleaning up over-consented app permissions. Under Devices, remove or disable devices registered during the window.

7. Mark the user compromised

In Entra ID Protection (Protection → Identity Protection → Risky users) select the user and Confirm user compromised. It trains the risk model and, if you have a risk-based Conditional Access policy, keeps the account blocked until an admin dismisses the risk. In the Defender portal the user page offers Disable user and Confirm user compromised together.

Verify

• Sign-in logs for the user show only failures after the block, and no successful sign-ins from the attacker's IPs after revocation.
• Get-InboxRule and the forwarding properties are clean; no unexpected apps or devices remain.
• The risky-user entry shows Confirmed compromised and the account remains disabled until the investigation in the runbook is done.

Roll back

Re-enabling is a decision, not a reversal. Before Update-MgUser -AccountEnabled:$true: the investigation has established what the account accessed, the password is new and known only to the user, MFA is re-registered on a device you trust, and the user has been told what happened. If the alert turns out to be a false positive (a traveller, a new VPN egress), dismiss the risk in Identity Protection rather than leaving confirmed compromised on a clean account — that entry feeds future risk scoring. The sign-in log investigation runbook covers telling the two apart.