How to Investigate and Respond to a Compromised Microsoft 365 Account

A Microsoft 365 (M365) account compromise means an attacker has gained unauthorized access to a user’s identity and resources. This can happen via stolen credentials (passwords), hijacked sessions (e.g. device-code/OAuth attacks), or illicit app consents.

The first priority is to contain the breach quickly: disable the account, reset passwords, revoke sessions and tokens. Next, perform a thorough investigation using Entra (Azure AD) sign-in logs, Microsoft 365 audit logs, and mailbox data to determine what happened. Remove any attacker persistence (device registrations, refresh tokens, malicious inbox rules or forwarding, OAuth app grants) and validate that only legitimate access remains.

Finally, restore the user’s access securely and harden the environment (Conditional Access, phishing-resistant MFA, logging) to prevent recurrence. This guide provides step-by-step instructions, checklists, and technical tips for IT and security teams handling an M365 account takeover, including examples of PowerShell/Graph commands, a detection matrix, and a flowchart for incident response.

What is a Microsoft 365 account compromise?

A compromised Microsoft 365 account means an attacker has obtained valid access tokens or credentials for a user’s M365 account (including Exchange Online, OneDrive, etc.). This can happen via:

• Credential theft: The attacker obtains the user’s password (through phishing, brute force, password reuse, or malware) and logs in as them. If MFA is in use, attackers may try to intercept or bypass it.
• Session or token theft: Even without the password, attackers can hijack a valid session or token. For example, in device-code phishing, the attacker initiates a Microsoft device-login flow and tricks the user into entering a code into the legitimate Microsoft login page. The user unknowingly authorizes the attacker’s session, who then holds a valid OAuth token for the account.
• OAuth app abuse: Attackers may trick a user (or admin) into consenting to a malicious OAuth application, giving the app broad access to the user’s mailbox and data. This is often called “illicit consent” or “phishing with OAuth” and is increasingly common with cloud services.
• Passive MFA/Session hijack: Less common in corporate accounts, but if an attacker breaches an endpoint (workstation) where the user was already signed in, they may steal session cookies or tokens from the browser or device memory.

Each path leaves different clues. For example, credential theft often shows a new login from an unfamiliar IP or location. Device-code phishing specifically shows a sign-in event marked as a device code flow (and often an associated “continuation” sign-in at Microsoft). OAuth abuses may produce new “service principal” or “consent grant” audit events.

A compromise is confirmed if you see evidence of unauthorized activity (e.g. phishing sent from the mailbox, changes to settings) combined with unusual sign-in or token events. Treat any confirmed or strongly suspected unauthorized access as a full account takeover incident.

Immediate Containment (First 15 Minutes)

When you suspect an M365 account is compromised, time is critical. The goal in the first few minutes is to isolate the account and block the attacker while preserving evidence:

• Block or disable the account: In the Microsoft Entra ID (Azure AD) admin center, locate the user and either temporarily block sign-in or disable the account. This prevents further logins (including via existing sessions or Single Sign-On). Blocking in Entra is often faster for one user; disabling the AD user (in on-premises AD) may be needed if password sync is in place.
• Reset credentials: Reset the user’s password immediately. In a hybrid environment, change the on-premises AD password twice in a row (to avoid pass-the-hash reuse) before syncing to Azure AD. Use a complex, unique password. Instruct the user (from a clean device) to log in with the new password once the device is safe.
• Revoke active sessions and tokens: Use PowerShell or the portal to revoke all existing refresh tokens.

For example, with Microsoft Graph PowerShell:

powershellCopyInstall-Module Microsoft.Graph.Users.Actions
Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId user@contoso.com

• This invalidates the user’s refresh tokens and forces re-authentication. Note that Azure AD access tokens may remain valid for up to an hour (pending continuous access evaluation), so also block/disable the account (as above) to cut off any immediate access.
• Force re-enrollment of MFA: In the Entra admin center under the user’s Authentication methods, require the user to re-register their MFA methods or reset them. Remove any suspicious or unknown MFA methods (phone numbers, authenticator registrations, etc.). Delete old app passwords. This ensures the attacker can’t use a previously registered phone or token.
• Revoke PRTs and devices: If the attacker created a new device in Azure AD (likely to get a Primary Refresh Token), remove it. In Entra ID, check Devices > Registered devices for any unfamiliar device belonging to the user, and Remove it. Primary Refresh Tokens (PRTs) allow silent renewals; removing the device and revoking sessions wipes out that persistence.
• Remove administrator roles (if any): If the compromised account had any elevated permissions, immediately remove them. (Attackers often avoid using admin roles until later, but check Azure AD roles and Exchange admin roles just in case.)

