OAuth consent phishing

How it works

An attacker registers an OAuth application with an identity provider such as Microsoft Entra ID or Google Workspace, often naming it something that looks like a document viewer or scheduling tool. They send the target a link to that application's consent page. The link goes to the real identity provider's real domain, so the browser padlock and the hostname are both genuine. The victim signs in normally, on their own tenant's login page, and completes their own MFA challenge exactly as they would for any other login.

What the victim then sees is a consent screen asking whether the application may read their mail, access their files, or act as them for a listed set of scopes. If they approve it, the identity provider issues the application an OAuth token with those scopes, and that token belongs to the application, not to the victim's browser session. It keeps working after the victim changes their password, because a password reset revokes the user's own sessions, not a token already issued to a third-party application. Google Threat Intelligence Group documented one suspected Russian cluster, UNC5976, running a variant of this against academia, aerospace, defense, and government targets in August 2026: a fake file-sharing page with a "Continue with Google" button that routed through the real Google login and captured the resulting tokens. Two other clusters in the same GTIG report, UNC6293 and UNC7005, ran different token-theft techniques against overlapping targets in the same window, verification-code relay and device-code phishing respectively, not OAuth consent phishing itself, but all three produce the same outcome: a legitimate token instead of a password.

Why it works

The identity provider's consent screen is designed to let users authorize third-party productivity tools, and it cannot distinguish a legitimate calendar app from a malicious one by name or icon alone. The control assumption that fails is that a user who successfully authenticates and then clicks "accept" has evaluated what they are accepting. In practice the consent screen competes with a login flow the user has completed hundreds of times without incident, and the scopes are described in the identity provider's generic language rather than in terms of what the requesting application actually does with them. Nothing about the strength of the user's password or their MFA method touches this step at all, because the attacker never needed either one. See consent management for how this is supposed to be governed.

How to detect it

• New OAuth application grants where the application's publisher is unverified or was registered in the last 24 hours.
• A single application accumulating consent grants from many users in a short window, which is unusual for a legitimately adopted internal tool.
• Application permissions that exceed what the application's stated function requires, particularly mail read, mail send, and files read-write together.
• Token usage from the application continuing after the granting user's password reset or MFA re-enrollment, since neither action revokes an already-issued application token.

Be honest about the limits: employees legitimately connect dozens of third-party tools to their identity provider every quarter, and most consent grants are exactly what they appear to be. A detection rule that fires on every new grant will be ignored inside a week; this needs risk scoring on publisher verification and scope sensitivity, not a blanket alert.

How to stop it

• Restrict user consent so that only administrator-approved applications can request sensitive scopes, closing the self-service path attackers rely on.
• Require admin consent workflows for any application requesting mail, file, or directory read-write scopes, with a named reviewer rather than an automatic approval.
• Audit existing OAuth grants on a recurring schedule, not just at onboarding, since consent granted once persists until explicitly revoked. See privilege escalation for what an over-scoped grant makes possible next.
• Revoke tokens explicitly during incident response. A password reset alone does not touch application tokens already issued; the grant itself has to be revoked.
• Educate users on scope review, focused on what a specific request would let an application do, rather than a generic warning about phishing links.

Seen in the wild

• Three Russian clusters move from password phishing to OAuth token theft
• Midnight Blizzard vs Microsoft: a legacy test account and an over-permissioned OAuth app

Sources

• MITRE ATT&CK T1528: Steal Application Access Token
• Microsoft: Detect and remediate illicit consent grants