Consent phishing: How attackers abuse OAuth 2.0 permissions to dupe users

When cybercrime historians look back on the first half of the 21st century, they will undoubtedly point to phishing as the most successful, and therefore, the most prevalent technique used to circumvent security. One of the reasons for this success is the ability of the cybercriminals behind phishing to work out novel ways of using the technique. The latest line of phishing tactics is ‘consent phishing.’

Two year's worth of NIST-aligned training

Deliver a comprehensive security awareness program using this series' 1- or 2-year program plans.

Book a Demo

What is consent phishing?

To understand consent phishing, you need to understand the mechanisms it relies on, namely:

• The user’s urge to click
• The OAuth 2.0 protocol

The urge to click

Cybercriminals put the human factor to great effect in social engineering exercises. We humans (the computer users) are trained to use the internet by clicking links; click the link to get to the next stage of whatever you were trying to do. One modern click to go to the next stage, which we are all too familiar with, is the ‘click to consent.’

Consent to login and share data boxes is part of the mainstay methodology used across a wide range of consumer and corporate apps from Google to Facebook to Office 365 and beyond. Behind the consent box lies the standard protocol OAuth 2.0.

OAuth 2.0

OAuth 2.0 is an authorization protocol and an important industry standard. It makes the login process easier within and across websites, online apps and mobile apps; OAuth 2.0 supports Single Sign On (SSO) to allow for seamless use of apps. It is widely used because of its flexibility, the wide availability of plug-in libraries, and improved usability for end-users when handling consented access to data. It hinges on the user consenting to give the RP access to data hosted by a provider, such as Microsoft 365.

Millions of websites and apps rely on OAuth 2.0 to operate. When a person signs in to access a website or app (i.e., a relying party or RP), this access is typically handled using an OAuth 2.0 authorization exchange: following user login and consent, the provider issues an access token used by the RP to access the data that the user has consented to share, which may be as little as an email address or access to documents, etc. Here’s an example of an OAuth 2.0 consent box:

How user consent facilitates phishing

The problem with this OAuth 2.0 exchange is that anyone can potentially register a malicious app (RP) with the provider. This opens the gates for cybercriminals to take advantage of a legitimate OAuth 2.0 authorization exchange.

In a consent phishing campaign, a cybercriminal follows these steps to steal an OAuth 2.0 bearer token, and with it, the user’s data and access credentials:

1. Cybercriminal registers malicious app with an OAuth 2.0 provider, e.g., Office 365, Azure Active Directory etc.
2. They send out a phishing message (spear phishing or scattergun) linked to the malicious URL.
3. Once the user clicks the link, the app opens, logs in and generates an OAuth 2.0 consent box.
4. The user clicks to consent to share the required data.
5. An authorization code is generated and sent to the attacker.
6. This code is used to request an access token that makes API calls to access the consented data, including email data, contacts, forwarding rules etc.
7. On a side note, a refresh token is often included in OAuth 2.0 exchanges. This could potentially allow persistent access to consented data.

Systems based on the OAuth 2.0 protocol are neat systems that make the web work seamlessly. Still, this in-built accessibility can also provide data on a plate to anyone who knows how to take advantage of the working parts.

Consent phishing in the real-world

An investigation into consent phishing by Microsoft has found that fraudsters create apps with legitimate-sounding business productivity apps such as “Enable4Calc,” “SettingsEnabler” or “Settings4Enabler” to trick OAuth 2.0 providers as well as users.

In a case study explored by Microsoft, the company found that consent phishing emails continued to use tried and tested social engineering tricks. The email was branded with a spoof but legitimate-sounding business growth solutions company in one real-world example. In this scenario, the consent phishing email also tricked users by playing on a sense of urgency and concern to review and sign an important business document. One of the more subtle but devastating aspects of the campaign was that the link to the document looked real because the app had been properly registered with an OAuth 2.0 provider.

The legitimate components within a consent phishing campaign make it more dangerous than other campaigns. Even the use of security measures such as second-factor authentication is no match for consent phishing. The attack happens after the credentials have been entered and then acts post-authentication to carry out persistent access to user data. This legitimacy makes it even harder to spot a consent phishing attack.

Way to stop consent from becoming an attack vector

The security industry fights back by putting hurdles to make it harder to take advantage of human behavior or additional security such as second-factor authentication. However, consent phishing has been designed to use the authorization part of the user journey and to act within that journey as a legitimate OAuth 2.0 consumer.

The prevention of clever attacks such as consent phishing is not an easy fix but instead requires a series of preventative measures to be employed.

Detection of malicious apps

Cloud app security brokers can be used to control OAuth 2.0 connected apps by detecting malicious app activity. These cloud-based services provide visibility into connected apps across an enterprise, monitoring activity and looking for anomalous behavior.

Whitelist apps and use step-up consent policies

Within a corporate context, a whitelist of trusted apps can be set up so that consent can only be given to apps from internal developers or known and trusted publishers. Microsoft Azure Active Directory can be used to enforce consent policies. The policies are based on a risk profile of an app. For example, a newly registered multi-tenant app where the publisher is not yet verified might be an at-risk app, and end-users would not grant consent.

App and consent security awareness

Training both users and administrators on consent phishing tactics. This should be incorporated into general security awareness training to help to prevent attacks.

Get six free posters

Reinforce cybersecurity best practices with six eye-catching posters found in our free poster kit from our award-winning series, Work Bytes.

Download Now

Consent phishing and app verification

The verification of apps that utilize OAuth 2.0 is a general industry issue. Work is ongoing on how to deliver a more trusted transactional internet. Much of this work is focused on creating trust across related parties. However, in the area of consent phishing, one of the key issues is in the verification of the RP, i.e., the fraudster’s app. Verification of apps is an onboarding issue, and the solution is contained deep within the usability and security of the relevant stakeholders. Verification of apps should always be done securely, with robust KYC (Know Your Customer) type checks carried out before being co-opted into an OAuth 2.0 facilitated system.

Consent phishing is a novel way of using the very structures (standard protocols) that allow the internet to operate effectively. This "man at the front door" approach to phishing is a hard attack method to control. Using methods that include app verification and threat detection, and employee security awareness can go a long way to reducing the risk.

Sources 

• OAuth 2.0 User Authentication and Consent For Clients, ietf.org 
• Microsoft delivers comprehensive solution to battle rise in consent phishing emails, Microsoft
• Tutorial: Investigate and remediate risky OAuth apps, Microsoft