Microsoft 365 Audit Log Alerts: 7 Patterns Every Admin Should Watch
Microsoft 365 audit logs are an underused goldmine for catching account compromise early. This guide covers seven specific patterns to alert on, what they actually look like in the logs, the false-positive rate to expect, and how to respond when one fires.
Where these logs come from
The Office 365 Management Activity API exposes four content types worth ingesting:
Audit.AzureActiveDirectory— sign-ins, MFA events, role changes, app consentsAudit.Exchange— mailbox operations, mail-flow rules, forwardingAudit.SharePoint— file access, sharing, permission changesAudit.General— everything else (Teams, Power Platform, etc.)
You can poll these directly with a registered Azure app + the right Graph permissions, or use a SIEM that handles the polling/parsing for you. Either way, the alerts below are the patterns worth watching.
The 7 patterns
1. External mail forwarding configured Critical
The classic account-compromise indicator. An attacker who gets into a mailbox immediately sets up forwarding to an external address so they keep seeing email even after the password gets reset.
Operation to match: Set-Mailbox with ForwardingAddress, ForwardingSmtpAddress, or DeliverToMailboxAndForward in the parameters. Also New-InboxRule / Set-InboxRule with redirect or forward actions.
What to ignore: Set-MailboxCalendarConfiguration, Set-MailboxRegionalConfiguration, and other Set-Mailbox*Configuration cmdlets — these are routine user preferences and substring-match against "Set-Mailbox" but aren't security-relevant.
False positive rate: Low if you exclude the configuration cmdlets. Genuine: legitimate auto-forwarding setups (rare in 2026 — most orgs disable this org-wide).
Response: Investigate immediately. Check sign-in history for the user, force MFA re-enrollment, review what was forwarded.
2. OAuth application consent granted High
Phishing campaigns increasingly skip password theft and instead trick users into authorizing a malicious OAuth app with Mail.Read or Files.Read permissions. The app then exfiltrates everything via Graph API — no password ever needed.
Operation to match: Audit log entry containing Consent to application. Look for the AppDisplayName field.
What to ignore: Substring matches on "consent" or "oauth" alone — there's noise in the M365 logs that triggers on those words. Match the literal "Consent to application" operation.
De-dup: By AppDisplayName — one alert per app per N days. A legitimate app install fires once; you don't need a re-alert every time it re-uses its scope.
Response: Look up the AppDisplayName on Microsoft's published apps. Cross-reference with your team — was this approved? If not, revoke from https://entra.microsoft.com → Enterprise Applications → app name → delete.
3. Sign-in from impossible-travel location High
User signs in from New York at 3pm and from Lagos at 3:15pm. Either they have a teleporter or one of those sign-ins is hijacked.
Operation to match: Successful sign-in events for the same UPN with locations more than ~500km apart within a window the human couldn't physically travel.
What to ignore: VPN exits — many users connect through corporate VPN endpoints that geolocate inconsistently. Maintain an allowlist of known VPN exit IPs.
False positive rate: Medium without VPN allowlists, low with them.
Response: Force password reset + MFA re-enrollment. Review what the session accessed.
4. Brute-force or credential-stuffing attempts High
Multiple failed sign-ins for the same user from the same IP, OR for many different users from one IP, indicate a brute-force or credential-stuffing campaign.
Operation to match: UserLoginFailed events. Threshold: 5+ failures in 10 minutes from one source IP. Or 10+ failures spread across 5+ unique users from one IP (credential stuffing).
De-dup: Per-source-IP for 1 hour. One alert per attacker.
Response: Block the source IP at your firewall (or via Conditional Access if you have it). Review whether any of the targeted accounts succeeded subsequently — if so, treat as compromised.
5. Transport rule (mail-flow rule) created or modified High
Org-wide mail-flow rules are a powerful tool — they're also a powerful attacker tool. A rule that BCCs all outbound mail to an external address gives an attacker continuous exfil even if they lose mailbox access.
Operation to match: New-TransportRule or Set-TransportRule in Audit.Exchange.
False positive rate: Low. Transport rules don't change often in healthy orgs.
Response: Review every rule modification. Confirm it was authorized. If not, disable + investigate the actor account.
6. Mailbox permission granted to another user High
An attacker who controls one account can grant themselves access to another user's mailbox via Add-MailboxPermission. This persists even after the original compromise is detected and remediated, so it's worth catching.
Operation to match: Add-MailboxPermission. Check the User and AccessRights parameters — FullAccess is the dangerous one.
What to ignore: Set-MailboxFolderPermission for individual folder shares — those are routine user actions for delegating calendars, etc.
Response: Confirm the permission grant was authorized (helpdesk ticket, manager approval). If not, revoke and investigate.
7. Global Admin role assigned Critical
Adding a user to the Global Administrator role gives them keys to the kingdom. Every G.A. assignment should be a deliberate, documented decision.
Operation to match: Role assignment events in Audit.AzureActiveDirectory where the role name is "Global Administrator", "Privileged Role Administrator", or "Exchange Administrator".
De-dup: Per-role-per-user. Don't suppress duplicates within a short window — every assignment is its own event worth confirming.
Response: Confirm the addition was authorized. If not, remove + audit what the user did while privileged. Microsoft recommends fewer than 5 Global Admins org-wide — assignments above that threshold should auto-page security regardless of who made them.
Three patterns that sound useful but generate too much noise
For completeness, here's what NOT to alert on — these come up in every "M365 monitoring guide" but in practice produce more noise than signal:
- "After-hours logins" alone — remote work is normal in 2026. Only alert if the IP is also external and unfamiliar.
- "User accessed many mail items" — most users do this when triaging email. Without baseline anomaly detection, you'll alert on every busy Monday.
- "File downloaded from SharePoint" — same problem. Useful in a forensic investigation, not as a real-time alert.
How to wire this up
Two paths:
- DIY: Register an Azure app with
ActivityFeed.Read+ActivityFeed.ReadDlp+ServiceHealth.Readpermissions. Poll the Management Activity API every 5 minutes, fetch content blobs, parse against the patterns above. Plan on ~2 weeks of engineering plus ongoing rule maintenance. - Use a SIEM: Most modern SIEMs include M365 connectors. StatusCore ships with all 7 patterns above as built-in rules and adds the M365 XDR response actions (disable user, revoke sessions) directly from each alert. Setup takes about 10 minutes — you create an Azure app registration and paste the tenant ID + client ID + secret into the dashboard. Free trial.
Quick recap
- Watch
Set-Mailboxwith forwarding parameters + InboxRule operations — but skip the benignSet-Mailbox*Configurationcmdlets - "Consent to application" is the OAuth abuse signal — dedupe by app name
- Brute-force = 5+ failures from one IP in 10 min. Credential-stuffing = 10+ failures across 5+ users.
- Transport rules + mailbox permissions + Global Admin assignments are all low-volume, high-importance — alert on every change
- Don't alert on after-hours logins from internal IPs or "user opened lots of email" — too noisy
Want all 7 patterns + 130 more, prebuilt?
StatusCore ships with M365 connectors and these detection rules out of the box. Free trial, no credit card.
Start Your Free Trial →Related reading: All-in-one SIEM + monitoring · How to monitor SIP trunks · StatusCore vs Blumira