Consent Phishing: The Attack That Doesn’t Need Your Password

Consent phishing (also called “OAuth phishing” or “illicit consent grant attacks”) is a social engineering technique where attackers trick users into granting a malicious third-party application permissions to access their accounts — via cloud services like Microsoft 365, Google Workspace, or Slack — without ever stealing a password.

Instead of harvesting login credentials through a fake login page, the attacker exploits the OAuth 2.0 authorization framework, the same protocol legitimate apps use to request access to your email, files, contacts, or calendar. Because the victim technically “approves” the access themselves, this attack bypasses many traditional defenses, including multi-factor authentication (MFA).

Why Consent Phishing Is So Effective

1. It sidesteps MFA entirely. Since no password is stolen, one-time codes, authenticator apps, and hardware keys become irrelevant — the attacker never needs to authenticate as the user.
2. It uses legitimate infrastructure. The malicious app is registered through real platforms (Microsoft Azure AD, Google Cloud, etc.), so the consent prompt looks authentic, often carrying real logos and legitimate-looking publisher names.
3. Access persists. Once granted, the OAuth token can remain valid for a long time — sometimes indefinitely — surviving password resets.
4. It scales easily. A single phishing campaign can target hundreds of employees with the same malicious app link.

How the Attack Works — Step by Step

Step 1: Attacker registers a malicious app
The attacker creates an application within a legitimate cloud provider’s developer platform and registers it as an OAuth client, often naming it something trustworthy-sounding (“Document Viewer,” “Zoom Meeting Extension,” “O365 Access”).

Step 2: The phishing lure
The victim receives an email, Teams/Slack message, or text with a link — often disguised as a shared document, meeting invite, or software update — that leads to a real, legitimate OAuth consent page (e.g., login.microsoftonline.com or accounts.google.com).

Step 3: The consent screen
Because the domain is genuine, there’s no fake login page to trigger suspicion. The user is asked to “Accept” permissions such as:

• Read/send email
• Access files and folders
• Read contacts and calendar
• Maintain access to data the user has granted access to

Step 4: Token issued
If the user clicks “Accept,” the identity provider issues the attacker’s app an access token (and often a refresh token). The attacker now has programmatic access to the account’s data and can extract information without ever knowing the password.

Step 5: Persistence and abuse
The attacker can use this access to exfiltrate emails, launch further phishing internally (from a trusted account), access sensitive files, or pivot deeper into an organization.

Real-World Examples

• PerSwaysion (2019–2020): A large-scale consent phishing campaign that targeted executives at over 150 companies, using fake Microsoft 365 login and consent pages to gain access to email accounts.
• Google Docs OAuth worm (2017): Attackers sent what appeared to be a Google Docs sharing invitation; accepting it granted a malicious app full access to victims’ Gmail and contacts, allowing the attack to self-propagate.

Warning Signs to Watch For

• Consent requests asking for broad or unusual permissions (e.g., “read and send email on your behalf” for a simple document viewer).
• Apps with generic, vague, or misspelled names.
• Unverified publishers (most platforms flag whether an app’s publisher identity has been verified).
• Unexpected consent prompts triggered by clicking a link in an unsolicited email or message.
• Permission requests that don’t match the app’s stated purpose.

How to Defend Against Consent Phishing

For Individuals

• Scrutinize consent screens the same way you would a login page — check the app name, publisher, and requested permissions before clicking “Accept.”
• Avoid granting broad permissions to apps you don’t recognize or didn’t intentionally seek out.
• Periodically review connected/authorized apps in your Google, Microsoft, or other account settings and revoke anything unfamiliar.

For Organizations

• Restrict user consent: Configure identity platforms (e.g., Azure AD/Entra ID) to disallow end users from consenting to app permissions without admin approval, especially for high-risk scopes.
• App verification/allow-listing: Only permit pre-approved, vetted applications; require admin consent workflows for anything else.
• Monitor OAuth grants: Use security tools (e.g., Microsoft Defender for Cloud Apps, Google Workspace security alerts) to detect unusual app registrations or consent grants.
• Conditional access policies: Apply risk-based policies that flag anomalous token usage patterns.
• Security awareness training: Train employees specifically on OAuth-based phishing, since most anti-phishing training still focuses only on credential theft.
• Regular audits: Periodically review and revoke stale or unnecessary third-party app permissions across the organization.

Consent Phishing vs. Traditional Phishing

Conclusion

Consent phishing represents an evolution in social engineering — one that exploits trust in legitimate authentication systems rather than trying to replicate them. As organizations harden their defenses against classic credential phishing with MFA and password managers, attackers have adapted by targeting the authorization layer instead. Defending against this threat requires a shift in mindset: users and administrators alike need to treat “Allow access” prompts with the same suspicion as login pages, and organizations need governance controls that prevent unchecked app consent in the first place.