What is Consent Phishing?

Consent phishing, also known as an illicit consent grant attack, is a phishing technique that exploits OAuth 2.0 authorization flows. Instead of stealing credentials directly, the attacker tricks the victim into granting permissions to a malicious third-party application. Once the victim clicks "Allow" or "Accept" on a legitimate-looking OAuth consent prompt, the malicious app gains API-level access to the victim's data—email, files, contacts, and messages—and this access persists even if the user later changes their password or enables multi-factor authentication (MFA). The attack is particularly dangerous because it bypasses traditional security controls and leaves organizational defenders struggling to detect unauthorized access that technically received explicit user consent.

How does consent phishing work?

Consent phishing exploits the legitimate OAuth 2.0 authorization framework in a seven-stage attack sequence. First, the attacker registers an OAuth 2.0 application with a cloud platform (Microsoft Entra ID, Google Workspace, Salesforce, etc.). The registration requirements are often minimal—a developer account is sufficient. Second, the attacker disguises the application to appear legitimate, often naming it to resemble a trusted productivity tool, meeting scheduler, or security scanner. Attackers may spoof or abuse verified publisher badges to increase legitimacy. Third, the attacker sends a phishing email or message containing a link to the OAuth consent URL. Lures typically involve urgency, such as "Your account requires re-authorization," "Review shared document," or "Approve pending request."

Fourth, when the victim clicks the link, they are redirected to a legitimate OAuth consent page from the real identity provider (for example, Microsoft login.microsoftonline.com). The page displays the malicious application name and asks the victim to grant specific permissions—such as Mail.Read (read email), Mail.Send (send email as the user), Files.ReadWrite.All (access all files), or offline_access (for refresh tokens). Fifth, the victim clicks "Accept" or "Allow," granting an OAuth token to the attacker-controlled application. Sixth, the attacker uses the OAuth token and refresh token to access the victim's resources via API. No credentials are stolen; the OAuth token itself provides persistent access that bypasses credential-based controls. Seventh, the access persists: password changes and MFA enforcement do not invalidate the OAuth grant, because the token-based access is independent of the authentication credentials.

More sophisticated variants have emerged. The hidden consent grant variant, identified by Semperis in 2025, allows attackers to add additional permissions after initial admin-level consent has been granted, without triggering another consent challenge to the victim. This enables privilege escalation post-compromise. The ConsentFix variant, disclosed by Push Security in 2025, combines ClickFix social engineering with OAuth consent phishing, hijacking OAuth grants through browser-native techniques. These variants represent evolving attacker sophistication in exploiting trust-based OAuth frameworks.

How does consent phishing differ from other credential-based attacks?

Consent phishing differs fundamentally from credential phishing. In credential phishing, the attacker steals the victim's username and password through a fake login page. Credential changes invalidate the attacker's access. In consent phishing, the attacker receives a token that grants API-level access independent of the victim's credentials. Changing passwords or enforcing MFA does not revoke the attacker's token-based access.

Device code phishing is related but distinct. Both consent phishing and device code phishing result in OAuth token theft and both bypass MFA. However, in consent phishing, the victim grants permissions to a third-party application, which is clearly visible in OAuth consent dialogs. In device code phishing, the victim never sees a permission request; instead, the attacker generates a device code and tricks the victim into authenticating on a legitimate OAuth login page, with the tokens captured by the attacker's endpoint rather than the victim's device.

Why does consent phishing matter?

Consent phishing represents a growing threat that exploits the tension between organizational security controls and legitimate OAuth integration practices. While hard statistics on consent phishing volume alone are limited—4.8 million phishing attacks were recorded by APWG in 2024 across all types, but consent phishing-specific breakdowns are not publicly disaggregated—Microsoft, Proofpoint, and security researchers indicate rapidly growing adoption by threat actors.

Microsoft observed in 2024 that consent phishing attacks were becoming increasingly sophisticated and harder to detect due to the use of verified publisher badges and hidden consent grants. Push Security reported in 2024 that consent phishing and device code phishing are becoming "increasingly difficult in core enterprise cloud environments like Azure due to stricter default configs," pushing attackers to evolve techniques. This indicates both that the threat is real and that defenders are raising their game.