At this point, the attacker’s access should be cut off or severely constrained. You may have to coordinate with other admins to ensure no residual access. Keep detailed notes on every action and timestamp for the incident log.

3. Investigation: What to Check

With initial containment done, conduct a systematic investigation of the account and tenant to understand the compromise. The investigation should cover the timeline of the attack and all possible persistence mechanisms.

3.1. Review Sign-in and Audit Logs

• Entra (Azure AD) Sign-in Logs: In the Microsoft Entra admin center, go to Monitoring > Sign-ins. Look for any unusual logins by that user, especially around the suspected compromise time (and a bit before). Key fields to examine are IP address, geographic location, time, and sign-in type (e.g. Interactive vs Non-interactive, Mobile vs Browser). Note any sign-ins from unfamiliar locations or impossible travel (e.g. Europe and then Asia 5 minutes later). Also check the Application column – if the login was via “AzureAD” or “Office365ExchangeOnline” vs a custom app. Specifically, a device code phishing will show two events: one for generating the device code (non-interactive), and one interactive login when the user enters it. An attacker stealing an existing session might show no new sign-in at all (they’d already have a valid token), which is harder to detect via sign-in logs.
• Microsoft 365 Audit Logs: The unified audit log in the Microsoft Purview (formerly Security & Compliance) portal captures a broad range of events across Exchange, SharePoint, Teams, etc. Search for activities by the user in question, especially in the timeframe of interest. Focus on events like UpdateInboxRules, Set-Mailbox, Add-MailboxPermission, Add-RecipientPermission, New-Mailbox/Remove-Mailbox, and Consent to an application. For example, if an attacker set up a hidden forwarding rule, the audit will record “Update-InboxRule”. You can use PowerShell:

powershellCopy# Search the audit log for mailbox rule or forward actions by this user
Search-UnifiedAuditLog -StartDate (Get-Date).AddHours(-4) -EndDate (Get-Date) -UserIds user@contoso.com -RecordType ExchangeAdmin,ExchangeItem,AzureActiveDirectory

• Then filter results for operations like Add-MailboxPermission, New-InboxRule, Update-InboxRule, Add-MailboxFolderPermission, Add-MailboxFolderPermission. Exchange Online will log mailbox rule changes in the audit log.
• Exchange (Mailbox) Audit Logs: If mailbox audit logging was enabled for the user, examine it for actions performed via Exchange (e.g. mailbox login by non-owner). The key events include MessageBind (where an external item is accessed), MailItemsAccessed, SoftDelete, and HardDelete. These require that mailbox auditing was turned on prior. If not, the unified audit log still captures many actions.

3.2. Inspect Email and Mailbox Settings

• Message Trace and Sent Items: Check the user’s Sent Items in Outlook or Outlook Web Access for any messages the user did not write. Also run a Message Trace (in Exchange Online or Defender portal) for the user during the incident window to see if any unusual messages (large volume, spam, or auto-forwarded mail) were sent. If the account has been on a spam blacklist (due to mass sending), it may appear in message trace logs and be listed on the Exchange Restricted Senders.
• Inbox Rules: Using Exchange PowerShell (or Graph), list all inbox rules for the mailbox, including hidden ones. For example:

powershellCopy# Check forwarding on mailbox
Get-Mailbox -Identity user@contoso.com | Format-List ForwardingSmtpAddress,ForwardingAddress,DeliverToMailboxAndForward
# Check all inbox rules (including hidden)
Get-InboxRule -Mailbox user@contoso.com -IncludeHidden | Format-List Name,Enabled,ForwardTo,RedirectTo,ForwardAsAttachmentTo

• Review any rule that automatically forwards or redirects mail, especially to external domains. Delete any suspicious or unknown rules. Attackers often use hidden rules to quietly exfiltrate mail or hide further phishing.
• Mailbox Permissions: Check if the user’s mailbox was granted SendAs, SendOnBehalf, or FullAccess to other users. Also check FolderPermissions. For example:

