This blog was co-authored by Obsidian Product Manager Tim Wenzlau and Staff Security Researcher Noah Corradin.
SaaS environments are a complex web of interconnectivity between SaaS platforms, third-party applications, and custom in-house integrations. This very benefit of SaaS can also act as a threat vector for attackers who are increasingly targeting integrations as entry points into an enterprise’s wider SaaS environment. An attacker who’s able to exploit integrations has the opportunity to establish persistence, make changes, and exfiltrate valuable data—oftentimes evading detection by traditional security measures.
In a previous blog, we defined OAuth applications, explored their benefits and risks, and broke down Obsidian’s approach to mitigating the growing threat of OAuth abuse. The topic has continued to gain visibility with its inclusion in recent high profile threat campaigns: GitHub, OiVaVoii, UNC3524, StellarParticle, and SUNBURST are just a few examples. These attacks take advantage of vulnerabilities across the SaaS supply chain and within internally developed applications.
To expand our threat detection capabilities and address the growing threat vector of OAuth abuse, our team has released several cutting-edge OAuth threat detections purpose built for protecting Microsoft environments. Specifically, these address internal application compromises, supply chain risks, and device code flow abuse. In this blog, we explore each of these unique threat vectors and explain Obsidian’s approach to mitigating these attacks.
Internal Application Compromise
Most organizations have several—if not hundreds—of internally developed applications connected into their corporate Microsoft environments. These applications can serve various purposes such as managing data or mail, provisioning users, and automating administrative functions.
Security teams often don’t examine these internal applications particularly closely, and depending on their Microsoft license, they may not even have granular logs of application activity available. Attackers are well aware of these vulnerabilities and look to exploit these applications to gain privileged access to the Microsoft environment.
The Russian hacker group known as Cozy Bear leveraged several techniques to compromise internally developed Microsoft integrations in their StellarParticle campaign which allowed them to establish persistence and carry out various attack objectives in target environments. In many cases, attackers remained undetected for months on end.
StellarPartical used a compromised Microsoft 365 administrator account to create a new integration with a generic name. Subsequently, they utilized this integration to add credentials to a second internal company-created integration which had the ability to read all mail on behalf of all users within the organization.
To mitigate these forms of internal application compromise, Obsidian continuously profiles the behavior of internally developed applications. When our models identify unusual and high-risk activities, security teams are immediately notified and able to take prompt remedial action.
Integration Supply Chain Risk
External third-party vendors are a necessary risk in today’s integrated SaaS ecosystems. Many organizations attempt to reduce this risk by conducting thorough vendor security reviews of the third party’s access into their environment. But what happens if that vetted third party is compromised after your organization has conducted a review and approved them?
In the recent GitHub breach, it was not GitHub that was compromised, but rather the access of supply chain partners Heroku and Travis CI. In the SolarWinds breach, email security vendor Mimecast was breached, enabling attackers to leverage Mimecast’s access into customer’s Microsoft 365 mailboxes.
Obsidian’s approach to mitigating supply chain risk is similar to our internal application compromise detection. We start by identifying and inventorying all third-party integrations with high risk access into the Microsoft environment, building a profile of their typical behaviors and activity patterns. Our machine learning models continuously evaluate the way these integrations are behaving to identify sudden changes that likely indicate a compromise. With this prompt detection, security teams are able to take timely corrective actions to minimize an attacker’s persistence and their ability to exfiltrate sensitive data.
Device Code Flow Abuse
Microsoft supports authorization via a device code flow which allows users to sign into Microsoft environments from input-constrained devices such as a smart TV, IoT device, or printer. Many average consumers are already familiar with this form of authentication—it’s what you might see when logging into Netflix or any other streaming service with a smart TV remote.
In this authorization flow, there’s no actual validation that the user is logging in from an input constrained device. Though infrequent, there are valid use cases for implementing these authorization sequences for Microsoft SaaS environments.
Obsidian detects attackers abusing device code flow to impersonate existing integrations, including first-party Microsoft applications like those in the Microsoft 365 suite. These attacks often convince users to reauthenticate valid integrations while they unknowingly approve an attacker’s entry into the environment. They often follow five simple steps:
- Phishing: The attacker crafts a phishing email, potentially pretending to be Microsoft asking the user to reauthorize a valid integration (such as Microsoft Office). The phishing email would contain a device code generated by the attacker and the authorization URL where the user needs to input that code (login.microsoftonline.com/common/oauth2/deviceauth). This phishing email would likely evade phishing detection email filters because the URL is a valid URL owned by Microsoft and commonly used for legitimate device code authorizations.
- The user receives and enters the authorization code.
- The user selects their Microsoft account for the integration to connect to.
- The user is prompted with a confirmation dialogue and accepts.
- The attacker is granted access to the Microsoft environment with all the privileges of the application they impersonated.
In this example, where the impersonated application is Microsoft Office, the attacker is able to download the user’s entire collection of files, access their emails, and send emails on behalf of the user.
