Consent Phishing

Consent phishing (also called OAuth phishing or illicit consent grant) is an attack pattern where attackers trick users into granting OAuth permissions to a malicious application. The user clicks a link, sees a Microsoft sign-in page asking them to allow an app called something innocuous to "Read your mail, Read contacts, Send mail as you" — and clicks Accept. The attacker now has API-level access to the user's mailbox without needing the user's password or MFA at all. Mitigated by restricting user consent in Entra ID admin centre (users can consent only to low-risk permissions; the rest need admin consent), Defender for Cloud Apps alerting on suspicious OAuth grants, and user awareness training about consent prompts.

Why it defeats MFA entirely

Consent phishing's real danger is that it sidesteps the entire authentication story. A normal phishing attack still needs the victim's password (and, if MFA is enforced, a second factor too) to get into the account. Consent phishing never asks for either — it asks the user to grant a token to an app, and that token keeps working for as long as the grant stands, independent of the user's password, MFA method, or even a subsequent password reset. Changing a compromised password after a consent-phishing attack does nothing at all; the only fix is revoking the specific OAuth grant. This is exactly why the attack targets busy, click-through-quickly users rather than trying to guess or steal credentials — it's a faster and stealthier path to the same mailbox access.

Worked example

An employee receives an email that looks like a routine document-sharing notification. The link goes to a genuine Microsoft sign-in page — the domain really is Microsoft's own, which is what makes this attack so convincing — the user signs in normally, and is then shown a consent screen for an app named something like "Office Document Viewer" requesting mail-read, mail-send, and contacts-read permissions. The user, expecting to view a document, clicks Accept without reading the permission list. The attacker's app now holds a valid access token and refresh token scoped to that mailbox — it can read every email, harvest contacts for the next round of the attack, and send mail as the victim, all without ever touching the victim's password. Detection typically comes later, from Defender for Cloud Apps flagging an unfamiliar app with a suspicious permission combination, or from a colleague reporting a strange email that "came from" the victim.

Common pitfalls

The most common organisational failure is leaving user consent unrestricted tenant-wide, which lets any employee grant a malicious app broad mailbox access with a single click and no admin visibility until after the fact. The second is restricting consent but not building a fast admin-consent-request workflow for legitimate new apps — when the safe default is slow and painful, users find workarounds, or admins get consent-request fatigue and rubber-stamp requests without checking them. The third is treating this purely as a user-awareness problem: training reduces the click-through rate, but the actual control that stops the attack from mattering is restricted user consent plus routine review of granted app permissions in Entra ID — awareness training alone doesn't remove tokens already granted before the training happened.