The attacker doesn't steal a password. They trick the user into granting permissions to a malicious application. "Sign in with Microsoft" — the user clicks approve, and now the attacker's app has a refresh token with persistent access to their mail, files, and calendar until revoked.

No password compromised. MFA was satisfied by the legitimate user. Conditional Access passed because the user authenticated normally. The malicious action happens at the consent layer — above authentication — where none of these controls apply.

The app now reads mail via Graph API. No interactive sign-in anomalies. No anomalous location. The non-interactive and service principal sign-in logs show token activity, but most SOCs never scrutinise them — and even when they do, the API calls are structurally identical to legitimate application behaviour.

Default M365 detections don't catch this reliably. Microsoft has added some — Defender for Cloud Apps flags unusual OAuth credential additions and suspicious mail access — but they're inconsistent, often delayed, and miss consent grants to newly registered external apps without a risk profile.

You need to monitor application consent grants in Entra ID audit logs ("Consent to application" under ApplicationManagement) and alert on any app requesting Mail.Read, Files.ReadWrite, User.Read.All, or offline_access from a non-approved publisher. Better still, disable user consent entirely in Entra ID and enforce an admin consent workflow — shifting the attack surface from "any user can be phished" to "only admins can approve apps."

This is the gap between "we have MFA" and "we have security."

Sharing a detection I built after investigating multiple AiTM compromises. The default Sentinel "suspicious inbox manipulation" template is noisy, and most environments disable it. Here's what I run instead:

High-fidelity query (external forwarding + financial keywords):

OfficeActivity | where TimeGenerated > ago(30d) | where Operation in ("New-InboxRule", "Set-InboxRule") | where Parameters has_any ("ForwardTo", "RedirectTo", "DeleteMessage", "MoveToFolder") | extend RuleDetails = tostring(Parameters) | where RuleDetails has_any ( "gmail", "protonmail", "outlook.com", "yahoo", "tutanota", "pm.me", "RSS Subscriptions", "Conversation History", "invoice", "payment", "wire", "security", "password", "MFA") | project TimeGenerated, UserId, Operation, RuleDetails, ClientIP | sort by TimeGenerated desc 

Broad audit query (all rule operations for manual review):

OfficeActivity | where TimeGenerated > ago(30d) | where Operation in ("New-InboxRule", "Set-InboxRule") | project TimeGenerated, UserId, Operation, Parameters, ClientIP | sort by TimeGenerated desc 

What I look for in results:

• ForwardTo or RedirectTo pointing to any external domain
• MoveToFolder targeting RSS Subscriptions, Conversation History, or Junk
• DeleteMessage with keyword filters on "security", "password", "sign-in", "MFA"
• Rule names that are blank, single character, or "..."
• ClientIP outside your corporate range (strongest single indicator)

Tuning notes from production:

The high-fidelity query fires maybe 1-2 times per month in a ~800-user environment. Most hits are legitimate (someone forwarding to a personal backup). The false-positive check: correlate the ClientIP with SigninLogs — if the same IP has a risky sign-in for the same user within the preceding 24 hours, it's a true positive.

The broad query returns 10-30 results per month. I review these weekly as a hunt activity. Most are legitimate rules. The value is catching the patterns the high-fidelity query doesn't match — like rules that forward to a newly registered domain that isn't in the keyword list.

Important context:

In AiTM compromises, the inbox rule is one of 3-4 persistence mechanisms created within minutes. The attacker also registers a new MFA method and consents to an OAuth app. If you detect the rule, check AuditLogs for the same user:

AuditLogs | where TimeGenerated > ago(24h) | where InitiatedBy has "<compromised user UPN>" | where OperationName in ("Consent to application", "Update user", "Add-MailboxPermission") | project TimeGenerated, OperationName, TargetResources, AdditionalDetails 

If you see MFA registration, OAuth consent, and an inbox rule from the same user in the same hour, that's a confirmed AiTM compromise — not a coincidence.

I'm happy to share more queries from the same investigation if it's helpful.