Consent Phishing & Malicious OAuth Apps

Your organization has rolled out multi-factor authentication. Passwords are long, unique, and stored in a manager. By most measures, you have done the hard work of locking the front door. Consent phishing walks around the back — and it does not need your password or your MFA token to get in.

Instead of stealing credentials, this attack tricks a user into clicking “Accept” on a permission request from a malicious application. Once granted, the attacker holds a valid access token that lets them read mail, files, and contacts on the user's behalf. No password is captured, no MFA prompt is triggered, and — critically — the access survives a password reset. Microsoft has documented and warned about these illicit consent grants for years, yet they remain widely misunderstood.

How Consent Phishing Works

The attack abuses OAuth, the same delegated-access protocol that legitimately lets a calendar app read your schedule or a mail client send on your behalf. The flow is deceptively ordinary:

An attacker registers an application in Microsoft Entra ID (or another identity platform) and configures it to request permissions such as read your mail, read your files, or maintain access to data you have given it access to.
The victim receives a link — by email, chat, or a compromised website — that opens a genuine Microsoft consent screen for that app.
The screen looks routine, the way countless legitimate apps do. The user clicks Accept.
The app receives an OAuth token and immediately begins calling the Microsoft Graph API with the permissions just granted.

From that moment, the attacker can read and exfiltrate data using the token — entirely independent of the user's password.

Why MFA and Password Resets Don't Help

This is the part that catches even mature security teams off guard. The standard incident-response reflexes are largely useless here.

As Microsoft notes in its remediation guidance, normal steps such as resetting passwords or requiring MFA are not effective against illicit consent grants, because the malicious app holds its own delegated access and is external to the organization.

The user never re-authenticates, so MFA is never re-challenged. The token is tied to the granted consent, not to the password — so rotating credentials changes nothing. Until an administrator explicitly revokes the app's consent and tokens, the attacker keeps reading data. Microsoft's guidance on detecting and remediating illicit consent grants walks through exactly that revocation process.

How This Differs From AiTM and Supply-Chain Breaches

Consent phishing is often confused with two other token-centric attacks, but it is distinct:

Adversary-in-the-Middle (AiTM) attacks proxy a real login to steal the resulting session token. There, the user genuinely signs in — MFA and all — and the attacker hijacks the session afterward.
Supply-chain OAuth breaches, where a trusted third-party integration is compromised, abuse tokens that were granted legitimately to a real vendor app.

Consent phishing is the user knowingly approving a brand-new, attacker-controlled app. Different entry point, different fix — which is why a one-size-fits-all response falls short.

What a Real Attack Looks Like

Picture a finance manager who receives an email — or a Teams message — about a shared budget document. The link opens a page asking them to connect a “document viewer” app to their account so they can open the file. The page is hosted on a genuine Microsoft login domain, complete with the familiar branding and the company logo. All the manager has to do is click Accept.

Behind that single click, the app has requested permission to read the user's mail and files. The moment consent is granted, it begins pulling messages and documents through the Microsoft Graph API. There is no spoofed login page to catch, no credential to phish, and no MFA challenge to fail — the manager genuinely authorized the access. To most users, and to many security tools, nothing obviously malicious has happened. The data simply starts leaving.

Microsoft has tracked campaigns in which malicious OAuth applications were used to compromise mailboxes and abuse cloud email services, underlining that this is a real, operationalized technique rather than a hypothetical. Once an attacker controls a consented app, they can quietly read correspondence, hunt for sensitive attachments, or use the access as a launchpad for internal phishing — all while the user's password and MFA remain untouched and uncompromised.

What Users Should Watch For

Because the consent screen itself is legitimate, the warning signs are contextual rather than technical. Train employees to pause when an app requests access and ask:

Did I initiate this? A consent prompt that appears after clicking a link in an email or chat — rather than from an app you deliberately set out to install — is a red flag.
Is the publisher verified? Microsoft displays a verified-publisher badge for vetted developers. An unverified publisher requesting broad mailbox or file access deserves real suspicion.
Do the permissions make sense? A document-signing tool has no business requesting permission to read all your mail or maintain persistent access.
Is there pressure or a pretext? Lures often dress the prompt up as a required security upgrade, a shared document, or a new collaboration tool from a “colleague.”

The Admin Controls That Close the Gap

User vigilance matters, but the most effective defense is to remove the decision from end users entirely. Microsoft recommends restricting user consent so the risky calls are made centrally.

Restrict user consent. In Entra ID, configure user consent settings so that users can consent only to apps from verified publishers for low-impact permissions — or block self-service consent altogether for higher-risk scopes.
Enable the admin consent workflow. Pair restrictions with a request queue so users can ask for an app and reviewers can evaluate the permissions, rather than simply hitting a dead end. Microsoft advises designating at least two reviewers.
Audit existing grants. Periodically review the permissions granted to enterprise applications and revoke anything unrecognized, over-permissioned, or no longer in use.
Monitor for anomalous app activity and alert on newly consented apps that immediately begin bulk-reading mail or files.

Where Awareness Training Fits

Restricting consent shrinks the attack surface, but users still encounter consent prompts for legitimately approved apps — so the instinct to scrutinize them has to be trained. A program like empowsec lets you teach employees to treat an unexpected “this app is requesting access” prompt with the same caution as a login page, and to report it rather than reflexively clicking Accept. Combined with simulations that build the habit of questioning unsolicited prompts, awareness training turns the human step in the OAuth flow from the weakest link into a checkpoint.

Key Takeaways

Consent phishing sidesteps the controls most organizations rely on most. Defending against it takes a combination of administrative lockdown and trained users:

Consent phishing grants token-based access to mail and files without a password and without triggering MFA.
Password resets and MFA do not remediate it — only revoking the app's consent and tokens does.
Restrict user consent and enable the admin consent workflow so risky approvals are centralized.
Regularly audit and revoke OAuth app permissions across your tenant.
Train employees to scrutinize permission prompts — unexpected access requests are a red flag worth reporting.