powershellCopyGet-MailboxPermission -Identity user@contoso.com | where {$_.User -notlike "NT AUTHORITY\SELF"}

• Remove any unexpected delegate or rights. An attacker could have added themselves or another account as a delegate to maintain access.
• Forwarding SMTP Address: Ensure no automatic external forwarding was configured on the mailbox (other than legitimate allowances). The Get-Mailbox command above shows if ForwardingSmtpAddress is set.
• Connected Devices: If the account is a mailbox for a user on mobile or M365 apps, check for any new devices. In Intune or Azure AD, list registered devices for this user (e.g. Get-AzureADDeviceRegisteredOwner). Remove any devices the user does not recognize.

3.3. Investigate Entra ID and OAuth

• New Application Consents: Check Azure AD’s Enterprise Applications or the audit log for OAuthConsentGrant or AppRoleAssignment events. If the attacker tricked the user into approving a malicious app, you’ll see a new service principal or delegated permission entry for that user. In Azure AD portal, under Users > (user) > Apps, look for anything suspicious. You can also run Graph:

powershellCopy# List granted OAuth2 permissions for the user
Connect-MgGraph -Scopes "User.Read.All","Application.Read.All"
Get-MgUserOAuth2PermissionGrant -UserId user@contoso.com

• Revoke any grants that shouldn’t be there (e.g. approvals for unknown apps).
• New Devices or Certificates: In Azure AD sign-in logs or the account’s Authentication Methods, look for any newly added FIDO keys, certificates, or phone numbers. Attackers may register a new MFA method to intercept OTP or to maintain access. Remove unrecognized methods (phone numbers, authenticator registrations) and enforce re-registration.
• Role and Group Changes: Confirm the user hasn’t been added to new privileged roles or groups. A quick audit: check Azure AD audit logs for Add member to role or Add user to group events for this user. Remove inappropriate assignments.

3.4. Correlate with Attack Indicators

When investigating, map each finding to how an attacker likely operated:

• Suspicious sign-in time/location + no token revocation: Suggests stolen credentials. The attacker simply logged in from afar. Look for a sequence like: normal user on VPN or office -> remote sign-in 10 minutes later.
• Device code login events: If you see the user completing a device code (AzureAD Device Login) and almost immediately an external session is granted, that matches a device-code phishing attack. The user’s actions will show one logon (the code entry) and the attacker’s session (the phishing site) will show another sign-in.
• High-volume email sent: If the account suddenly sent hundreds of emails, likely a mail forwarding or spam attempt. Check who the recipients were (from message trace). If many failed delivery attempts to external addresses, the attacker may have used the account for a spam blast.
• Malicious forwarding or rules: Automatic forwards to unfamiliar domains almost always indicate compromise.
• Concurrent sessions: If Azure AD shows two simultaneous sign-ins (from different IPs or devices) for the same user, that’s a red flag. The legitimate user and the attacker are both “logged in”. This often means the attacker got a refresh token or PRT and maintained a session while the user was legitimately signed in elsewhere.
• OAuth tokens or new apps: Unrecognized application names or new consent to an app suggests a token-theft scenario. Remove and audit those immediately.
• No signs in Entra logs but malicious mail still sent: The attacker might have had a valid session (e.g. PRT) that did not re-authenticate. In this case, check mailbox rules and audit logs; the attacker may have set up forwarding to steal mail without triggering a sign-in event.

4. Remediation: Removing the Attacker’s Access

Once you’ve identified what the attacker did, take actions to remove all malicious artifacts and lock down the account.

• Change the password and enforce strong MFA: Even if you reset it at the start, ensure the password is updated and strong. Enforce MFA on the account (preferably phishing-resistant methods like FIDO tokens or Microsoft Authenticator with passkeys). Avoid SMS/phone methods if possible. Require the user to register MFA on a clean device.
• Disable legacy protocols: Block any legacy authentication methods (POP/IMAP/SMTP AUTH, etc.) via Conditional Access, since those do not enforce modern MFA.
• Remove all suspicious mailbox rules and forwarding: Delete any auto-forwarding or redirect rules (using Remove-InboxRule in PowerShell if needed). For example:

