What is consent phishing?
Most people are familiar with the two most common types of phishing”Š”, “Šcredential phishing and phishing payloads, where attackers trick users into revealing credentials and downloading malicious software respectively. However, there is a third type of phishing on the rise: consent phishing. Consent phishing deceives users into granting a third-party SaaS application access to their account, enabling it to retrieve sensitive information or act on their behalf. These attacks leverage existing permissions provided by identity and OAuth providers like Google and Microsoft. For example, the Mail.ReadWrite scope on Microsoft allows a third party SaaS app to read and reply to any email on the user’s inbox. OAuth was originally created to enhance user experience and productivity by seamlessly integrating software tools. In the past few years, OAuth has become a widely adopted authentication method due to the surge in the number of SaaS applications used in the workplace. According to SaaS Academy, most large enterprises have 450 active SaaS apps at a given time, with an average employee working with 12 to 14 applications on a daily basis. Thus, the growing demand for seamless integration and efficient workflows has made OAuth a critical tool. Unfortunately, the very same consent capabilities have been repeatedly misused by attackers to steal confidential data, impersonate employees and distribute malware. This article will discuss the mechanisms behind consent phishing, some case studies and best practices to defend against this rising attack form. However, in order to truly understand consent phishing, it is important to first understand how OAuth works.
Understanding how OAuth Works
OAuth was created to enable users to authenticate through a single trusted Identity Provider (IDP), which can then be used by other applications to verify the user’s identity. Applications can also request permissions to perform actions on behalf of the user. These permissions, known as scopes, define the extent of the actions an application can take on the user’s behalf. This is what a typical OAuth flow looks like:
- The user signs up and accesses a new SaaS app. The app redirects the user to the user’s IDP, which displays the app’s details and requested scopes (permissions). The user confirms their identity and grants these permissions by entering their credentials into the IDP. Authentication occurs via one of two means:
Implicit authentication, where consent is granted automatically once credentials are entered. Code authorization, where the user inputs a provided code into the IdP’s authorization page to grant consent. 5. Once the consent is granted, the IDP generates three tokens: ID tokens identifies the app as an authorized app Access tokens allows the app to perform permissioned actions Refresh tokens enables the app to obtain new tokens
How does consent phishing work?
Consent phishing works very similarly to a regular OAuth authentication flow, which is why it is especially difficult for employees to identify. Typically, it involves the following steps:
- The attacker identifies the target users and learns (i) their IDP and (ii) the types of SaaS applications they use. The attacker builds a similar app, or simply a shell app that has a relevant name and registers it on the relevant OAuth provider. The attacker uses a variety of spearphishing techniques to trick the user into clicking the OAuth link to the malicious app. The user gets redirected to their legitimate IDP, requesting consent to grant specific permissions to the app. Once the user accepts this request, the attacker can use the access tokens to perform malicious acts.
Now that we understand the typical flow of a consent phishing attack, let’s look at several case studies to see how it has been used to compromise employee accounts in practice.
Case Study 1: O365/Gmail Account Takeovers
There have been several consent phishing attacks aiming to gain control of employee emails. A common tactic involves a spearphishing email mimicking a file sharing notification from OneDrive or Google Drive. Once the employee clicks on “Open” they get redirected to their IDP, requesting permissions to read and send emails on their behalf. Believing that the email came from a trusted app, employees frequently breeze through these terms. These permissions are then used by attackers to read confidential emails and send emails from this employee’s account to other employees containing further phishing links or malware. Now that these emails come from a legitimate internal address, it becomes even more difficult for other employees to recognize that they come with malicious intent.
Image Source: Microsoft [1], [2]
Case Study 2: Gitlocker Attacks
Earlier this year, a spearphishing campaign from the address notifications-at-github.com sent fake job and security alerts to developers on GitHub, containing a link to one of two malicious sites: githubcareers[.]online or githubtalentcommunity[.]online. Upon arriving on these websites, the user is asked to grant the malicious app the right to access their personal information and private repos. Attackers then used these accounts to spam forums and notifications, while many victims reported losing access to their entire repository
Case Study 3: Chrome Extension Attack
Just this week, Cyberhaven was reported to release a malicious version of their browser extension on Chrome Store, which were used to steal session cookies and exfiltrate sensitive information across multiple apps used by their customers. This was the result of a large-scale consent phishing attack targeting extension developers. An email mimicking Chrome Store was sent, requesting urgent action to prevent the developer’s extension from being removed from Chrome Store due to a compliance violation. This led to an OAuth page requesting permission for a Privacy Policy Extension to “edit, update or publish” the developer’s Chrome extensions. A full demo of the attack was discovered and disclosed by SquareX researchers a week before the breach. medium.com/media/d9b24f87f6ef115da9257e938646d492/href Source: SquareX
Why is consent phishing so dangerous?
Unlike regular credential phishing, consent phishing is especially challenging to deal with due to several reasons.
- Permissions Fatigue
As seen across several examples above, the consent phishing sequence closely mimics a typical SaaS authorization workflow, a process that employees frequently go through. Just like how most people don’t read the fine print on most Terms & Conditions forms, it is more likely than not that employees click through these OAuth pages without fully reading the permissions requested. Furthermore, the regular user may not be technical enough to understand the “normal” permissions required for SaaS apps to function, especially as many legitimate applications such as Grammarly also request similar rights to these malicious apps. 2. Involves a Trusted IDP/OAuth Provider Consent phishing leverages legitimate IDP providers such as Google and Microsoft that are generally trusted by employees. This makes it more challenging for an average user to distinguish between legitimate and malicious requests. 3. Poor Traceability Once a user grants consent to a third party SaaS app, malicious or not, it is extremely difficult for security teams to track which apps these permissions are granted to, what these permissions are used for or to revoke these rights at the admin level. Similarly, if multiple third party apps have the same permissions, it may be challenging to track the root cause of an attack should a breach occur.
Best practices to deal with consent phishing
How then should an organization protect itself against consent phishing? Here are some best practices that we believe are critical for every organization to consider. 1. Restrict ability to grant OAuth permissions The most deterministic way to prevent consent phishing is to prevent users from granting OAuth permissions to unauthorized SaaS apps, especially risky permissions that may involve reading sensitive information or writing, editing or publishing on the user’s account. Now a completely strict whitelist may not be realistic for most organizations, thus it is important that there is a seamless way for employees to request for exceptions and for security teams to easily review these requests in a timely manner. SquareX’s Browser Detection and Response (BDR) solution allows security teams to do just that. Not only can they manage the OAuth workflows across the organization, the platform also allows admins to centrally grant exceptions on a one-off, time-bound or perpetual basis. Employees can even append a business reason in the exception request to avoid the painful back and forth that often impacts productivity and trust between users and the security team. https://youtu.be/YoHetx4xbpg 2. User education on consent phishing attacks One key reason for the effectiveness of consent phishing attacks is the lack of awareness on how OAuth permissions can be used in a malicious way. As discussed, employees often associate IDP providers with legitimate applications and hence do not truly understand the risk of carelessly approving authentication workflows. Unfortunately, due to the nascency of these attacks, many security training programs are still focused on basic credential phishing and do not include consent phishing as part of the curriculum. It is absolutely critical that companies raise awareness about consent phishing internally through case studies and ideally, in workflow training. For example, SquareX’s BDR enables security teams to add custom messages to policies blocking OAuth workflows in order to help users understand the risks associated with the permissions requested by their apps. 3. Regularly audit existing permissions Last but not least, it is extremely common for a benign app to turn malicious”Š”, “ŠCyberhaven is just one of many examples. Vendors could be hacked, or attackers may have developed a benign app on purpose to get approved by security teams before adding malicious functionality. Thus, it is critical for security teams to regularly audit the SaaS apps and permissions employees are using.
Introducing the BDR
SquareX’s Browser Detection and Response (BDR) solution goes beyond just protecting against consent phishing and identity-based attacks. SquareX’s industry-first BDR solution detects, mitigates and threat-hunt client-side web attacks targeting employees in real time. The solution comes in the form of a lightweight browser extension that can be deployed to existing browsers via a simple group policy. We believe that there are three key components required when it comes to securing the browser: Web Threat Detection & Mitigation including identity attacks, malicious sites & scripts, malicious browser extensions and malicious files Browser DLP including genAI DLP, clipboard DLP, file DLP and insider attacks Private App Access to provide secure access to web applications and private apps via the browser, including for BYOD/unmanaged devices
Consent Phishing: The New, Smarter Way to Phish was originally published in SquareX Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.
First seen on securityboulevard.com
Jump to article: securityboulevard.com/2025/01/consent-phishing-the-new-smarter-way-to-phish/
