Responding to a Suspected Account Compromise

Contain first, investigate second. Revoke active sessions, audit inbox rules and forwarding, review sign-in logs, reset credentials and MFA, then assess what the attacker accessed or sent.

Last reviewed June 2026. Uses commands from the Entra ID builder, Exchange builder, and Security builder.

A compromised M365 account is a race between the attacker's dwell time and your response speed. The first priority is always containment, cutting the attacker's access to the account, before any investigation. Investigating an account the attacker is still logged into is like reading footprints while someone is still walking on them.

Do not reset the password as your first action if you suspect business email compromise (BEC) or an active financial transaction. Alerting the attacker by locking them out can trigger a final fraudulent action. Consult with the client first about the business context. In most cases, revoke sessions first (which is less visible), then reset credentials once you have a plan.

Step 1: Revoke active sessions immediately

Revoking sign-in sessions forces all current tokens to become invalid. The attacker loses any active browser sessions and OAuth tokens within minutes. This does not require a password reset and is the safest first action in almost all cases.

Revoke-MgUserSignInSession -UserId user@contoso.com

Confirm the revocation succeeded (the command returns a simple success/failure). The effect propagates across services within one to fifteen minutes depending on the service's token cache lifetime. Conditional access policies evaluate the revocation faster than older tokens expiring naturally.

If the account has active Exchange sessions, also disconnect them:

Get-PSSession | Remove-PSSession

Step 2: Block sign-in while you work

If the situation warrants locking the account entirely while you investigate, block sign-in without resetting the password yet. This prevents new logins while preserving the existing password for forensic reference if needed.

Update-MgUser -UserId user@contoso.com -AccountEnabled:$false

Remember to re-enable it once you have reset credentials and MFA:

Update-MgUser -UserId user@contoso.com -AccountEnabled:$true

Step 3: Audit inbox rules and forwarding

Attackers routinely create inbox rules to hide their tracks: forwarding replies to external addresses, moving messages to obscure folders, or deleting security notifications. These rules persist after a session is revoked and continue operating.

Get-InboxRule -Mailbox user@contoso.com |
  Select-Object Name, Description, Enabled, ForwardTo, ForwardAsAttachmentTo, RedirectTo, DeleteMessage, MoveToFolder

Look for any rule that forwards externally, redirects to an unusual folder, or deletes messages. Any rule you did not create is suspicious. Remove malicious rules:

Remove-InboxRule -Mailbox user@contoso.com -Identity "Rule Name" -Confirm:$false

Also check SMTP forwarding set directly on the mailbox, which bypasses inbox rules entirely and is invisible to the end user:

Get-Mailbox user@contoso.com | Select-Object ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward

If either forwarding field is set and you did not configure it, clear it:

Set-Mailbox user@contoso.com -ForwardingSmtpAddress $null -ForwardingAddress $null

Step 4: Review sign-in logs

The sign-in logs show where the attacker logged in from, when, and using which client. This establishes the timeline and confirms whether the compromise is ongoing or historical.

Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'user@contoso.com'" -Top 50 |
  Select-Object CreatedDateTime, IpAddress, Location, AppDisplayName, ClientAppUsed, Status, RiskDetail |
  Sort-Object CreatedDateTime -Descending

Look for logins from unusual geographies, unknown IP addresses, or at times inconsistent with the user's normal working pattern. Logins from two geographies simultaneously (impossible travel) or from known VPN exit nodes associated with credential stuffing are strong indicators of compromise.

If Entra ID Identity Protection is licensed, check for risky sign-ins and user risk events, which may have already flagged the compromise before you were called. Get-MgRiskyUser and Get-MgIdentityProtectionRiskyUser show accounts with outstanding risk signals.

Check which apps the attacker accessed

Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'user@contoso.com'" -Top 100 |
  Group-Object AppDisplayName | Select-Object Name, Count | Sort-Object Count -Descending

An attacker who accessed SharePoint, OneDrive, or Teams in addition to mailbox means the scope extends beyond email. Document what was accessed before scoping down.

Step 5: Check for MFA manipulation

After gaining access, attackers frequently register an additional MFA method (their own phone number or authenticator app) so they can maintain access after a password reset. Check registered authentication methods before resetting:

Get-MgUserAuthenticationMethod -UserId user@contoso.com |
  Select-Object Id, AdditionalProperties

Remove any method the user does not recognise. Then reset the password and re-register MFA with the legitimate user present and verified. Never re-register MFA over an unverified phone call or email thread; verify identity out of band.

# Reset password via Entra ID admin center or:
Update-MgUser -UserId user@contoso.com -PasswordProfile @{
  Password = "NewTemporaryPassword123!"; ForceChangePasswordNextSignIn = $true
}

Step 6: Check for mail sent by the attacker

BEC attacks send fraudulent payment instructions, credential phishing to internal contacts, or data exfiltration via email. Trace what the attacker sent during the compromise window:

Get-MessageTraceV2 -SenderAddress user@contoso.com `
  -StartDate "2024-01-01" -EndDate "2024-01-07" |
  Select-Object Received, RecipientAddress, Subject, Status |
  Sort-Object Received

Adjust the date range to the compromise window from the sign-in logs. Look for messages to external addresses, especially finance-related domains, or internal messages the user does not recall sending. If fraudulent messages were sent to internal recipients, they need to be warned and the messages may need to be purged.

Purge malicious sent messages from recipient inboxes

# Requires Compliance Search permissions
New-ComplianceSearch -Name "BECCleanup" -ExchangeLocation All `
  -ContentMatchQuery "From:user@contoso.com AND Subject:'Wire Transfer'"
Start-ComplianceSearch -Identity "BECCleanup"
# Review results before purging:
New-ComplianceSearchAction -SearchName "BECCleanup" -Purge -PurgeType SoftDelete

Step 7: Check for app consents granted by the attacker

OAuth consent phishing tricks users into granting a malicious app permissions to their mailbox or files. The attacker no longer needs the account credentials; the app token keeps working until the consent is revoked.

Get-MgUserOauth2PermissionGrant -UserId user@contoso.com |
  Select-Object ClientId, Scope, ConsentType

Any consent granted during the compromise window to an unrecognised application should be revoked. Revoke the specific grant:

Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "grant-id"

After containment: document and prevent

Once the account is secured, document the timeline from sign-in logs, the rules found, messages sent, and apps consented to. This is the incident report. Then address why the compromise succeeded: was MFA absent or bypassable, was the password reused from a breached service, or was a phishing link clicked? The answer determines the prevention.

For tenants without Conditional Access, this is the strongest argument for introducing it. An account with MFA can still be compromised via adversary-in-the-middle phishing (Evilginx, Modlishka and similar tools); phishing-resistant MFA (FIDO2 keys or Windows Hello for Business) is the only reliable defence against that class of attack. The conditional access guide covers the baseline policies worth deploying in MSP-managed tenants.