Cloud Security , Security Operations
Mitigating the Risks of Malicious OAuth AppsProofpoint Sizes Up the Cloud Security Battle
Attackers are increasingly using malicious OAuth 2.0 applications to siphon data and access sensitive information from a wide variety of cloud platforms, and mitigating the risks is proving challenging, according to the security firm Proofpoint.
See Also: LIVE Webinar | Stop, Drop (a Table) & Roll: An SQL Highlight Discussion
In 2020, Proofpoint detected more than 180 malicious OAuth 2.0 applications attacking over 55% of its customers with a success rate of 22%.
Microsoft introduced a Publisher Verification mechanism for Microsoft Partner Network accounts in Azure AD to help stop malicious OAuth apps targeting its cloud platforms, such as Office 365. This has had "limited success" in reducing cloud malware intrusions, and many challenges remain, Proofpoint and other security experts say.
OAuth is an open standard for authorization that allows a user to grant a third-party application continuous access to a cloud service by using an access token without needing to give it a password.
"Malicious app attacks often target the accounts of vice presidents, account managers, HR representatives and CFOs - the kinds of users with access to highly sensitive data," Proofpoint says. "If successful, attackers gain persistent and independent access to resources, such as emails - including read, write, send and setting mailbox rules - files, contacts, notes, Microsoft Teams chats and more. They redirect users to a phishing site after the user consents to the application."
Although attacks using malicious OAuth 2.0 applications are not yet widespread, they've been observed in the United States, Australia and France, says Assaf Friedman, a Proofpoint threat research engineer.
But Cloud account compromises are common, Proofpoint says. About 95% of cloud tenants have been targeted by one or more attack campaigns and more than 50% have been compromised, the security firm reports.
Chris Morgan, senior cyberthreat intelligence analyst at Digital Shadows, says that although Microsoft plays a big role in stopping the spread of malicious OAuth applications, organizations in all sectors must step up their efforts.
"These organizations should govern their use of OAuth applications through active observation and management of the various permissions granted through the applications," he says. "Understanding what third-party applications your employees use is also essential before deciding whether the use case of the applications warrants any potential risk."
Critiquing Microsoft's Efforts
Microsoft's Publisher Verification mechanism has had some success in addressing cloud malware risks, Proofpoint says. But some experts say it has shortcomings.
"Unlike other trust relationships which require access to a carefully protected private key, the mechanism which Microsoft has devised to blunt malicious OAuth apps is quite weak," says Oliver Tavakoli, CTO at the security firm Vectra AI.
"Once an attacker breaks into an organization’s Azure footprint, simply registering an app is relatively trivial - and this app then takes on the trust associated with the infiltrated organization. A user from the next targeted organization won’t even get a warning that the app may be malicious before granting it access. Malicious OAuth apps are particularly gnarly, as resetting the password for the originally compromised account won’t withdraw access to the authorized app. So post-forensic cleanup often is incomplete."
A spokesperson for Microsoft did not immediately reply to a request for comment.
In 2020, attackers used several techniques to deliver malicious OAuth 2.0 applications, including application impersonation methods and lures, such as COVID-19 themes, mail quarantine messages and office reviews from peers, Proofpoint says.
Some sophisticated attacks even relied on Microsoft’s Azure to generate invitations to the malicious application consent page, according to Proofpoint (see: SolarWinds Attackers Manipulated OAuth App Certificates).
Assessing Publisher Verification
In a new report critiquing Microsoft's Publisher Verification system, Proofpoint describes how it works and how some attackers manage to get around it.
"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," Proofpoint researchers note. "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."
Proofpoint says that 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, using the compromised identity to bypass Microsoft’s Publisher Verification and share the application widely.
"After cloud account compromises, 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."
Threat actors create malicious code and host it on a web server, accessible via a malicious app URL, Proofpoint says. Once the target cloud account is compromised, the attackers can start creating an application in the "app registrations" section in Azure portal, marking the application as "multi-tenant application" with the "web" settings and adding the malicious URL of their code to the application, the researchers note.
"As the malicious code requires access permissions to resources, the attacker adds the relevant permissions on the applications page, under the 'API Permissions' tab. The attackers further use a CLI command for creating the application, which includes a JSON Web Token called 'manifest.json' file, which requires scopes for the application," Proofpoint says.
In addition, an "offline access" permission is required to create a refresh token, which means the user isn’t involved in creating the access token for the application. Upon completion of this activity, no additional action is required in the compromised account, unless the attacker wishes to consent to the application on behalf of the attacked account owner, according to the researchers.
"The accounts that are targeted with the creation of the application aren’t necessarily able to access sensitive data. However, such accounts are indeed highly targeted by the malicious applications (in the distribution phase). Proofpoint analyzed such attacks, with the main focus being the technique of the creation and distribution using the attacked tenant identity," Friedman notes.
Researchers say that the distribution of the application requires adding a malicious URL to the application consent page.
The attacker uses this malicious link as part of phishing attacks, clickjacking and other attack types to compel the user to consent to an application, and the attacker generates OAuth 2.0 access tokens on the user’s behalf and gains access to the permitted resources, the Proofpoint researchers note.
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, the researchers say.
Proofpoint researchers detected several tenants hosting what appear to be one or more malicious OAuth apps, affecting other tenants. Friedman states that they observed several applications, such as Email Client, Settings and Enabler4Excel, utilizing this technique.
"This technique was spotted prior to the implementation of the Verified Publishers mechanism. However, its goal was to improve the impersonation phase of the attack, rather than bypass the mechanism. In all of the observed cases, the application redirects the users to a broken link or a real application (such as mail clients) and has no further user interactions, which aren’t required once the token is granted. As those apps utilize a refresh token, the end user doesn’t have to log in to the malicious app after consenting," Friedman states.
Proofpoint researchers recommend using Microsoft’s "verified publisher" policy.
"Decide who can create an application," they say. "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."
In addition, researchers recommend reducing the attack surface by not consenting to any application unless required; reviewing the permissions requested by the application, the source of the application and post-authorization activities by all applications from every source; and constantly revoking unused applications.
The accelerated move to the cloud during the pandemic has led enterprise security teams to recreate an enterprise network using thousands of identity and access management rules, virtual private cloud controls, and peculiarities of cloud-native services, which can cause problems, says Mohit Tiwari, co-founder and CEO at Symmetry Systems.
"Cloud services also permit developers to make significant errors quickly unless the cloud and security teams have put virtuous guardrails in place," he says. "Therefore, speed and permissions sprawl makes for a tricky combination.
"Because cloud workloads are designed to be containerized and fault-tolerant, and security teams can place several layers of IAM and detection-response defenses that operate at machine speed, they are likely a safer alternative to legacy workloads on static infrastructure."