← All field notes
entra idoauthconsentpersistence

The app you approved is reading your mail

Consent phishing skips your password entirely. The victim clicks Accept on a real Microsoft consent screen, and a malicious app gets standing access to their mailbox and files. Here is the grant, and the fix.

Attack flow
1Send a consent-phishing link
2Victim approves on the real Microsoft consent screen
3App is granted mail/files scopes
4App reads data as itself
5Persistent access
Seen in the wildMidnight Blizzard (APT29)Consent-phishing crews

The victim never typed a password into a fake page. They clicked Accept on a real one.

What it is

In a consent-phishing (illicit consent grant) attack, the victim is lured to a legitimate Microsoft consent screen for an attacker-registered OAuth app requesting permissions like Mail.Read or Files.Read. When they click Accept, the app receives a token and standing access to their data, with no password captured. This is T1528 (steal application access token) with T1566 (phishing).

Why it works

There is no password to steal and no MFA to fail, because the user genuinely authorizes the app. The access survives password resets, because it is the app’s grant, not a session.

How to detect it

In the Entra audit log, look for new OAuth app consents, especially to unverified publishers requesting mail or file scopes, and apps reading data shortly after consent.

The fix that holds

Restrict user consent with an admin approval workflow, allow only verified publishers, and alert on risky consents. Review app grants regularly, and during response revoke both the grant and the app’s tokens, not just the user’s session.

Practice it

We built an illicit consent grant scenario in GraphLattice Range so teams learn why a click can be standing access, and how to clear it.