The use of application-based phishing campaigns is not new in the threat landscape, and there have been a couple of honorable mentions since 2014. However, recent high-profile events affecting large number of users and services have brought them to the news again, in updated shapes and forms. This blog discusses these types of attacks, focusing on the more recent OAuth consent-based lures.
Introduction
Cloud-based applications are spreading across the entire Internet ecosystem. Developers can easily build applications that integrate with users and organizations by accessing their data directly from cloud platforms. The digital transformation has even accelerated this process, which in most cases relies on these processes to enhance and tailor as much as possible the user journey.
Knowing this scenario, malicious actors started to leverage the fact that users are bombarded with dozens of applications that connect to their accounts and identities and entice them into providing access to their valuable data. While most phishing attacks focus on the users themselves, application-based attacks use a cloud-enabled application as their main vector to access the victim’s information.
OAuth Flows and Authorization Consent
The type of attack, the OAuth 2.0 Framework, will be our focus. The specification of IETF’s RFC 6749 is described as:
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
In a simplified way, the main purpose of the specification is to define a standard process for providing clients with a secure way to access delegated resources on behalf of the resources’ owner. The process specified includes the mechanism for the resource owner (e.g. an application’s end user) to authorize a third-party client (e.g. a cloud application) to access its data or resources. This authorization is then expressed as an access token that is issued to the third-party, and that can be used to access the protected resources.
Consent Request from “Risky App”
The more relevant step in the process for what we’re reviewing in this article is the user’s approval or “consent”. For this step to be as secure as possible, critical conditions must be met and if not met, this flow is open to a wide range of potential abuses, enabling the notion of consent-based phishing attacks.
Anatomy of an Application-based Phishing Attack
Application-based attacks share a similar structure although vary according to the attack techniques, the application used to deceive a user or the abused OAuth flow. Application-based phishing attacks would have a similar flow as in this diagram:
Basic application-based phishing attack flow
- The attacker reaches the victim via email, social media or other means, impersonating a target service. In some cases, it might be targeted to some service that is known the victim uses. The initial contact includes a link to a legitimate identity provider service, or an attacker site that then redirects to the legit service.
- Upon clicking on the link, the victim is taken to a login page. This can be for example Office 365, Google Account, or any other legitimate identity provider service.
- The victim provides their credentials and authenticates to the identity provider. This can be using username and password but can also extend to providing Multi-Factor Authentication methods, authenticating with password-less, or other forms of strong authentication. Note that up to this point, the user might have interacted with valid and legitimate services, with all well-known security measures in place.
- After authentication, the user is then prompted with the infamous consent page. The permissions and scope of the authorization requested might vary, but generally includes not only reading profile and user’s data, but in some cases also modify elements on the victim’s account. The consent page includes details about the application for who’s access is being requested.
- Once the user grants access to the impersonated target service, the attacker-controlled app now has access to the victim’s account with the permissions allowed. The attacker can then automate the process of collecting victim’s data, accessing services on his/her behalf, etc.
From a threat tracking perspective, this technique is referenced as Steal Application Access Token (T1528) in the ATT&CK matrix. Related techniques are also Spearphishing Link (T1566.002) and Use Alternate Authentication Material: Application Access Token (T1550.001).
Application-based Phishing Variants Through Recent History
One of the first cases of OAuth authorization flow abuses in the context of phishing was Andrew Cantino’s post on an issue affecting Google Apps Script in 2014. This issue relied on the fact that the user experience didn’t make it clear that granting access to a Google Apps Script allowed the 3rd-party code to perform almost any action with the victim’s data. At that time, the vendor treated the behavior as “working as designed” and didn’t consider the report as a security vulnerability.
Back in April 2017, Trend Micro reported on a campaign from the Pawn Storm threat actor that involved the abuse of OAuth as part of their social engineering techniques. While not the first, this becomes one of the clearest malicious uses of techniques that involved application-based phishing at that time. This episode was followed by a Google Docs “phishing worm” that replicated itself by abusing OAuth’s consent to get access to the victim’s contact list and send additional permission requests. This campaign was quickly turned down by Google, as reported by ArsTechnica in a couple of articles.
Another description of practical application-based phishing attacks was shared by Etienne Stalmans in his blog post from 2017 “Phishing with OAuth and o365/Azure”. In the article, Etienne describe the technique using Microsoft’s Office365 applications and define it as a “stealthy” way to perform phishing.
In May 2018, Douglas Bienstock shared related examples in an article in FireEye’s blogpost “Shining a Light on OAuth Abuse with PwnAuth”. Like previously mention, the article introduces the abuse of OAuth applications during social engineering attacks, by asking the victim to allow access to its account to a malicious third-party application. The article was covered in length also in subsequent articles and episodes of the State of the Hack podcast.
Amnesty International unmasked several attacks that targeted civil society organizations during 2019. One of those, focused on organizations from Egypt, leveraged Google’s third-party applications to access victim’s accounts. Another campaign, focused on organizations from Middle-East and North-Africa, used password-stealing phishing techniques but also included phishing lures looking to get into Microsoft Outlook’s accounts.
We can also refer to a set of high-profile attacks that leveraged the ability to create cross-tenant third-party applications in Microsoft’s Office 365 and targeted accounts. Some of those attacks began in 2019 and involved several campaigns from allegedly multiple actors, involving not only phishing but also BEC (Business Email Compromise) scams and ended up with legal actions and takeovers, as well as major changes in Microsoft’s infrastructure.
Finally, phishing schemes can leverage flawed federation flows as well. This is the case of, for example, the OAuth Device Code Authentication. This flow carries some inherent security risks that are clearly stated in the specification and started to become target of malicious campaigns recently. Some examples are publications demonstrating the phishing vector against Office 365 applications and AWS’ SSO implementation.
Tools and Detection Guidelines
Whether you’re working on better understanding these techniques, planning for doing user awareness training, or just testing your defenses and detection capabilities around these techniques, it’s always useful to have practical tools around. Through the years and some of the research pieces we’ve mentioned, several tools have become available to build and simulate this type of attack. The following are some tools that can be used from an offensive perspective:
- PwnAuth: Douglas Bienstock from Mandiant published PwnAuth, which allows launching and managing OAuth abuse campaigns from a Web-based application built on top of the Django framework.
- PhishInSuits: A more recent tool published by SecureWorks that allows for abusing OAuth’s Device Code Flow.
- o365-attack-toolkit: A toolkit from MDSec to not only simulate phishing attacks but also leverage compromised tokens to access victims’ emails and documents.
- aws-sso-device-code-authentication: A set of Python scripts to target AWS SSO OIDC applications and abuse the flaws in OAuth Device Code Authentication flow.
From a detection standpoint, there’re several guidelines available according to each identity provider and how access to the OAuth grants and other indicators can be obtained to look for suspicious activity. Worth mentioning is Douglas’ OAuthHunting script to gather suspicious grants in Microsoft’s Office365 environments.
Prevention and Mitigation of Application-based Phishing Attacks
The increase in prevalence and impact of this type of attack pushed some cloud identity providers and vendors to make their move and close some of the doors for abuses. Aside of fixing individual reported implementation bugs, last October 2020 Microsoft announced three main changes on how the Azure platform handles consent requests:
- Implemented a verification process for application publishers, which allows developers to add a verified check that’s visible by the end user on the consent page.
- Disabling consent to new multi-tenant applications from unverified publishers.
- And finally, allowing to set per-tenant policies about how to handle user consent.
The changes were also accompanied by guidelines and playbooks for the detection of this type of attack.
Overall, and in addition to the platform’s efforts such as the ones highlighted here, that incorporating this type of phishing attack into security awareness and defensive playbooks is going to improve prevention and mitigation.
Conclusions
Innovations in threat operations force security teams to be vigilant and update their playbooks. In this case, the rise of consent and application-based phishing lures requires an increased effort on not only implement defensive measures, such as limiting third-party applications in shared cloud infrastructures but also teaching employees and users about the risks of these new methods. Things that were safe a time ago, might require adjustments as new attack methods are revealed.
Feel free to reach me on Twitter as @martingalloar or email our SecureAuth Innovation Labs team using labs@secureauth.com!
