What is consent phishing (OAuth phishing)?

Key takeaways

• Consent phishing routes around MFA by design: the attacker never logs in, the user does, and MFA fires for the legitimate user.
• The foothold is a refresh token, not a password. Resetting the password and rotating MFA does not revoke the grant.
• Standard email security tools rarely catch consent phishing because the lure links to a legitimate identity-provider URL.
• Mid-market manufacturers using Microsoft 365 or Google Workspace are exposed by default; admin consent policies and app governance are usually permissive.
• Defense is OAuth governance and continuous detection on grant events, not user training alone.

How does an OAuth consent phishing attack bypass MFA?

Most authentication-focused defenses assume the attacker needs to obtain credentials and answer MFA. Consent phishing changes the assumption. The attack flow:

1. The attacker registers an OAuth application against the target's identity provider (Microsoft Entra, Google, Okta).
2. The app is configured to request scopes that give the attacker the access they want (mailbox read/write, files, contacts).
3. The attacker sends a lure to the target with a link that initiates an OAuth consent flow.
4. The target clicks the link. The target sees their own identity provider's URL (login.microsoftonline.com, accounts.google.com). Trust signals are correct.
5. The target authenticates. MFA fires for the legitimate user. The target approves.
6. The consent screen appears, asking the target to grant the app the requested scopes.
7. The target approves. A refresh token is issued to the attacker's app, scoped to the user.
8. The attacker now has persistent, password-independent access to whatever the scopes allow.

The trust signals are all correct from the user's perspective: their own identity provider, their own credentials, their own MFA prompt. The error is at the consent step, which is the one step most users do not have a mental model for.

The attack is structurally invisible to most email security tools because the lure link points to a legitimate identity provider URL. There is no malicious domain to block, no credential prompt on a forged page, no malware payload to detonate in a sandbox.

The Microsoft 365 attack flow step by step

The most common environment ARG sees this attack succeed against is Microsoft 365 in mid-market tenants. The full flow:

1. App registration. The attacker registers a multi-tenant Entra app with a benign-looking name ("Document Review Pro", "Project Sync Tool", "Mail Backup"). Multi-tenant registration is on by default; any user from any tenant can grant consent.

2. Scope configuration. Scopes set to a combination of high-value reads and offline_access: Mail.Read, Mail.ReadWrite, Files.Read.All, Contacts.Read, offline_access. Some attackers also request Mail.Send to enable internal pivot.

3. Lure delivery. A spear phish sent from a credible sender, with a pretext that justifies granting an app permission. Common pretexts: "Sign in to view the shared document", "Authorize the new tool your team is rolling out", "Confirm migration access by signing in here", "Review and approve the IT integration for [vendor]". Multi-channel variants pair the email with a confirming vishing call or SMS.

4. Consent flow. Target clicks. Microsoft login page renders. Target authenticates with MFA. Consent screen lists the permissions; the screen design is the same whether the app is benign or malicious. Target approves.

5. Token issuance. The app receives a refresh token. Microsoft sets the token lifetime per tenant policy; default is long.

6. Exploitation. The attacker pulls the mailbox, sets a forwarding rule, exfiltrates contacts and files, and (where Mail.Send is granted) sends internal pretexts from the compromised mailbox. Onward attacks (BEC, lateral phishing) follow.

7. Persistence. The grant survives password changes, MFA resets, and even some forms of account suspension. Only an explicit revocation of the consent through Entra removes the access.

The defending team often does not know the grant happened. The lure was not blocked by email security. The login was successful and MFA was satisfied. No detection rule fired unless the tenant has explicit OAuth-grant monitoring.

Why standard email security tools miss consent phishing

Three structural reasons:

1. The lure link points to a legitimate URL. Microsoft, Google, Okta. There is no malicious domain to flag.
2. The payload is a configuration change, not a credential or executable. Sandbox detonation does not produce a malicious indicator; the consent flow is the same regardless of which app is being authorized.
3. The post-attack behavior runs on legitimate APIs. Mailbox reads through Microsoft Graph look identical to a legitimate productivity app. Without baseline behavior modeling, the activity is invisible.

The attack is structurally adversarial to email-gateway-centric defense. The right detections live in the identity layer (Entra audit logs, Microsoft Graph activity, anomalous app behavior, OAuth grant events), not in the email gateway.

Examples of consent phishing campaigns in 2024 and 2025

What ARG and the broader industry have seen at scale:

• "Microsoft Mail Backup" multi-tenant app campaigns. Recurring waves of lures impersonating IT or compliance teams, requesting users authorize an app with broad mailbox scopes. Reaches Microsoft 365 tenants without any malicious domain ever being touched.
• OAuth grants impersonating SaaS vendors during procurement cycles. A pretext that the company is rolling out a new tool (DocuSign, Workday, Jira, Salesforce integration) requesting the user authorize "to test access". The naming conventions are tuned to current procurement language.
• "M&A diligence portal" pretexts during deal windows. During acquisition activity (visible from press releases, SEC filings, or competitor signals), pretexts ask executives and finance to authorize a "diligence portal" app for "secure document exchange".
• AI-tool pretexts. "Authorize Copilot for [Team]" or "Authorize the new AI assistant for finance". The pretext rides on legitimate roll-outs of AI tooling that mid-market manufacturers are actively considering.
• "Microsoft 365 quarantine release" lures. Pretext that a quarantined message can be released by authorizing a quarantine app. The pretext loops back through legitimate Microsoft URLs in a way that defeats user pattern-matching.