State-linked and financially motivated threat actors have adopted OAuth-based phishing. According to Microsoft's "Defending against evolving identity attack techniques" (2025), state-linked actors including the Russian group Storm-2372 and financially motivated groups including TA2723 have adopted OAuth-based phishing since 2024. A high-profile August 2025 campaign abused trusted OAuth integrations (Drift) to access Salesforce organizations, using stolen OAuth tokens to mass-query Salesforce and mine embedded secrets (AWS credentials, Snowflake keys), then pivot into connected platforms, according to Dark Reading's "OAuth Abuse: The Threat of Illicit Consent Grants" (2025). This demonstrates the real-world risk of consent phishing to enterprise infrastructure.

What are the limitations of consent phishing attacks?

Consent phishing has several constraints that limit its effectiveness. First, the attack requires user interaction with a legitimate consent page. The attack fails if the victim does not click "Allow." Users who are cautious about app permissions and review permission scopes carefully can stop the attack entirely.

Second, administrative consent controls are highly effective. Organizations that restrict user consent to admin-approved apps only, or apps from verified publishers only, significantly reduce attack surface, according to Microsoft's "Protect against consent phishing" (2024). This single control can reduce consent phishing risk from critical to low.

Third, malicious OAuth applications are detectable through regular reviews of granted app permissions. Unusual API activity patterns, sudden access to many users, and anomalous consent patterns can be identified through audit logs and cloud access security broker (CASB) tools. According to Microsoft's "Detect and Remediate Illicit Consent Grants" (2024), proactive auditing prevents attacker persistence.

Fourth, platform restrictions are progressively tightening. Microsoft and Google have progressively tightened default consent settings, making it harder for unverified apps to request broad permissions. This raises the bar for attacker success, according to Push Security (2024).

Fifth, consent phishing doesn't work without OAuth support. This attack is only effective against platforms with OAuth 2.0 consent flows—primarily cloud and SaaS applications. Legacy on-premises systems are not vulnerable because they lack OAuth infrastructure.

Sixth, refresh tokens eventually expire. While long-lived, refresh tokens do have expiration policies configurable by administrators. Organizations that shorten token lifetimes can reduce the attacker's persistence window even if consent is granted.

How can organizations defend against consent phishing?

The single most effective mitigation is restricting user consent in Azure AD / Microsoft Entra ID. Organizations should set "User consent for applications" to "Do not allow user consent" or alternatively "Allow user consent for apps from verified publishers only, for selected permissions." This is the foundational control, according to Microsoft's "Protect against consent phishing—Microsoft Entra ID" (2024).

Enable an admin consent workflow so users can request app access, which is then reviewed by an administrator before being granted. This converts a one-click attacker vector into a multi-step approval process requiring human judgment.

Regular app permission audits are essential. Organizations should periodically review all third-party apps with granted OAuth permissions and immediately remove apps that are no longer needed or appear suspicious. Tools such as Microsoft Defender for Cloud Apps and SSPM (SaaS Security Posture Management) solutions can automate this monitoring, according to Microsoft's "Detect and Remediate Illicit Consent Grants" (2024) and Valence Security (2024).

Configure app governance policies to detect anomalous app behavior, such as apps with excessive permissions, apps from unverified publishers, or apps exhibiting unusual API call patterns. Microsoft Entra ID and dedicated SSPM solutions provide these capabilities.

Require that only apps from verified publishers can be consented to by users. Verified publisher status increases the barrier for attackers who would need to go through formal publisher verification, which requires identity validation.

Security awareness training is important but insufficient as a standalone control. Train users to scrutinize OAuth consent prompts carefully. Key warning signs include unfamiliar app names, requests for broad permissions (Mail.Read, Files.ReadWrite.All), and unsolicited consent prompts triggered by emails. According to Infosec Institute (2024), educated users can identify many suspicious consent dialogs.

Implement Conditional Access Policies that evaluate app consent requests based on user risk, device compliance, and location. These policies can block consent for high-risk users or unusual sign-in scenarios.

Reduce OAuth token and refresh token lifetimes to limit attacker persistence if consent is granted. Shorter token lifetimes mean attackers have less time to extract data or move laterally before tokens expire.

Deploy SaaS Security Posture Management (SSPM) solutions such as Valence Security, Push Security, or AppOmni for continuous monitoring of OAuth grants across SaaS platforms. These tools provide real-time visibility into permissions granted across the organization's cloud footprint.