Defending Against OAuth App-Based Attacks on Enterprise SaaS

The phenomenal growth in the adoption of software as a service (SaaS) has prompted enterprises of all sizes to move their critical data to SaaS-based applications. And as attackers tend to follow data to induce a breach, their new area of focus is enterprise SaaS. The recent Midnight Blizzard attack by nation-state actors clearly reinforces the fact that this trend has only just begun.

One interesting aspect of this attack, as well as other recent attacks on SaaS, is that the attackers leveraged a combination of traditional attack vectors, like poor posture controls around authentication and new attack vectors, likeOAuth based applications. It’s worth mentioning that this attack vector has also recently been leveraged by opportunistic threat actors to automate both business email compromise (BEC) attacks and phishing attacks, as well as  push spam and deploy virtual machines (VMs) for crypto mining. This underscores  the fact that attacks on SaaS apps are not exclusive to state-sponsored groups only. 

The anatomy of an OAuth attack on SaaS apps

Let’s drill into some of the tactics that attackers seem to have used in this attack:

1. Initial Access via password spraying on test tenant accounts.
2. Defense Evasion by using distributed residential proxies in addition to limiting the number of attempts to stay under the radar of systems that keep an eye on the volume of such defense evasion attempts.
3. Persistence by granting access to OAuth applications to maintain access, even if they were to lose access to the account used during initial access.
4. Privilege Escalation using the OAuth application to grant  elevated access to the Microsoft  corporate environment.
5. Lateral Movement via the OAuth application’s elevated access towards Exchange Online.

While the tactics remain very similar to a classic MITRE framework, the  techniques used to perpetrate the attack have evolved enough to exploit the new attack surface left open by OAuth applications.

OAuth applications are the new blindspot

For an end user who is looking to get things done in the most easy and effective way, OAuth applications are a huge blessing because they allow users to interconnect or integrate their apps and data very easily from within the SaaS application they are using, by simply issuing a few commands. Let’s say for example, you are working away in Slack and want to connect to your Google Drive to obtain specific data. The OAuth app for Slack will allow you to approve access to your Google Drive, via an OAuth token and by using your credentials to collect that specific data of your interest. 

You no longer have to login to Google Drive and be prompted for multi-factor authentication (MFA) when you can easily obtain the data from it directly from within your Slack messaging app.

Similar to the Slack and Google Drive example discussed above, OAuth apps also enable you to connect your calendar, HRMS accounts, DevOps platform, payroll account, and other accounts to various other SaaS apps.

However, with beauty comes danger and with ease, risks.

The easy onboarding of OAuth apps without security checks is one such risk. These apps can be provisioned by any end user with just one click. Now with the thousands of OAuth apps available from public marketplaces, you can only imagine how the ease of provisioning exponentially compounds risk, unless SaaS admins set up stricter controls. 

Another risk comes from users easily building custom/internal OAuth apps using the low/no code frameworks that most SaaS applications offer. These frameworks provide a mechanism for code execution and persistence by bad actors, if accounts are compromised similar to what was seen in the Midnight Blizzard attack. Since most organizations do not have any vetting or review processes around internal OAuth applications, risks get further aggravated. Let’s also factor in the lack of visibility and control over user transactions, and subsequently, exfiltration of data, beyond the perimeters you control. 

There are a few additional risks that must be tracked when using OAuth tokens on applications protected by multi-factor authentication (MFA). The first one arises because as temporary tokens, OAuth tokens are designed for use post authentication, and therefore don’t require re-authentication, allowing bad actors to bypass MFA once they gain initial access. The other risk with OAuth tokens is that although they are based on a temporary token design, they often can be refreshed indefinitely in most implementations, which gives bad actors persistence access.

And lastly, a major risk factor is the lack of expertise on the SaaS admin team in dealing with security issues arising from the use of OAuth apps. Most SaaS admins are not aware of the risks from OAuth apps or have no easy way to vet the app before approving one.

How to defend against OAuth app-based attacks

In order to help you pre-empt these types of attacks it’s very important to educate and partner with your SaaS application administrators, closely monitor your SaaS applications posture, risk profile OAuth apps in real time, and cut off all the insecure and unnecessary doors and windows that exist in Microsoft applications.

Here are the core system hardening techniques that are enforced by a good SaaS Security Posture Management (SSPM) solution that can help you protect your Microsoft SaaS applications.