Decoding Consent Phishing: How Attackers Exploit User Consent for Malicious Intent

Phishing attacks are ubiquitous in modern times, and take different forms depending on the objective that the attacker has.

Two of the most common types of phishing attacks used in the wild are credential phishing and payload phishing. Credential phishing attacks try to trick users into disclosing their credentials to the attacker; often by imitating a legitimate application login page, such as the main corporate Microsoft login screen (legitimately available at https://login.microsoftonline.com/). Payload phishing attacks, instead, try to trick the user into downloading and executing malware on their system; these files are often masquerading as common file types, such as macro-enabled word documents, OLE office documents or PDFs. These kind of phishing attacks have always existed in one form or another since internet communications were used by people who had access to valuable systems or information.

This blog post investigates the third, newer, type of phishing, Consent Phishing. Consent Phishing aims to exploit how modern Single Sign-On (SSO) systems and Identity Providers (IdPs) work to trick users into granting malicious actors access (consent) to their accounts or information.

What are we giving consent to?

Before we dive deeper into the dangers of Consent Phishing, and a more in-depth explanation of the attack vector, it is important to understand what the concept of “consent” means in this context. Consent is something given by a user to a Software as a Service (SaaS) application that allows the application to access the user’s account or information and potentially perform actions on their behalf. For example, a Gmail user could give consent to a SaaS application that allows it to read the user’s emails to detect spam and potentially delete emails that are spam. I’m sure many of the readers of this article are familiar with this when they link a FaceBook, Microsoft, or Google account to a new third-party service and receive a web page asking the user to give the service certain permissions for it to function. An example of the prompt that a user would receive for this is shown in Image 1.

Image 1: Azure AD Consent Prompt

This functionality is extremely useful for applications and the integration of different services; however, like many of the useful tools on the internet, malicious actors can abuse this functionality to try and attack users and companies.

What makes Consent Phishing dangerous?

The ability to grant consent is extremely useful functionality that allows users to give applications granular control over parts of their accounts and information, without giving them full access. However, there is a widespread trend across legitimate applications of all kinds to request an unnecessary level of privilege for the functionality they implement. This can be for a variety of reasons but, most commonly, this allows free applications to be able to harvest more data for use in targeted advertising. As an example, one can simply check the permissions that a massively popular application like TikTok requests:

Image 2: The full set of permissions requested by the TikTok Android App [1]

When this becomes an industry trend, it has the effect of desensitising users to granting applications excessive permissions. This attitude likely carries over to all manner of permission requests, including potentially worrying consent requests from malicious applications.

Given this context, OAuth consent is an example of a hacker’s favourite type of functionality to target; something that is extremely useful, so it is used in many systems, but is also prone to misconfigurations (like excessive permissions) so that attacks are easier to execute.

Consent Phishing, like other attack vectors, has its own uses and disadvantages; in general, some of the things that make Consent Phishing dangerous are:

The consent requests come from legitimate trusted domains, which are likely to make users more susceptible to believing the attacks represent a legitimate request. A consent request for access to a Google account comes from Google’s domain, not the domain of the software making the request.
Consent gives attackers access to the account or information without the requirement of MFA or passwords. Once a user gives consent, a token is given to the software that allows it to perform actions as the user with the privileges received.
It is common for legitimate applications (such as mobile applications) to ask for excessive user consent on things like privileges or data gathering functionality. The prevalence of this likely desensitises users to malicious requests that are asking for excessive permissions.
It can be hard to track which applications have been granted consent. Unless a user is specifically looking for the list of applications with access to their account, it is unlikely that they would encounter it in their common use of an application.

Who is vulnerable to Consent Phishing attacks?

Effectively, any user account that has authorisation privileges that can be obtained with an OAuth flow is vulnerable to Consent Phishing. This would typically be accounts associated with an internet-accessible Identity Provider (IdP).

As an example, Microsoft runs one of the larger public IdPs, providing users with a “Microsoft Account”, which is commonly used for personal Microsoft services like XBox, Personal Office 365 and Onedrive, amongst others. Another Microsoft service, Azure AD, hosts the infrastructure for organisation-specific IdPs. Many large corporations, still running onsite Active Directory for corporate Identity Management, synchronise these corporate accounts to a Azure AD IdP that they control – to enable use of cloud services like Exchange Online.

This makes Azure AD an extremely alluring target for attackers, given the large corporates who use it for their O365 and Azure infrastructure. However, other Big Tech companies, such as Google and Facebook, run public IdPs that are used by many everyday people, and can also be targeted by Consent Phishing attacks.

What are some examples of large-scale Consent Phishing attacks?

Some examples of real-world Consent Phishing attacks against these IdPs follow:

Security researchers at ProofPoint security discovered an Azure application that abused Microsoft’s Partner Program and the resultant Microsoft verification status to phish users and get them to grant access to their emails and sensitive internal information. [2]
Microsoft Threat Intelligence also tweeted about a malicious application called “Upgrade” that can attack and control a victim’s email address. [3]

However, these attacks have not gone unnoticed and Microsoft have implemented some recommendations and protections against Consent Phishing. These include the Verified Publisher program and the ability for Administrators of Azure AD tenants to configure all consent requests to require Admin consent. These are strong defences, especially forcing all consent grants to obtain Administrator approval; however, they do not prevent threat actors from attempting this attack, they just significantly increase the difficulty in successfully doing so.

How does Consent Phishing work?

Consent Phishing is an attack vector that targets OAuth authorisation requests to receive an access token that has permissions to perform specific actions on a user’s account. While this is a legitimate feature in the OAuth specification, it can be abused by attackers requesting permissions they should not have using a malicious application. An example of a legitimate application using OAuth consent would be one that requests email mailbox permissions to read and delete spam messages from a person’s account. The malicious counterpart of this would request the same privileges to read the user’s entire mailbox and potentially send emails to other users impersonating the victim user.

OAuth consent flow

Before we dive into an explanation of how attackers perform a Consent Phishing attack, we need to have an understanding of OAuth and how its flows work to authenticate and authorise users. OAuth was designed to allow a user to authenticate against a single trusted Identity Provider (IdP), which can then be used by other applications to authenticate the user. Applications can also request permissions in order to perform actions on behalf of a user. These permissions are called scopes, as they represent the scope of actions that an application can perform on behalf of the user.

The various steps involved in an OAuth consent flow can be seen in the Image 3:

Image 3: The OAuth2 consent flow (from Microsoft’s Documentation) [4]

A common OAuth flow will start with a user navigating to the web application and authenticating or choosing to give the application privileges over their account. The application will then redirect the user to their IdP’s domain, with a link associated to the requesting web application. For example:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=This-is-a-unique-identifier&response_type=code&scope=Request+scopes

The parameters in this URL are used to identify the requesting web application and the scopes it is asking for; a scope is simply a privilege that would be assigned to the application. For example, the scope called User.Read would allow the application to read the information about the user.

The user will then authenticate with their credentials which proves their identity to the IdP. If a request for authorisation is made, there are two options that may occur going forward. The first option is called implicit authorisation, where users’ consent to a message that explains the permissions that they are giving a specific application – this was shown earlier in Image 1. The second option is code authorisation, where the application provides the user with a code that they input into the authorisation page on the IdP that will then give the application consent to perform actions on behalf of the user.

Once a user has granted a malicious application the necessary privileges, the IdP will provide the application with an access token, ID token and refresh token. The access token can then be used by the application to perform actions and new tokens can be retrieved with the refresh token. An ID token is used to prove the application’s identity and is used for authentication.

Consent Phishing Attack Steps

A high level overview of how a Consent Phishing attack would be performed is as follows:

An attacker chooses a target, either an individual – or employees of an organisation – and develops a premise for a Consent Phishing attack. For example, a loadshedding app that adds blackout times to a Microsoft Teams calendar.
They then select the IdPs to be targeted; they will need to register their application with each IdP being targeted.
While optional, attackers who wish to maintain access for longer periods of time may develop a minimally-functional application based on the selected premise. An attack that uses an application that offers some functionality is less likely to be reported as malicious to the IdP than one that is not functional at all.
The attacker will then need to integrate the OAuth request into the application. They will need to communicate with the user and redirect them to the IdP for authentication and authorisation.
Finally, the attacker needs to have successfully socially engineered the user to both complete the authentication to the IdP and consent to the necessary OAuth permissions. Once this is done, the IdP will send the application an access token that can be used to perform actions on the user’s behalf.
Exploitation and profit.

Future articles will provide a technical reproduction of a Consent Phishing attack for IdPs such as Azure AD and Google.

Remediations

Each IdP has specific remediations that can be implemented to limit or prevent Consent Phishing attacks from being successful. However, the detail around these will be discussed in future articles that deal with the specific configuration for each IdP. This article will instead focus more on the high-level protections that should be implemented, and what training users can be given to thwart these attacks.

Corporate IdP Recommendations

From a technical perspective, the best remediation that can be implemented is a complete restriction on a user’s ability to give consent at the IdP level. Applications can then be given consent to user’s accounts by explicit administrator configuration, if required. If completely disabling user consent is not an option, and user consent is still required in a limited capacity, it should be required that all consent prompts require admin approval before the consent approval flows can be completed, so that administrators can audit permissions granted to external applications.

User Training Recommendations

Administrator control over consent only works in a corporate setting; normal users are the administrators of their own personal Google, Facebook or Microsoft accounts. Normal users’ best defence against Consent Phishing is therefore awareness and critical thinking. This may seem vague, so here are some points that users could consider when a consent prompt appears:

What can the application do with these privileges it is asking for? How much information am I giving this application, and how much control will it get?
Does the application need these privileges to function? For example, a calculator probably doesn’t need admin control over your account.
Do I know and trust the application that is requesting consent? Arbitrary or vaguely named applications should not be trusted, such as an application simply named “Upgrade”.
Is this publisher verified or trusted by my IdP? For example, Microsoft has a verified badge; however, as mentioned earlier, these controls are not infallible, as real-world attacks using verified applications have happened. [2]
Every so often, it is worthwhile to see which applications have access to your account and removing those that are no longer used. If you do need them in the future, you can simply re-authorise them.

General Observations

It is worth noting that Consent Phishing aims to abuse a feature of the OAuth protocol – the ability to grant an external application access to a portion of the data associated with an account, without sharing the account’s credentials with that application – in order to maintain unintended access to that account. It is therefore hard for public IdP providers to simply fix or disable the attack, as valid use cases exist that make use of this functionality.

Furthermore, Consent Phishing, as with many other attack vectors, is ultimately a game of leap frog between hackers and companies that run IdPs. When hackers find new techniques and are able to perform attacks more easily, the targeted companies come up with new security measures that make the attack vector harder for a while. Then attackers work to figure out how to bypass those controls once more, and start abusing the attack vector again, until the next round of security controls are implemented.

Conclusion

Consent Phishing is a dangerous attack vector that can allow malicious actors to use legitimate and trusted IdP login pages in an attempt to compromise user accounts. It targets useful functionality for giving users access to applications to perform actions on their behalf. This attack vector can, by design, be used to bypass trusted and strong mitigations, such as account MFA and prompts for user credentials. However, there are also many strong defence mechanisms put in place on commonly used applications that are worth being aware of. The most important thing you can do to protect yourself is to know about about the attack vector and possible defenses, know what to look for to identify these types of phishing attacks and always question why an application needs access to your information before granting consent.