powershellCopyGet-InboxRule -Mailbox user@contoso.com -IncludeHidden | 
  Where-Object {$_.ForwardTo -or $_.RedirectTo} | 
  Remove-InboxRule

• Revoke refresh tokens (again): If you initially revoked sessions, do it again after cleanup. You can call the Graph endpoint directly:

bashCopyPOST https://graph.microsoft.com/v1.0/users/{id}/revokeSignInSessions

• This specifically revokes refresh tokens (Azure AD v1/v2). Note: This does not always immediately sign the user out of all sessions (access tokens can remain valid for up to an hour). That’s why temporary account disabling is recommended.
• Remove malicious app consents: For any offending OAuth permissions, use Remove-MgOauth2PermissionGrant or the Azure portal. Confirm no lingering third-party apps have user-level permissions.
• Delete unauthorized devices: In Azure AD, go to Devices and delete any unexpected devices associated with the user. This removes any PRTs linked to those devices.
• Inspect and clean “Sent Items”: If the attacker sent phishing emails or commands (e.g. BEC), remove those from Sent Items and, if your org uses it, use Defender for Office 365’s Threat Explorer to automatically quarantine (Purview ZAP) any malicious outbound messages that were delivered.
• Check other accounts: If one account was compromised, search for similar suspicious activity on accounts that communicated with it during the incident (look for similar inbox rules on those accounts, or the same OAuth app being granted). Attackers sometimes compromise one account and move laterally via email forwarding chains.
• Reactivate account when safe: Only re-enable or unblock the account after you are confident the threat is neutralised and all remediation steps are complete. Make sure the user logs in from a trusted device, completes MFA, and verifies that things look normal.

5. Validation Before Restoring Access

Before you consider the incident fully resolved, perform sanity checks:

• Confirm no recent sign-ins: Ensure that no new suspicious sign-in events occurred after your last containment action. If using Azure AD risk policies, check that the user’s sign-in risk is no longer flagged.
• Review all findings: Double-check that every malicious inbox rule, forwarder, and app was removed. Test that email forwarding is truly off.
• User verification: Communicate with the user (via safe channels) to confirm there’s no ongoing unexpected behaviour (like lost emails, weird meeting invites, etc.). You may want them to log in and verify their Outlook, OneDrive, etc., in presence of IT.
• Enable re-authentication: Consider applying a Conditional Access policy that requires the user to re-authenticate (e.g. using MFA) on every login for a short period. This mitigates the case where an old access token might still be valid on some device.
• Document the incident: Record all actions taken, logs reviewed, and the outcomes. This documentation is critical for future response planning and for any compliance reporting.

6. Monitoring and Hardening (Post-Incident)

After restoring the account, strengthen your defences to deter a repeat incident:

• Enforce phishing-resistant MFA: Use hardware keys (FIDO2) or app-based MFA that resists man-in-the-middle. Avoid SMS or voice MFA. Microsoft explicitly recommends FIDO tokens or passkeys for admin accounts and high-value users.
• Conditional Access policies: Implement sign-in risk policies. For example, block or MFA-challenge any sign-in flagged as High Risk. Enable Continuous Access Evaluation (CAE) if available, so that token revocations happen in real time. Block legacy auth protocols through CA (they bypass MFA).
• Inbox rule alerts: Configure alerts or automated playbooks (via Microsoft Purview or SIEM) to notify on events like “New inbox rule created” or “External forwarder added.” Quick detection of a hidden rule is often the first sign of compromise. Microsoft recommends setting up monitoring for unexpected mailbox rule creation.
• Safe Attachments/Links: Use Defender for Office 365 Safe Links and Anti-Phishing policies to catch future phishing attempts. Safe Links will scan URLs and can trigger an alert if the same campaign tries again.
• Email hygiene: Deploy DMARC/SPF/DKIM on your domains to prevent easy email spoofing. While these don’t stop credential attacks, they reduce phishing success against your brand.
• Incident playbooks: Update your incident response plan with lessons learned. Include the specific steps above, and ensure tools like TRACE are tuned to detect unsolicited code-request emails or out-of-pattern multi-factor prompts.

7. TRACE Integration and Limitations

