OAuth consent phishing

OAuth consent phishing, which Microsoft calls an illicit consent grant, tricks a user into approving an attacker-controlled application's request for access to their mail, files, or other data. The sign-in page is real, the user's MFA succeeds, and what the attacker receives is an OAuth grant that belongs to the application rather than the user's session. Microsoft's own guidance is that "normal remediation steps (for example, resetting passwords or requiring multifactor authentication (MFA)) aren't effective against this type of attack." It is a talk-past attack: authentication is satisfied, not broken.

How it works

1. Register an app. The attacker registers a multi-tenant application in Microsoft Entra ID, Google Cloud, Salesforce, or any OAuth provider, with a name such as "Document Viewer", "Privacy Policy Extension", or a copy of a real vendor tool.
2. Request the useful scopes. Typical requests are mail read and send, file read, contacts, and offline_access, which yields a refresh token so the access outlives the session that granted it.
3. Deliver the consent link. The link goes to the provider's genuine authorization endpoint, so the hostname and certificate are correct. Delivery is by email, a fake file-share page with a "Continue with Google" button, or a phone call from "IT support".
4. The user consents. They sign in to their own tenant, pass their own MFA, and click Accept on a screen listing the requested scopes in the provider's generic wording.
5. Harvest through the API. The application now holds tokens and reads mail or files through the provider's API, from the attacker's infrastructure. Nothing about this looks like a login from a new location, because the user's own sign-in was ordinary.

Variants change the delivery, not the principle. In UNC6040's campaign against Salesforce customers, a caller posing as IT support walked the employee through authorizing a modified Data Loader connected app. ConsentFix, reported in July 2026, has the victim drag a localhost callback URL back into the browser, handing over the authorization code. Device-code phishing, covered in its own brief, achieves the same token-without-password outcome through a different OAuth flow; see device code phishing.

Why it works

The consent screen is built to let users connect productivity tools without an administrator, and it cannot tell a real calendar app from a malicious one by name or icon. The control assumption that fails is that a user who authenticates and clicks Accept has evaluated what they accepted. They have approved hundreds of similar screens without incident. Two structural facts make the grant durable. First, it sits outside the user's credential: in Microsoft Entra ID a consent grant is an authorization given to a separate service principal, which has "account-level access to data without the need for an account in the organization," so a password reset or MFA re-enrollment does not touch it. The same pattern holds on Google Workspace, where Cyberhaven's employee received no MFA prompt at all. Second, Microsoft's default lets all users consent to permissions that do not require admin consent, which includes access to their own mailbox. The grant lives in the MFA blind zone: the abused path never reaches a login where MFA could apply.

How to detect it

• "Consent to application" audit events. In Microsoft 365, search the Purview audit log (or Entra audit logs) for the Consent to application activity and check whether IsAdminConsent is True, which means someone with admin rights granted tenant-wide access. Microsoft advises reviewing consent grants weekly in large tenants and notes audit entries can take 30 minutes to 24 hours to appear.
• Inventory the grants. Look for AllPrincipals consent types on non-Microsoft applications, read-write or ".All" delegated permissions, misspelled or bland application names, and grants held by executives or administrators.
• Grant velocity. A new application collecting consent from many users within hours is unusual for a legitimately adopted tool.
• Publisher and age. Unverified publisher, recently registered app, reply URLs on hosting or tunneling domains.
• API access after reset. Mail or file reads by an application that continue after the user's password reset are the signature of a surviving grant. MITRE's T1528 analytics describe the same chain: unusual app registration, user-granted tokens, then high-privilege resource access.

The false-positive problem: employees connect legitimate third-party tools constantly, and alerting on every grant trains the SOC to ignore it. Score on publisher verification and scope sensitivity, and alert only on the combination. Mailbox auditing must already be on to reconstruct what the app read.

How to stop it

Ranked by effect:

1. Restrict user consent. Allow users to consent only to apps from verified publishers for permissions you classify as low impact (the microsoft-user-default-low policy in Entra), or disable user consent. In Salesforce, restrict which connected apps users can authorize and require admin approval for API-enabled apps. MITRE's M1021 says the same.
2. Turn on the admin consent workflow so a blocked user can request review instead of looking for a workaround, with a named reviewer for any mail, file, or directory scope.
3. Audit existing grants on a schedule. Changing consent settings only affects future consents; existing grants remain. Revoke what nobody can explain.
4. Revoke the grant, not just the password, during response. In Entra, remove the delegated grant (Remove-MgOauth2PermissionGrant) and any app role assignment, and disable the service principal. Microsoft's guidance lists these steps explicitly.
5. Put phishing-resistant MFA on anyone who can approve apps. It does not stop consent itself, but it stops the credential theft that often accompanies vishing-led consent. See phishing-resistant MFA.
6. Train on scopes, not links: what would this request let the app do, and why would a PDF viewer need to send mail. See consent management and how third-party SaaS token breaches reach hundreds of tenants, the fan-out breach version of the same grant.

Seen in the wild

• Cyberhaven Chrome extension hijacked through OAuth consent phishing (December 24, 2024): an employee with Google Advanced Protection and MFA authorized a malicious "Privacy Policy Extension" app from an email posing as Chrome Web Store support. They received no MFA prompt; the attacker used the grant to publish malicious extension version 24.10.4.
• UNC6040 voice phishing campaign against Salesforce customers (disclosed June 4, 2025): callers talked employees into authorizing a modified Data Loader app, then exported data for extortion. Google reported one of its own Salesforce instances was hit in June 2025.
• Midnight Blizzard password spray into Microsoft corporate email (2023 to 2024): the actor used a legacy test OAuth application with elevated access to create malicious apps and grant itself full access to Exchange Online mailboxes. See the teardown.
• Three Russian clusters move from password phishing to OAuth token theft (August 2026): GTIG's UNC5976 ran a fake file-share page with a "Continue with Google" button.
• MITRE ATT&CK records APT28 using malicious OAuth applications posing as "Google Defender" to steal tokens.

The Identity Breach Report 2026 counts two incidents where OAuth consent never triggered an MFA prompt, and ranks governing OAuth apps and user consent as a control addressing 8 of its 123 incidents.

Sources

• MITRE ATT&CK T1528: Steal Application Access Token
• Microsoft: Detect and remediate illicit consent grants
• Microsoft Entra: Configure how users consent to applications
• Microsoft Defender for Cloud Apps: Investigate risky OAuth apps
• Google Threat Intelligence Group: The Cost of a Call, from voice phishing to data extortion (June 2025)
• RFC 6749: The OAuth 2.0 Authorization Framework