The named campaigns rotate; the structure does not. The lesson is that the defense is OAuth governance, not lure-pattern detection.

How to detect rogue OAuth grants in a tenant

For Microsoft 365 tenants, four detection sources matter:

1. Microsoft Entra audit log: Consent to application events. Filter for new grants, especially multi-tenant apps with high-value scopes (Mail.*, Files.*, offline_access). Alert on grants outside the admin-consent allowlist.
2. Microsoft 365 Defender: Suspicious OAuth app alerts. Built-in alerts for known-bad patterns. Useful as a floor; not sufficient on its own.
3. Microsoft Graph API activity anomalies. Apps reading mailbox content at unusual volumes, from unusual IPs, or outside business hours. Behavioral baselining catches campaigns the Defender ruleset misses.
4. Periodic OAuth grant audits. Quarterly review of all enterprise apps with high-value scopes against an approved list. Users almost always have grants they do not remember authorizing; the audit surfaces them.

For Google Workspace tenants, equivalent detections live in the Admin console (Security > API Controls > App access control) and in BigQuery exports of Workspace audit logs.

A consent-phishing-aware detection program reports each new grant to the security team for triage, not just the ones flagged as obviously suspicious. The default posture is verify-on-grant, not investigate-on-alert.

Best practices for app consent governance in Microsoft 365 and Google Workspace

1. Restrict user consent to high-scope grants. In Entra, set the user consent policy to "Allow user consent for apps from verified publishers, for selected permissions" or stricter. High-scope grants require admin consent. Same model in Google Workspace via API access control.
2. Maintain an admin-consent allowlist. Approved apps are explicitly added; everything else requires admin review. The list is small; the friction is the point.
3. Continuous monitoring on consent events. Each new grant produces a ticket for security review, with the requesting user, the app, and the scopes. Triage takes minutes; the cost is small relative to the loss prevention.
4. Quarterly OAuth audit. Review all enterprise apps in the tenant against the allowlist. Revoke anything that does not belong, with user notification and explanation.
5. Phishing-resistant authentication for everyone. FIDO2 and passkeys reduce credential exposure overall and surface anomalous flows in identity logs. See What is phishing-resistant MFA?.
6. Continuous simulation that includes OAuth-grant pretexts. Most adaptive simulation programs run phishing simulation and vishing but skip OAuth. OAuth pretexts should run on the same cadence and feed the same outcome backlog.
7. Incident response playbook for OAuth compromise. Revoke grant, force reauthentication, rotate any tokens issued during the window, audit mailbox rules and forwarding policies, audit Graph activity from the grant window. See What is an incident response plan (IRP)?.

Consent phishing FAQs

Does MFA stop consent phishing?

No. The attacker never logs in; the victim does. MFA fires during the legitimate sign-in to the consent prompt, the user authenticates correctly, and then approves permissions for the malicious app. From that point on, the attacker holds a refresh token and reaches the data without ever touching the user's password or MFA.

What permissions do attackers request in a consent phishing attack?

Common high-value scopes include Mail.Read, Mail.ReadWrite, Mail.Send, Files.Read.All, Files.ReadWrite.All, Contacts.Read, and offline_access. The offline_access scope is what gives the attacker a persistent refresh token. In a Microsoft 365 tenant, these grants typically arrive through the v2.0 endpoint with an enterprise-app registration that looks legitimate.

How do you revoke a malicious OAuth grant?

In Microsoft 365, an administrator removes the enterprise application or revokes the user's consent through Microsoft Entra. In Google Workspace, the administrator removes the app through Security and the user revokes through their account permissions. Critically, revoking the grant invalidates refresh tokens but does not always invalidate access tokens immediately; rotating user credentials and forcing reauthentication is often required.

Is consent phishing the same as token theft?

Related, not identical. Consent phishing obtains tokens through legitimate user consent to a malicious app. Token theft (also called token replay) obtains existing tokens through malware on the device, browser extensions, or man-in-the-middle proxies that capture the token mid-flight. Both result in the attacker holding valid tokens that bypass password and MFA on subsequent use.

How ARG tests consent phishing exposure during simulation

OAuth consent phishing is a standard channel in ARG's continuous simulation. It runs alongside email phishing, vishing, smishing, and (during on-site engagement weeks) physical pretext entries.

Tests are operated by James Wall on infrastructure ARG controls. A multi-tenant test app is registered with the same scopes a real attacker would request; lure pretexts vary per round (IT-driven tool rollout, vendor integration, M&A diligence portal, Copilot or AI assistant enrollment). Targets rotate across roles; engineering managers see "Document Review" pretexts, finance sees "Mail Backup" or "Reconciliation Tool" pretexts, executives see "M&A Diligence" pretexts.

Each test logs the lure, the recipient action (clicked, authenticated, consented), the scopes that would have been granted, and the post-grant detection events visible in the defending stack (Entra audit log entries, Defender alerts, Graph activity baselines). The output identifies which roles would have authorized which scopes, and which detection paths fired or did not.

Findings consolidate into the same monthly operational packet as the rest of the engagement. Remediation focuses on app consent policy tightening, OAuth detection coverage, the admin-consent allowlist, and the response playbook. Re-testing in the next round confirms whether the remediation held.

For founding clients, OAuth consent simulation is part of the monthly retainer alongside the other social engineering channels.

Apply as a founding client or see how the engagement works for the full delivery cycle.