In practice, security often involves multiple layers. An email protection platform like TRACE can play a role in early detection of the phishing attack that led to compromise. For example, TRACE can flag an email with suspicious prompts (“you are being asked to enter a code”) or anomalous content indicating social engineering. It can correlate that with the user’s subsequent activities (e.g. the user “clicked a code” link) as a signal of compromise intent.

However, once the user is on the legitimate Microsoft login page and approves the sign-in, TRACE cannot undo that. The final authorization is performed by Microsoft’s identity system. Therefore, TRACE’s strength lies in alerting you to the malicious email and unusual sign-in prompt, giving your team a chance to intervene early. Actual removal of attacker access (revoking tokens, disabling accounts, etc.) must be done via Azure AD and Exchange controls, not by the email security layer.

In other words: email-layer tools detect malicious intent and phishing lures, whereas identity-layer controls (Azure AD, Entra ID) manage session tokens and re-authentication. Both are needed: TRACE to stop the initial phishing email from succeeding, and Azure AD controls to handle the fallout if it does.

8. First-Hour Response Checklist

Use this checklist as a quick reference for initial actions once an M365 compromise is suspected:

1. Incident Notification: Inform your IT security incident response team. If your org has a predefined incident handling process, activate it.
2. Identify Scope: Verify whether it's one account or multiple. Scan user activity for simultaneous similar attacks.
3. Contain: Immediately disable/block the user account in Entra ID. (For on-prem AD, also disable the AD account and reset password there.)
4. Reset Password: Force password change (twice if hybrid AD). Ensure future password resets are only done on a clean device.
5. Revoke Sessions/Tokens: Run Revoke-MgUserSignInSession -UserId <UPN> to invalidate refresh tokens. (Alternatively, in Entra admin center, use the “Revoke sessions” button).
6. Disable MFA Methods: Remove or reset all the user’s MFA methods (phone, app registrations). Require re-registration when safe.
7. Review Mailbox: Immediately inspect and disable any discovered forwarding or rules (using Get-Mailbox/Get-InboxRule).
8. Audit and Sign-in Logs: Pull sign-in and audit logs covering the past 1–2 hours (or since last known good state). Look for anomalies (new IPs, new devices, consent events).
9. Remove App Grants: Check for newly consented apps (Azure AD Enterprise Apps) and revoke suspicious ones.
10. Check Delegations: Verify no new delegates or "Send As/On Behalf" permissions were granted.
11. Secure Endpoint: If possible, isolate or wipe any device likely infected that the user may have used (especially if malware was involved).
12. Enable Security Measures: Apply a Conditional Access policy to require re-authentication for this user on all devices (if not already applied).
13. Communication: Inform the affected user and potentially impacted stakeholders that the issue is being addressed (preferably without details to avoid panic).
14. Document Everything: Log all timestamps, actions taken, and findings. This will help in post-incident analysis and compliance.

Completing these tasks quickly can significantly reduce attacker dwell time and data loss.

Final Thoughts

A compromised Microsoft 365 account is not the end of the world—but it is a serious security incident. The attacker now has the keys to your email and possibly your data. The most important lessons are: contain early, investigate thoroughly, and remove every backdoor. Modern phishing and account takeover techniques (like device‑code MFA bypass) are sophisticated, but the defenses are straightforward if applied properly: strong multifactor authentication, proactive monitoring of anomalies, and detailed logging for forensics.

Every unsolicited login prompt or forwarded email from a user should trigger suspicion. Combining email-layer intelligence (to catch the phishing in the first place) with robust identity protection (Conditional Access, token revocation, alerts on rule creation) forms a layered defence. If you follow the steps above – blocking the account, revoking tokens, and then cleaning up any malicious changes – you will break the attack chain before it can do lasting damage.

Remember: After solving the immediate problem, review and improve your security posture. Attackers will keep adapting, but a well-hardened identity infrastructure and vigilant security operations team will limit their success.

FAQ

What exactly counts as a "compromised Microsoft 365 account"?

+

An account is compromised when an unauthorized person or process gains access to it. This could be through stolen credentials (password or OTP), hijacked session tokens, malicious OAuth app consents, or misuse of existing sessions. It means the attacker can use that account as if they were the user. If there’s evidence (suspicious logins, mailbox rules, or emails) that someone else is controlling the account, treat it as compromised.

