A sophisticated attack vector known as “consent phishing” has emerged as a significant SaaS security threat. Unlike traditional phishing that targets credentials directly, consent phishing exploits legitimate authorization protocols that use OAuth 2.0 to gain persistent access to corporate SaaS resources.
Late last year it was disclosed that Google Chrome extension vendors were targeted in a consent phishing attack with 2.6 million end users impacted. This attack targeted at least 35 commonly used Chrome browser extensions including the cybersecurity firm Cyberhaven. Cyberhaven disclosed that an employee’s account was compromised in an earlier attack, which enabled threat actors to gain access to the Google Chrome Webstore. Attackers deployed consent phishing tactics, tricking users into granting permissions to a malicious OAuth application disguised as a legitimate "Privacy Policy Extension", allowing them to publish malicious versions of Chrome extensions. Other notable campaigns this year include attacks involving 12,000 GitHub repositories and Microsoft.
Consent phishing typically involves sending a socially engineered email to a victim’s mailbox. Microsoft email in particular seems to be highly targeted. Victims are lured with compelling and urgent messaging such as security alerts in GitHub. Once the victim approves the permissions request, the threat actor harvests the OAuth token, gaining full access to the resources via API, rendering multifactor authentication (MFA) useless.
Read further to understand this insidious threat and how best to safeguard against it.
How Consent Phishing Works
Here is a step-by-step sequence of such an attack:
1. Launch Phishing Campaign: A spear phishing campaign, usually using email, targets specific users, with a call to action that uses urgent messaging such as: “See security alert,” “Click here to view message,” “Upgrade account security,” etc.
2. Consent Request: After clicking the link, the user is redirected to a legitimate consent page, for example from Microsoft 365 or Google Workspace. Here, the permissions requested are detailed, usually giving the threat actor read and write permissions over emails, contacts, and files.
3. Authorization: The unsuspecting user reviews and accepts the requested permissions, believing the request is legitimate. Upon consent, the threat actors then receive an authorization code from the SaaS application, enabling them to create a new OAuth session token, which grants them access to the victim’s environment.
4. Access Token Acquisition: The OAuth token then allows API calls that interact with user data based on granted permissions, often with read and write, and with potential access to sensitive information—enabling them to manipulate APIs, exfiltrate data, or maintain persistent access.
Why MFA Fails Against OAuth Consent Phishing
While organizations might think they have adequate security controls in place protecting access to their critical SaaS applications, most commonly using MFA, with consent phishing these controls prove to be useless. Since the attackers leverage non-human identities that leverage OAuth 2.0 API-based access, MFA protections are rendered ineffective against the subsequent abuse of granted permissions.
Adding to the security challenge is the common lack of monitoring of 3rd party integration environments. This is often due to a lack of dedicated tooling, but also due to the complexity that these environments can entail.
The Technical Anatomy of OAuth Consent Phishing
The mechanics of consent phishing involve several critical components that are incredibly difficult to detect and that result in devastating breaches, often compromising an organization’s most sensitive data:
1. Unmonitored Non-Human Identities / OAuth Tokens: NHI’s like OAuth tokens and their lifecycle often fly under the radar, particularly from a creation, permissioning and integration monitoring vantage point.
2. Excessive Permission Scope: Threat actors request and succeed in getting highly privileged permission scopes like read and write access for email, contacts, and files.
3. Longer Dwell Times: Unlike compromised credentials that can be changed, OAuth tokens can provide longer dwell times due to their long-lived nature, providing access until explicitly revoked.
Security professionals must understand that standard security controls like conditional access policies typically evaluate risk at authentication time for human users, but fail to assess the security posture of applications requesting delegated permissions.
Final Word
As defenses evolve, so too will attack methodologies. It is likely that consent phishing campaigns are already leveraging AI to create convincing lures for victims. These types of attacks should be taken as a clear signal that the security mandate extends beyond protecting credentials to securing and monitoring the entire authorization layer of SaaS environments, including new 3rd party integrations and permission scopes.
To get a handle on this threat, security professionals should implement controls focused on third party SaaS integrations, which at a minimum should include regular audits and revocations of unauthorized OAuth tokens.
.jpg)
