Consent phishing is where attackers trick users into authorizing malicious OAuth apps. But we’re now seeing different use cases emerge as attackers get creative to evade detection controls.
Consent phishing is where attackers trick users into authorizing malicious OAuth apps. But we’re now seeing different use cases emerge as attackers get creative to evade detection controls.
Consent phishing was one of the first techniques we added to the SaaS attacks matrix, where attackers trick users into authorizing malicious OAuth apps.
The attacker sends a phishing link to a target that requests permissions to access sensitive data or permissions to perform dangerous actions for an app the victim is using. If the target grants consent for the permissions, the adversary gains that level of access over the target’s account — and certain data and functionality depending on the scopes granted. This attack bypasses MFA entirely (including phishing-resistant MFA) by sidestepping the login process — think of it as an authorization attack, as opposed to an authentication one. Naturally, this means it also persists through typical authentication changes like a password reset.
Consent phishing has been primarily aimed at getting access to larger cloud platforms like Microsoft Azure or Google Workspace tenants, or more complex apps like GitHub. These apps present an obvious opportunity to attackers in terms of the functionality and and data they contain.
Two separate cases of consent phishing have hit the headlines this month representing very different use cases — let’s compare them.
1. Classic consent phishing
Attackers targeted GitHub users across 12,000 repositories by creating fake security alert issues in GitHub repositories. These legit-looking alerts send the victim to a GitHub authorization page for a "gitsecurityapp" OAuth app that requests a lot of very risky scopes granting full access to a user's account and repositories.
Once authorized, the attacker has extensive access to the account, from which point they can modify repositories to conduct further attacks against users (e.g. by infecting them with malware), poison the repos and services connected to the repository, and exfiltrate any sensitive data the account has access to.
Alongside consent phishing, this is an example of in-app phishing, which avoids delivering the message via corporate email. Even if the target gets an email notification, the phish isn’t delivered via email directly, and so email-based scanning solutions won’t detect it — they’ll receive a legitimate notification email directly from GitHub. It’s also less likely to raise suspicion as GitHub issue notifications are expected, increasing the click chance.
2. Not really consent phishing?
This example is much more unusual. In this case, the attacker used malicious Microsoft OAuth apps impersonating Adobe and DocuSign.
Rather than trying to grab lots of juicy permissions for Microsoft, the attacker used consent phishing to prevent automated analysis of their phishing page by security tools. To be served the real phishing page, you need to first authorize the fake OAuth app — meaning that security tools and bots won’t be able to reach the page to determine if it’s malicious or not.
The attack started with attackers sending phishing emails to target users with a fake password reset lure.
Because the initial phishing link directs to the legitimate login.microsoftonline.com URL, it appears legitimate and bypasses common domain-based security checks.
After clicking the link, the user signs into their real Microsoft account (this might even happen automatically if the user is already signed in on the device/browser they’re using). They are then redirected to a permissions request page for the fake OAuth app.
The permissions requested by the app (profile, email, openid) are so limited as to be basically unexploitable. They are also the same permissions you would accept if you were authorizing Microsoft to perform a social login (SSO via OIDC) to a third party app.
Clicking the link redirects the victim to the malicious page but masks it using the legit Cloudflare Turnstile service. As well as making the page look more credible (since its fronted by a legit service to block bots) this is a common detection evasion technique we’ve blogged about previously which prevents security solutions from accessing and analysing the malicious page.
After completing the verification, the page (and the malicious phishing kit element) is finally loaded. If the victim authenticates, the session will be stolen by the attacker, along with the captured credentials and MFA code.
Using consent phishing to evade detection
The attacker is essentially using their fake OAuth app to prevent security analysts and bots from analysing the real phishing page, because the first page loaded is a link to a legitimate Microsoft domain. They’re also layering it with a range of other detection evasion techniques like using Cloudflare Turnstile.
We’ve previously blogged about how attackers are using layered detection evasion techniques to circumvent typical phishing page detections, which are often email-based, including:
Prevent analysis of phishing pages by security bots, including using legitimate services like Cloudflare Workers and Turnstile (as above), CAPTCHA, and various sandbox-aware techniques to ensure only the intended victim is served the phishing page, such as only providing the correct parameters to load the page if the correct path is followed (rather than attempting to load the malicious page by going directly to the domain).
DOM and visual obfuscation of phishing pages when the victim does land on the page to prevent it from being identified as malicious through signature-based detection of page elements.
This seems a bit overkill and many of the steps here are likely to raise suspicion — like the fact that you’re never asked to provide the original code for the password reset, and are asked to unexpectedly consent to an OAuth app. But clearly, the attacker is more concerned about bypassing technical safeguards than human ones (not a great endorsement for the state of phishing awareness training).
How Push detects and blocks phishing attacks
Push overcomes the various detection evasion techniques shown here by using in-browser detections based on the phishing page that the user sees. This means that no matter where the user accesses the link from (email, IM platform, social media, or anywhere else on the internet) Push can observe and analyse the page to determine if it's malicious.
Push uses layered detections based on identifying the phishing kit running on the page itself, whether the page is cloned from a legitimate login page, as well as detecting whether the credentials being entered on the page have been used to log into your SSO account previously.
By fingerprinting the password for your most important accounts used to log into IdPs like Microsoft, Google, Okta, etc. Push can prevent users from entering this password into any other page. So for example, if the user attempts to enter their real Microsoft password onto a phishing page, Push detects and intercepts it, blocking the phishing attempt.
You can’t phish a victim if they can’t enter their credentials into your phishing site!
Using Push to review OAuth integrations
You can also use Push to discover and remove risky OAuth integrations accepted by your users.
This shows which OAuth apps have been added, which apps they are integrated with, what permissions they’ve been granted, as well as other properties that indicate risk (e.g. whether the app’s publisher has been verified).
If your users are consent phished, you’ll be notified via webhook event that a new integration has been added. These risky integrations can be removed via the Push platform by clicking ‘delete integration’.
We don’t just stop phishing attacks
It doesn’t stop there — Push provides comprehensive identity attack detection and response capabilities against techniques like credential stuffing, password spraying and session hijacking using stolen session tokens. You can also use Push to find and fix identity vulnerabilities across every app that your employees use like: ghost logins; SSO coverage gaps; MFA gaps; weak, breached and reused passwords; risky OAuth integrations; and more.
If you want to learn more about how Push helps you to detect and defeat common identity attack techniques, book some time with one of our team for a live demo.
