OAuth consent phishing is the M365 attack path most orgs aren't watching.
The attacker doesn't steal a password. They get the user to grant 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."
Start here:
training.ridgelinecyber.com/…