How an OAuth app bypasses MFA: the Midnight Blizzard pattern

Your Conditional Access requires MFA, yet an attacker reads executive mailboxes with no login and no MFA prompt. The mechanism is an OAuth application, and it is the pattern behind the 2024 Midnight Blizzard intrusion.

Why MFA does not apply

Application permissions, such as the Exchange Online full_access_as_app permission, are granted to an application’s service principal, not to a user. The app authenticates as itself using the client-credentials flow. Because the token’s identity is the app and not a person, per-user MFA and most Conditional Access policies, which target users, never apply. A foothold that can create or consent an app escalates to tenant-wide mailbox access. In ATT&CK terms this maps to T1098.003 and T1528.

How the attack chains

The entry is usually mundane: a password spray on a legacy account that has no MFA. From there the attacker registers or consents a malicious OAuth app, grants it a high-privilege application permission, and uses the app-only token to read mail across the tenant.

How to detect it

Watch for admin consent to apps requesting high-privilege application permissions, and for service-principal sign-ins using client credentials with no interactive user. Both are unusual and high-signal.

How to contain and eradicate it

Disable the app’s service principal, revoke its tokens, and remove the consent grant. Resetting the entry account’s password does nothing, because the app authenticates as itself. Then audit all app credentials and consent grants, especially client secrets quietly added to existing apps, restrict who can register and consent to apps, require an admin-consent workflow, and enforce phishing-resistant MFA on every account, including legacy and test accounts.

Practice it

We built this exact scenario in GraphLattice Range, including the containment call that trips up teams who reset the user instead of the app.