How to defend the full social engineering attack chain | Register for the webinar to learn more

General

What Is Consent Phishing?

Consent phishing tricks users into granting OAuth permissions to malicious apps, giving attackers cloud access without passwords; learn how it works, why it’s hard to stop, and effective defenses.

Doppel Team• Security Experts
September 23, 2026
5 min read

Consent phishing is a social engineering attack that tricks a user into granting OAuth permissions (opens in new tab) to an attacker-controlled application, giving it standing access to their cloud account to read email, send mail, or reach files. Unlike credential phishing, which steals a password, consent phishing never needs one: the victim hands over access by approving a legitimate permission request on the provider's own screen.

Microsoft calls the technique an illicit consent grant (opens in new tab), and MITRE ATT&CK tracks it as technique T1528 (opens in new tab), Steal Application Access Token. The attacker registers an app with an OAuth 2.0 provider such as Microsoft Entra ID and gives it a name resembling a real productivity tool. Common requested scopes include Mail.Read and Files.Read; the attacker may also request offline_access and set a redirect URI pointing at their own infrastructure.

Delivery uses a standard OAuth authorization URL (opens in new tab) sent by email or planted on a trusted website. The link points to the identity provider's real authorization endpoint, such as https://login.microsoftonline.com/ (opens in new tab), while its query string carries the attacker's client_id and requested scopes. The victim signs in normally, completes MFA if required, and sees a genuine consent screen listing the permissions the app requests.

One click on Accept sends a short-lived authorization code (opens in new tab) to the attacker's redirect URI, and their server exchanges it for a delegated access token, plus a refresh token when the user granted offline_access. From there the attacker works the API directly, reading the victim's mailbox through Microsoft Graph (opens in new tab) with the consented Mail.Read scope, all without ever seeing the victim's password.

Consent phishing is hard to stop because every artifact the victim and the security stack encounter is genuine. The victim signs in on the provider's real login page, completes MFA, and approves an authentic consent screen. The link resolves to the provider's real domain, so domain-reputation checks alone often miss it, and because the login page is real, training that teaches users to spot fake login pages (opens in new tab) offers no signal.

Multi-factor authentication does not help, because the provider issues tokens only after the victim completes it; the attacker inherits the outcome of a fully legitimate sign-in. The compromise also outlives standard incident response. Password resets and MFA re-enrollment do not end it, because the consented app sits outside the organization and its refresh token keeps working until an administrator revokes the grant, removes the app, or the token expires.

Consent phishing also rarely travels alone. Attackers pair it with related techniques such as device code phishing and adversary-in-the-middle proxies, so a single approval can be one step in a larger campaign.

Consent phishing and closely related OAuth token-phishing techniques take a few main forms:

  • Classic illicit consent grant. A phishing email carries a real authorization URL for a malicious app. Once the victim consents, the granted scopes let the attacker read and exfiltrate mail, reach files in OneDrive and SharePoint, and send mail as the user.
  • Device code phishing. A related technique abuses the OAuth device authorization flow: the attacker generates a legitimate device code and tricks the victim into entering it on the provider's real device-login page, capturing the resulting access and refresh tokens without registering a malicious app at all.

Because consent phishing exploits a legitimate feature, defense centers on governing consent and auditing the grants already in place:

  • Restrict user consent. In Microsoft Entra ID, limit user consent (opens in new tab) so employees can approve only apps from verified publishers requesting low-impact permissions, or adopt Microsoft's managed default. In Google Workspace, control third-party app access (opens in new tab) and block unconfigured apps by default.
  • Route requests through admins. Pair the restriction with an admin consent workflow (opens in new tab) so blocked users can send requests to designated reviewers instead of working around the control.
  • Audit existing grants. Policy changes govern only future consents, so audit enterprise application permissions (opens in new tab) regularly, prioritizing excessive scopes across Exchange Online and Microsoft Graph.
  • Keep a revocation playbook. When investigators confirm an illicit grant, revoke active sessions, clear refresh tokens for the affected accounts, and remove the malicious application or service principal along with its OAuth grants.

Because the lure that starts the attack arrives by email, lookalike domain, or fake file-sharing page, these controls work best alongside delivery-layer detection that catches the impersonation before an employee ever reaches the consent screen.

How Doppel helps

Doppel is the AI-native Social Engineering Defense (SED) platform that unifies Digital Risk Protection and Human Risk Management. Because consent phishing succeeds at the delivery layer, where the lure reaches the employee, that is where the platform focuses: it detects the spoofed sender domains, impersonation emails, and fake file-sharing pages used to deliver consent lures before anyone reaches a consent screen.

Doppel's Brand Protection product and the Doppel Threat Graph correlate scattered infrastructure into a single campaign view, where agentic AI dismantles the domains and pages behind a lure. Phishing simulation turns a detected threat into a controlled exercise, and Security Awareness Training teaches employees to scrutinize an app's permission requests even when the URL looks legitimate.

Dismantling that delivery infrastructure forces attackers to rebuild it for every attempt, making the next campaign too costly to run. Request a demo to get started.

Consent phishing is an attack that tricks a user into granting OAuth permissions to a malicious application for their cloud account, such as reading email or accessing files. The victim signs in on the identity provider's real login page and approves a genuine consent screen, giving the attacker tokens without exposing a password. The attacker receives access and refresh tokens (opens in new tab) that allow API calls on the victim's behalf. The technique also goes by the name illicit consent grant.

Credential phishing attacks the authentication layer by capturing passwords on a fake login page. Consent phishing attacks the authorization layer: the victim authenticates legitimately on the real provider's domain and then delegates permissions to an attacker-controlled app. The distinction matters for response, because a password reset may address stolen credentials but does not revoke consent. Ending a consent phishing compromise requires revoking the OAuth grant and removing the malicious application.

In cybersecurity, consent phishing is classified as an authorization attack rather than a credential-theft one. It maps to MITRE ATT&CK technique T1528, Steal Application Access Token, and is often called an illicit consent grant. The user approves a malicious app's OAuth permissions without surrendering a password, so the resulting access is delegated and token-based, and it persists until the grant is revoked rather than until the password changes.

No. Multi-factor authentication validates identity at sign-in, and consent phishing operates after sign-in succeeds. The victim completes MFA legitimately on the real login page, and the attacker receives the tokens the provider issues afterward. Because the malicious app already holds a consented grant, MFA does not revoke it.

In a campaign disclosed in January 2023, a threat actor abused Microsoft's verified-publisher process (opens in new tab) to get malicious OAuth apps approved, then relied on trustworthy-looking consent screens to gain access and exfiltrate mail from targeted organizations.

A related device-code campaign shows how far the technique reaches. Since August 2024, the threat actor Storm-2372 (opens in new tab) has sent lures resembling WhatsApp, Signal, and Microsoft Teams invitations that carried attacker-generated device codes; victims who entered a code on Microsoft's real device-login page handed over access and refresh tokens. Microsoft also observed the group registering attacker-controlled devices in victims' Entra ID to obtain a Primary Refresh Token and extend access.

Last updated: September 23, 2026

Related Articles

More insights on related topics.

View All Articles