Incident Response Checklist for a Compromised Office 365 Account

Overview

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 Containment

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

1.1 Reset the user's password

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 "[email protected]" -PasswordProfile @{
    Password = (New-Guid).ToString().Substring(0,16) + "!A1"
    ForceChangePasswordNextSignIn = $true
}

1.2 Revoke all active sessions

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

Revoke-MgUserSignInSession -UserId "[email protected]"

1.3 Block sign-in (if still uncertain)

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 "[email protected]" -AccountEnabled:$false

1.4 Disable any app passwords

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: Investigation

2.1 Check the Unified Audit Log

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 "[email protected]" `
    -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 rules

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

Get-InboxRule -Mailbox "[email protected]" | Format-List Name, Description, Enabled, MoveToFolder, DeleteMessage, ForwardTo, RedirectTo

2.3 Check mail forwarding

Get-Mailbox -Identity "[email protected]" | Format-List ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward

2.4 Check OAuth app consents

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 logs

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: Remediation

3.1 Remove malicious inbox rules

# Remove a specific rule by name
Remove-InboxRule -Mailbox "[email protected]" -Identity "rule-name" -Confirm:$false

3.2 Remove mail forwarding

Set-Mailbox -Identity "[email protected]" -ForwardingSmtpAddress $null -ForwardingAddress $null -DeliverToMailboxAndForward $false

3.3 Remove malicious OAuth apps

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

# List service principal assignments for the user
Get-MgUserAppRoleAssignment -UserId "[email protected]"

# Remove suspicious assignment
Remove-MgUserAppRoleAssignment -UserId "[email protected]" -AppRoleAssignmentId "<id>"

3.4 Re-enable sign-in and enforce MFA

Once the investigation is complete:

Update-MgUser -UserId "[email protected]" -AccountEnabled:$true

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

3.5 Notify affected parties

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: Prevention

Immediate hardening

• 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 monitoring

• 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 awareness

• 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 Template

Document every incident using a standard format:

Summary

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.