Microsoft 365 Tenant Compromise Playbook: Evict Attackers From Exchange, SharePoint and Teams

Resetting a password does not evict an attacker from Microsoft 365: inbox rules, forwarding, mailbox delegates, sharing links, app passwords and consented apps all keep working until someone removes them. Once sign-in is back under control, the real work is in the workloads: finding what the attacker read, sent, shared and planted in Exchange Online, SharePoint, OneDrive and Teams, mostly through the unified audit log. This playbook covers how a workload compromise shows up, triage questions, containment in priority order, eradication across each workload, recovery, evidence to preserve and notification triggers. It is written for Microsoft 365 administrators, SOC analysts and incident responders. Sign-in, Conditional Access and the Entra ID control plane are covered in the Identity Provider Tenant Compromise Playbook; run that in parallel if the tenant's identity layer is affected.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public Microsoft 365 documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Revoke sessions, not just passwords. Disable the account or reset the password, then revoke sign-in sessions and refresh tokens; Microsoft notes app passwords survive a reset and must be deleted.
• Hidden inbox rules are the classic persistence. Check every mailbox in scope with hidden rules included, plus SMTP forwarding and delegate permissions.
• Know your audit retention. Audit (Standard) keeps records 180 days for logs generated since 17 October 2023; Audit (Premium) keeps Exchange, SharePoint, OneDrive and Entra records a year for E5 users. Export before the clock runs out.
• Scope mail exposure with MailItemsAccessed. Sync events mean assume the whole folder was taken; bind events identify individual messages by InternetMessageId.
• Apps outlive users. A consented OAuth app or an app with new credentials keeps access after every user is cleaned up, so app review is part of every tenant compromise.

How the incident shows up

Microsoft lists common symptoms of a compromised mailbox, and the same audit data shows workload abuse elsewhere in the tenant.

See the Microsoft 365 Unified Audit Log Guide for Detection for building alerts on these operations.

Triage questions

1. Which accounts are affected? Start from the first alert, then widen through shared IPs, client strings and session IDs in sign-in and audit logs.
2. Is the identity layer still compromised? Are there unknown MFA methods, new admin role holders or Conditional Access changes? If yes, the identity playbook leads and workload clean up follows.
3. What is the audit window? Which audit tier and licences apply, and how far back do records go for the affected users?
4. What mail was read or sent? Use MailItemsAccessed and Send to scope it; for sync events in the attacker's context, assume the whole mailbox was synced.
5. What files were taken or shared? Which sites and OneDrives did the accounts reach, and were sharing links created to outside parties?
6. Were apps involved? Did users or admins consent to new apps, or did existing apps get new secrets or permissions?
7. Was there fraud? Did the attacker change payment details in conversations? If so, run the Business Email Compromise Response Playbook alongside.

Scoping mail exposure with MailItemsAccessed

MailItemsAccessed is part of Audit (Standard) and is on by default for users with Office 365 or Microsoft 365 E3 or E5 licences. It covers POP, IMAP, MAPI, EWS, Exchange ActiveSync and REST access, and records two kinds of access that need different handling.

Separate attacker activity from the real user by comparing ClientIPAddress, ClientInfoString and SessionId. Microsoft notes that duplicate records within one hour are filtered unless one of those context fields differs, and that mail synced to a client and read offline leaves no further audit trail, so sync scoping is deliberately pessimistic.

Containment priorities

1. Disable or reset: Microsoft's preferred first step is disabling the account (Update-MgUser -UserId $user.Id -AccountEnabled $false); otherwise reset the password, without emailing it to the user. For accounts synced from Active Directory, reset twice in AD; for federated identities, reset on-premises.
2. Revoke sessions: run Revoke-MgUserSignInSession to invalidate active sessions and refresh tokens. Delete app passwords, which a reset does not revoke.
3. Remove rogue MFA methods and admin roles: remove authentication methods the user does not recognise, and any admin roles the account should not hold.
4. Stop mail exfiltration: clear SMTP forwarding (ForwardingSmtpAddress) and disable or remove suspicious inbox rules found with Get-InboxRule -Mailbox <Identity> -IncludeHidden, checking RedirectTo, ForwardTo and ForwardAsAttachmentTo. Remove delegate permissions the owner did not grant.
5. Disable suspect apps: Microsoft advises disabling a suspect app's service principal (setting accountEnabled to false) before deleting it or rolling its keys, to allow time to assess impact.
6. Cut external sharing: remove anonymous and external sharing links created by the compromised accounts during the window, and restrict external sharing on affected sites while the investigation runs.
7. Contain Teams spread: tell users who received links from the account, delete malicious messages, and tighten external access settings in the Teams admin centre if the attacker used external chat.

Eradication

Exchange Online

• Sweep every mailbox in the tenant, not just the known victims, for rules forwarding externally and mailbox level forwarding; attackers often plant the same rule on several accounts.
• Review mailbox permissions, Send As and Send on Behalf grants, and remove those without a business owner.
• Check signatures and contact details in the Global Address List, which Microsoft lists among the symptoms of compromise.
• Purge phishing mail sent internally from recipients' mailboxes.

SharePoint and OneDrive

