Compromised M365 Account Response Plan

Overviewsection

A compromised Microsoft 365 account is one of the most common security incidents businesses face. Attackers use stolen credentials to send phishing emails from the victim's mailbox, set up inbox rules to hide their activity, and sometimes pivot to business email compromise (BEC) fraud.

This checklist gives you a repeatable process to contain, investigate, remediate, and prevent a recurrence.

Phase 1: Immediate Containmentsection

These actions must happen within the first 15 minutes of confirmed or suspected compromise.

1.1 Reset the user's passwordsection

Change the password immediately. Use a strong, random password and do not send it to the user via email.

# Connect to Microsoft 365
Connect-MgGraph -Scopes "User.ReadWrite.All"

# Reset password — force change at next sign-in
Update-MgUser -UserId "user@company.com" -PasswordProfile @{
    Password = (New-Guid).ToString().Substring(0,16) + "!A1"
    ForceChangePasswordNextSignIn = $true
}

1.2 Revoke all active sessionssection

The password reset alone does not kill existing sessions. Revoke them explicitly.

Revoke-MgUserSignInSession -UserId "user@company.com"

1.3 Block sign-in (if still uncertain)section

If you suspect the attacker has a secondary persistence method (app password, OAuth app), block sign-in entirely until investigation is complete.

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

1.4 Disable any app passwordssection

App passwords bypass MFA. If the user has any, remove them immediately from the Microsoft Entra admin center (entra.microsoft.com) MFA settings page.

Phase 2: Investigationsection

2.1 Check the Unified Audit Logsection

Search for suspicious activity in the last 30 days. You can use the Search-UnifiedAuditLog cmdlet via Exchange Online PowerShell, or use the Microsoft Purview compliance portal (compliance.microsoft.com) which provides a UI-based audit search under Audit (Standard). Purview audit is now the recommended way to access and search audit logs.

# Connect to Exchange Online
Connect-ExchangeOnline

# Search audit log for the compromised user
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
    -UserIds "user@company.com" `
    -ResultSize 5000 | Export-Csv -Path ".\AuditLog-user.csv" -NoTypeInformation

Look for:

• MailItemsAccessed — did the attacker read specific emails?
• Send or SendAs — did they send emails from the account?
• New-InboxRule — did they create forwarding or deletion rules?
• UpdateInboxRules — modification of existing rules
• Add-MailboxPermission — did they grant access to another account?
• Consent to application — did they authorise a malicious OAuth app?

2.2 Check inbox rulessection

Attackers almost always create inbox rules to delete or redirect replies to their phishing emails.

Get-InboxRule -Mailbox "user@company.com" | Format-List Name, Description, Enabled, MoveToFolder, DeleteMessage, ForwardTo, RedirectTo

2.3 Check mail forwardingsection

Get-Mailbox -Identity "user@company.com" | Format-List ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward

2.4 Check OAuth app consentssection

In the Microsoft Entra admin center (entra.microsoft.com), navigate to Applications > Enterprise applications and review any recent consents granted by the compromised user. Revoke any unfamiliar applications.

2.5 Review sign-in logssection

In the Microsoft Entra admin center (entra.microsoft.com), go to Monitoring > Sign-in logs and filter for the user. Look for:

• Logins from unfamiliar IP addresses or countries
• Logins from unusual user agents (often Python-based libraries)
• Successful logins without MFA challenges

Phase 3: Remediationsection

3.1 Remove malicious inbox rulessection

# Remove a specific rule by name
Remove-InboxRule -Mailbox "user@company.com" -Identity "rule-name" -Confirm:$false

3.2 Remove mail forwardingsection

Set-Mailbox -Identity "user@company.com" -ForwardingSmtpAddress $null -ForwardingAddress $null -DeliverToMailboxAndForward $false

3.3 Remove malicious OAuth appssection

Revoke consent for any suspicious apps via the Microsoft Entra admin center or:

# List service principal assignments for the user
Get-MgUserAppRoleAssignment -UserId "user@company.com"

# Remove suspicious assignment
Remove-MgUserAppRoleAssignment -UserId "user@company.com" -AppRoleAssignmentId "<id>"

3.4 Re-enable sign-in and enforce MFAsection

Once the investigation is complete:

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

Ensure the user is enrolled in MFA. Use Conditional Access policies to require MFA for all sign-ins.

3.5 Notify affected partiessection

If the attacker sent phishing or BEC emails from the compromised account, notify the recipients (internal and external) that the messages were not legitimate.

Phase 4: Preventionsection

Immediate hardeningsection

• Enable MFA for all users via Conditional Access (not per-user MFA). Use authentication strengths in Conditional Access to require phishing-resistant MFA (passkeys/FIDO2, Windows Hello, certificate-based authentication)
• Microsoft Authenticator push notifications now require number matching by default, which helps prevent MFA fatigue attacks
• Disable legacy authentication protocols (POP, IMAP, SMTP AUTH)
• Conditional Access policies are strongly preferred over Security Defaults for any organisation with Microsoft Entra ID P1 or higher. Use Security Defaults only if you do not have a Conditional Access licence
• Block app passwords for all users
• Enable Microsoft Entra ID Protection risk-based policies to automatically detect and respond to risky sign-ins and compromised users
• Enable token protection and continuous access evaluation (CAE) to ensure that revoked sessions are enforced in near real-time, rather than waiting for the token to expire

Ongoing monitoringsection

• Enable mailbox audit logging for all mailboxes
• Configure alerts for suspicious inbox rule creation
• Configure alerts for impossible travel sign-ins
• Review Microsoft Entra sign-in risk reports weekly

User awarenesssection

• Conduct targeted phishing simulation for the affected team
• Provide the compromised user with a post-incident briefing
• Update the organisation's incident response documentation with lessons learned

Incident Report Templatesection

Document every incident using a standard format:

Summarysection

Responding to a compromised M365 account follows a consistent pattern: contain by resetting credentials and revoking sessions, investigate audit logs and inbox rules, remediate by removing persistence mechanisms, and prevent by hardening the environment. Speed matters — the longer an attacker has access, the more damage they can do.