Open authorization or “OAuth” apps add business features and user-interface enhancements to major cloud platforms such as Microsoft 365 and Google Workspace. Unfortunately, they’re also a new threat vector as bad actors are increasingly using malicious OAuth 2.0 applications (or cloud malware) to siphon data and access sensitive information. In 2020, Proofpoint detected more than 180 different malicious applications, attacking over 55% of customers with a success rate of 22%.
We have observed many forms of OAuth token phishing attacks and OAuth app abuse, which is ideal for attackers to conduct reconnaissance, launch employee-to-employee attacks, and steal files and emails from cloud platforms. Malicious app attacks often target the accounts of vice presidents, account managers, human resources representatives and chief financial officers—the kinds of users with access to highly sensitive data. If successful, attackers gain persistent and independent access to emails (including read, write, send and setting mailbox rules), files, contacts, notes, Microsoft Teams chats and more. In some cases, they redirect users to a phishing site after the user consents to the application.
Malicious OAuth apps in 2020
In 2020, attackers used many techniques, such as application impersonation methods (like homoglyphs and logo or domain impersonation) and lures (like COVID-19, mail quarantine and office reviews from peers). The sophisticated attacks even relied on Microsoft’s platform to generate invitations to the malicious application consent page.
Microsoft, to control the growing problem of malicious third-party apps, initiated a publisher verification mechanism—and has seen limited success. In fact, Proofpoint researchers have observed bad actors creating applications in compromised tenants to bypass this verification process. They use the tenant’s trusted identity to distribute malicious applications widely.
How does Microsoft authenticate app publishers?
Microsoft realized in late 2020 that authenticating app publishers can play a vital role in helping to mitigate the malicious OAuth apps threat. So, it created the publisher verification mechanism to provide end users with a credibility factor on the application publisher. This process binds the publisher to a verification process where:
- The publisher must be a valid Microsoft Partner Network member.
- The publisher’s account must be part of a verified tenant (including the listed publisher domain).
- The publisher must agree to the “Microsoft Identity Platform for developers” terms of use.
Microsoft also checks the tenant bills and activity. The whole process of verification is a complicated and unrewarding procedure from the attacker’s standpoint.
Aside from placing a verification badge on the consent screen for an application from a verified publisher, Microsoft also added a policy that allows administrators to preclude users from consenting to an application from a non-verified publisher. In addition, applications published after November 8, 2020, are coupled with a consent screen warning in case the publisher is not verified, and the tenant policy allows the consent.
Has Microsoft succeeded in stopping malicious OAuth apps?
The short answer: No. Although publisher verification has vastly reduced the activity of cloud malware, the threat hasn’t been mitigated completely. True to form, the attackers have changed their tactics. Now, they’re compromising accounts in credible tenants first. Then, they’re creating, hosting and spreading cloud malware from within.
Cloud account compromise is a widescale problem, with 95% of cloud tenants targeted by one or more campaigns and more than 50% of all tenants compromised.
The post-compromise activity is vital. Attackers access sensitive information via emails and files, plant malware, leak data, perform lateral movements via mail, and abuse applications to achieve persistence with a low footprint. Sometimes, attackers will create an application in the compromised tenant, using its identity to bypass Microsoft’s publisher verification and share the application widely.
How Attackers Create Malicious Apps in Credible Cloud Tenants
An attacker would first create their malicious code and host it on a web server, accessible via a URL (malicious app URL). After compromising the target cloud account, the attacker then creates an application in the “app registrations” section in Azure portal, marking the application as “multi-tenant application” with the “web” settings, adding the malicious URL of their code to the application. As the malicious code requires access permissions to resources, the attacker adds the relevant permissions on the applications page, under the “API Permissions” tab.
Figure 1: How Attackers Create Malicious Apps in Credible Cloud Tenants
Attackers can also use the following CLI command for creating the application:
The “manifest.json” file includes the required scopes for the application. For example, adding “mail.read” and “mail.send” permissions requires the following JSON:
An “offline_access” permission is needed to create a refresh token, which means the user isn’t involved in creating the access token for the application.
Once this activity is complete, no further action items are required in the compromised account, unless the attacker wishes to consent to the application on behalf of the attacked account owner. Distributing the application widely will require a URL to the application consent page. This requires the application (client) ID and the malicious app URL:
The attacker can use this link as part of phishing attacks, clickjacking and other attack types to compel the user to consent to an application. Once an attacked user consents to an application, the attacker can generate OAuth2.0 access tokens on the user’s behalf and access the permitted resources.
This activity not only bypasses the publisher verification mechanism, but it also makes identifying malicious apps more difficult. That’s because the tenant’s credibility can no longer be used as a key parameter in evaluating an application. For account owners, trusting the application publisher is no longer sufficient.
Among the thousands of tenants we monitor, Proofpoint has detected several tenants hosting what appear to be one or more malicious OAuth apps, affecting multiple other tenants.
Takeaways and recommendations:
- Use Microsoft’s “verified publisher” policy. While some credible tenants host malicious applications, non-credible tenants host the vast majority of cloud malware.
- Decide who can create an application. Microsoft allows admins to prevent non-admin users from creating applications with a policy. That should reduce the risk of attackers compromising non-admin accounts and creating applications in the tenant environment. However, it can also create an overload on the admins if application creation activity is common within your organization.
- Reduce the attack surface by:
- Not consenting to any application unless required.
- Reviewing the permissions requested by the application.
- Reviewing the source of the application.
- Revoking unused applications constantly.
- Reviewing post-authorization activities by all applications from every source.
How can Proofpoint help?
Proofpoint Cloud App Security Broker (Proofpoint CASB) detects, assesses and revokes OAuth permissions for the third-party apps and scripts that access your IT-approved core cloud services. Our in-depth analysis helps identify risky apps, including malicious ones, and reduce your attack surface. Based on risk score and context, you can define or automate actions. For example, you can manually or automatically revoke OAuth tokens for Microsoft 365 and Google apps that can pose a risk if abused.
Protect users and data with Proofpoint’s people-centric security for cloud apps. Proofpoint CASB combines compromised account detection, data loss prevention (DLP), cloud and third-party apps governance with adaptive access controls to help you secure Microsoft 365, Google Workspace, Box, Salesforce, Amazon Web Services (AWS), Azure, Slack and more.
For more information on how a CASB can help you secure cloud applications, download the Proofpoint white paper, “Getting Started with CASB.”