• List files downloaded, synced and shared by the accounts in the window; remove sharing links and external guests added.
• Check for uploaded malicious files or modified documents used to phish others, and restore earlier versions.

Teams

• Remove external guests and members added to teams during the incident; review apps and connectors added to teams and chats.
• Find chats and channel posts the compromised account sent during the window, and delete those carrying malicious links or files; files shared in Teams live in SharePoint and OneDrive, so clean their sharing links there too.
• Review guest access and external access settings against what the business needs, and document any temporary restriction so it is lifted deliberately after recovery.

Where identity fits

Workload clean up depends on non-human identities as much as on users. Shared mailboxes, service accounts used by scanners and line-of-business apps, and app registrations with Mail.Read or Files.Read.All application permissions can all read data without a user signing in. Treat each one as in scope: confirm its owner, rotate its credentials if the attacker could reach them, and remove permissions it does not need. See the OAuth Token Theft Incident Playbook for token-based app abuse.

Applications

• Review consent grants in the Entra audit log (activity Consent to application) and filter for non-admin consents, as Microsoft's compromised app playbook shows.
• For an app you keep, roll credentials: add a new certificate, then remove old secrets and keys from both the application and its service principals. Rotate Key Vault secrets the app could reach, starting with those it actually read.
• For malicious apps, delete them (soft deleted items stay recoverable for 30 days) and watch for re-enablement events (Update Service Principal with account enabled true, or Add Service Principal).
• Restrict user consent and turn on the admin consent workflow. See How to review Microsoft 365 app registrations with mail permissions.

Recovery

1. Re-enable accounts after the investigation with new credentials and enforced MFA, phishing-resistant for administrators.
2. Remove users from the Restricted entities page in the Defender portal if outbound sending was blocked.
3. Restore deleted mail and files from recycle bins, versions or backups.
4. Set alerts for new forwarding rules, external forwarding, mass downloads and new app consents.
5. Review licences for audit coverage: extend retention for high value users if records aged out during the investigation.

Measures that show the clean up held: forwarding rules to external domains (target zero without approval), apps with user consent and no owner, time from detection to session revocation, mailboxes with MailItemsAccessed available, and recurrence within 30 days.

Decision points

• Single mailbox, short window: clean the account, sweep rules tenant wide, notify recipients of any phishing sent.
• Several accounts or an admin: treat as tenant compromise, run the identity playbook first, and assume app persistence until proven otherwise.
• Small organisations: Microsoft's Run Tests: Compromised Accounts diagnostic helps identify suspicious activity when no SOC is available.

Evidence to preserve

Retention decides what survives: Audit (Standard) records generated since 17 October 2023 are kept 180 days, and Audit (Premium) keeps Exchange, SharePoint, OneDrive and Entra records for one year for E5-licensed users. Export to storage you control, with hashes and chain of custody (NIST SP 800-53 AU-9 and AU-11).

Notification triggers

• GDPR and UK GDPR: report a personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless it is unlikely to result in a risk to individuals (Article 33), and tell individuals where risk is high (Article 34). Mailbox access usually exposes personal data of third parties.
• NIS2: in-scope entities give an early warning within 24 hours and an incident notification within 72 hours for significant incidents (Article 23, national transposition).
• Sector rules: Microsoft's MailItemsAccessed guidance gives the example of checking accessed messages for PHI in HIPAA-regulated organisations.
• Recipients of phishing: customers and partners who received mail from a compromised account should be warned promptly, even where law does not require it.

See the Breach Notification Laws by Country Guide.

Common failure patterns

• Stopping at the password reset: refresh tokens, app passwords, rules and delegates all survive it; session revocation and the workload sweep are what evict the attacker.
• Checking only visible rules: rules created through some interfaces do not show in Outlook; always query with -IncludeHidden.
• Cleaning one mailbox: the attacker used the first account to phish colleagues; sweep the tenant for the same rule names, forwarding targets and sign-in IPs.
• Filtering the first audit search: Microsoft advises searching without an activity filter first, so unexpected operations are not missed.
• Deleting the app first: deleting or rolling keys before disabling loses the chance to see what breaks and can destroy evidence; disable, assess, then remove.
• Letting retention run out: slow investigations lose the start of the timeline; export audit data on day one.

Framework mapping

Practitioner checklist

• Audit is on and retention for key users covers your typical detection delay.
• MailItemsAccessed is available for mailboxes that hold sensitive data.
• Alerts fire on new external forwarding, hidden rules and mass downloads.
• The runbook includes disable, password reset, session revocation and app password removal, in that order.
• A tenant wide sweep script for inbox rules and forwarding is tested and ready.
• User consent is restricted and the admin consent workflow is on.
• Every enterprise app has an owner.
• Responders know how to remove users from Restricted entities and restore deleted items.
• Communication templates exist for phishing recipients and regulators.

Standards and references

• Microsoft Learn: Responding to a compromised email account
• Microsoft Learn: Compromised and malicious applications investigation
• Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
• Microsoft Learn: Manage audit log retention policies
• Microsoft Learn: Audit log activities
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Identity Provider Tenant Compromise Playbook, Microsoft 365 Unified Audit Log Guide for Detection, OAuth Token Theft Incident Playbook, Microsoft 365 Security Checklist.