If a user’s Microsoft 365 account was hacked, is changing their password enough?

+

No. Changing the password (and enabling/resetting MFA) is essential, but it may not fully evict the attacker. The attacker might have a valid refresh token or PRT that remains active until revoked. You also need to revoke active sessions and tokens (e.g. using Revoke-MgUserSignInSession), and delete any new device registrations or OAuth consents the attacker put in place. Only after all malicious access paths are closed should you let the user log back in.

How can I tell if an account compromise attempt was successful?

+

Check both Azure AD sign-in logs and mailbox data. Successful compromises usually leave footprints: an unknown IP address in the sign-in logs, a new mailbox rule or forwarding address, or evidence of email sent by the user that they didn’t send. If the user fell for a phishing email with a device code, Azure AD will show a completed device-login flow for that user. Similarly, if a malicious OAuth app was granted, you'll see an “App consent” record.

Which logs should I check in Microsoft 365 for evidence of compromise?

+

Key sources are: Azure AD sign-in logs (via Microsoft Entra admin center) for login events, Microsoft 365 audit logs (via Purview/Security portal) for admin and mailbox activities, and Exchange mailbox audit logs for actions inside the mailbox. Also use Exchange’s Message Trace to see emails sent during the incident. Don’t forget to look at the user’s Sent Items and any alerts from Defender for Office 365.

What are malicious inbox rules and how do I detect them?

+

Malicious inbox rules are automatic email filters set by the attacker in the victim’s mailbox – for example, a rule that forwards all mail from a finance manager to the attacker. They can be hidden from the user by normal UI. Use PowerShell Get-InboxRule -IncludeHidden to list all rules for the mailbox and look for any that forward or redirect mail to external addresses. Any suspicious rule should be removed immediately.

After I reset the password, should I disable the account or keep it locked?

+

For maximum security, temporarily disable or block the account (uncheck Account enabled in Entra ID) until you’re sure the compromise is fully cleaned up. This forces all sessions to drop and ensures the attacker can’t use any remaining token (since token invalidation can lag up to an hour). There may be some business inconvenience, but it’s the safest way to ensure the attacker is really out. Once you’ve revoked tokens and cleared mailbox persistence.

How do I find out how the attacker got in (phishing vs brute force, etc.)?

+

Investigate the initial phishing email (if any) and the Azure AD sign-in logs. For example, if there’s a timestamp where the user entered credentials or a device code after a suspicious email, that suggests a phishing device-code attack. If the sign-in came from an IP/region the user never visits and no phishing was reported, it may have been a stolen password. Check if the account had weak credentials or if an OAuth app was involved.

What if the attacker has also used the compromised account to hack others (BEC or lateral movement)?

+

Consider this the beginning of a larger incident. Look at emails sent from the account: did the attacker send malicious requests to colleagues or customers? Search the audit logs for actions by those contacts around the same time. Also check if any shared resources (SharePoint, Teams) were accessed. If other accounts show similar signs (new inbox rules, unexpected logins), treat those as potential targets. You may need a broader incident response beyond the one account, including notifying affected parties.

Can Microsoft automatically recover a compromised account?

+

Microsoft provides tools to revoke sessions and disable accounts, but it won’t automatically fix compromise – that’s on your IT team. There is a “Sign-in sessions” revoke button in Entra ID (as above). For personal Microsoft accounts (Outlook.com) there’s a different recovery process, but for organizational M365 accounts, the response is in your hands. In case of an insider threat or advanced persistent attack, you might engage Microsoft support.

Is my organization liable if one of our accounts is compromised?

+

This is an operational, not legal, question – but generally, you have a duty to protect customer data and comply with regulations (GDPR, HIPAA, etc.). Promptly responding to a breach is often required by law. Use the incident documentation (logs, timelines) you collect as evidence of a timely and thorough response. If sensitive data was exposed, you may need to follow breach notification procedures.

More from the blog

• Security strategy How to Choose AI Email Security for Office 365 in 2026: What Microsoft's Own Guidance Says →
• Security strategy Twenty-Two Articles, Four Themes: What a Year of Writing About AI and Email Security Taught Me →
• Security strategy Your Employee Just Got a Sextortion Email. Is It a Security Incident? →

← All posts