Let’s talk about SaaS attack techniques

Our goal at Push is simple — to stop identity attacks. Today, the vast majority of identity vulnerabilities exist in the context of SaaS apps.

The reasons for this are clear: Security teams have reduced central oversight and control over SaaS apps than they are used to, these apps exist in large numbers per company, and the identities that are used to access these apps are... complicated, to say the least. Securing hundreds of apps, with thousands of associated identities, is therefore no mean feat.

Securing SaaS use means building controls that are easy to use, easy to understand — and ultimately effective. Not just effective against the hand-wavy concept of “SaaS attacks,” but specific techniques — the most common techniques that are likely to cause real damage.

To talk about this, we need to have a shared understanding of what these techniques are. To get that conversation going, we’ve pulled together all the techniques we're aware of, and our research team has even added a bunch of new ones.

The SaaS attack matrix

We’ve taken inspiration from the MITRE ATT&CK framework (certainly intended as the sincerest form of flattery), but wanted to make a conscious break away from the endpoint-focused ATT&CK techniques and instead focus on techniques that are SaaS-specific. In fact, these techniques don’t touch endpoints (so they bypass EDR) or customer networks (so they bypass network detection) — so we’re calling them networkless attacks.

You can find more detailed descriptions of these techniques (and hopefully PRs for some we missed) on GitHub.

Since we’re not targeting endpoints, let’s talk about the new targets: The accounts/identities on SaaS apps. We found it was useful to think about these identities not as standalone isolated islands — but much more like a graph; less a single web-server on the internet and more like many Windows endpoints on an Active Directory. 

You can leverage this access to an identity on a trusted platform to target (so laterally move or escalate privilege to) other users or identities. For example, attacks like using access to SaaS apps to phish other employees through comments and spoofing users on IM platforms to social engineer them there — or perhaps backdooring links in documents.

In this case, unusually, it’s not the data in these hundreds of SaaS apps that create risk, and you need to consider low-risk (from a data perspective) apps as a vector to pivot to higher-risk apps in your estate.

Initial access and poisoned tenants

Attacks like credential stuffing and email phishing that get you initial access to SaaS apps are fairly well known — because they work and are widely used. We’re also starting to see tools and attacks that suggest that phishing employees through these IM apps is about to go mainstream.

Another interesting attack is a spin on the classic waterhole attack called a poisoned tenant. Rather than attacking a customer tenant for a SaaS app, the attacker lures employees into joining an attacker-controlled tenant. 

SaaS apps allow anyone to name app tenants (a.k.a. spaces, teams, or instances) anything they like — including your company name. Attackers send invites to your employees from within the app with a customized message explaining why they should join this new tenant (or sign up to the app if they are not already a user). 

Attackers might even pay for premium licenses in the app to further entice employees to join. The attacker then waits for the employee to upload sensitive data or create integrations with other company apps containing crown jewels.

Living-off-the-(SaaS)-land to persist and avoid detection

In the endpoint world, a favorite technique is the use of legit OS utilities or LOLBaS (Living-Off-the-Land Binaries and Scripts), which are often signed Microsoft utilities. Perhaps the most well-known example is executing scripts through PowerShell rather than building custom malware. That isn’t as useful these days, but there was a time when PowerShell was routinely used to bypass AV, EDR, and even app allow-listing.

In that same living-off-the-land mindset, an attacker trying to maintain access to each SaaS app they compromise using custom OAuth integration apps might instead choose to use legit SaaS apps that specialize in workflow automation to create shadow workflows. Utilizing legit SaaS apps also means they can hide in plain sight from incident responders, instead of having to rely on unverified or unpublished integrations.

Perhaps the best example here is using a well-known automation app like Zapier, which claims to have more than 5,000 integrations. These integrations are often verified, approved, and connected to a trusted vendor (Zapier). An attacker might create workflows to:

• Do daily data exfiltration from a victim’s data lake.

• Configure a webhook that adds malicious accounts to a Github repo on demand.

• Automatically find and replace bank account numbers in emails to the finance team.

All appear as legitimate Zapier integrations. But, before you put in alerts specifically for Zapier, know that it’s one of dozens of apps that support these kinds of offensive workflows.

A sneaky attacker might go further and use an evil twin integration to make another instance of an existing integration — making this backdoor almost impossible to discover.

Features or vulnerabilities?

When looking for attack techniques, you’re typically going after features that have weaknesses you can abuse rather than bugs in a single app that will be patched. 

It’s pretty common for SaaS apps to skip email verification or allow multiple simultaneous authentication methods. Both of these are conscious design choices in the name of lowering the friction of account creation and reducing customer support. However, these features make techniques like account ambushing and ghost logins possible. If these attacks become widespread, these might come to be seen more as bugs rather than a positive feature for users.

In other cases, the bugs are serious enough and hard enough to patch that they’re worth noting as a technique. The recently disclosed (and perfectly named) nOAuth bug fits this bill. 

The bug arises from a confusion between an email identity and email metadata field in Microsoft integrations and without a central fix from MS (the fix isn’t trivial), these bugs are likely to be discovered and re-occur on third-party OAuth apps for a while to come.

The SaaS market is driving these offensive techniques

SaaS apps are basically web apps that are run in the cloud and accessed from endpoints, so then WebApp, endpoint, and cloud security should cover all of SaaS, right? 

That was our assumption when we started, but what we found instead was that SaaS marketing practices are driving a lot of pretty interesting techniques that you don’t run into in standalone web apps.

Modern SaaS is easy to adopt, easy to use, low friction, low cost, low overhead

Making apps easy to sign up for and low effort to support means you need to make some interesting choices when it comes to designing account creation and recovery flows. 

Many apps allow users to sign into apps using multiple methods, easily invite collaborators (internal and external) and avoid any additional friction during the signup process. 

For example, many apps avoid verifying new account email addresses. This is not laziness, these are conscious design choices — not driven by security clearly, but not accidents.

Modern SaaS is highly integrated

Most SaaS apps are trying to build app marketplaces or perform well in other apps' marketplaces (often both), and it’s rare these days to find apps that don’t integrate with other apps. 

OAuth has become the de facto standard protocol for doing this, and most users have become quite used to approving OAuth2.0 consent flows. These integrations have opened up lots of incredibly useful doors for attackers to persist access and move laterally across SaaS apps that few incident response teams have run into yet. These tokens don’t expire when you reset passwords, aren’t protected by MFA, and actions they performed are rarely logged. 

These are not bugs or oversights but rather a consequence of how these APIs are intended to be used (by machines, not human adversaries).

Problems with observing SaaS attacks 

This research begs one question above others: “Are we seeing these attacks in the wild?” 

Yes, definitely

For some of the better-known techniques, like credential stuffing and email phishing, the answer is an easy yes. Stats from Microsoft (1,287 password attacks every second) and Auth0 (a third of their traffic is credential stuffing) speaks volumes. Other sources like the NCSC's Cyber Security Breaches Survey 2022 and the Verizon 2023 Data Breach Investigations Report suggest that phishing is also a major cause of SaaS breaches. Anecdotal reports from colleagues in the Incident Response field suggest that malicious mail forwarding rules are seen a lot, something which is supported by the Expel Quarterly Threat Report for Q1 2023 (see page 6).

The takeaway is that the current focus for defenders should be to ensure users have good phishing-resistant account security in place — make sure you have basics like strong unique passwords and MFA in place across your entire SaaS estate.

For newer OAuth attacks, it’s a lot less clear …

Other techniques like consent phishing have been discussed in some breach disclosures like the 2020 SANS breach. These OAuth techniques also pop up in the news (for example, the 2022 Github/Heroku/Travis-CI breach where GitHub accounts were breached using stolen Heroku and Travis-CI OAuth tokens). 

That said, none of these techniques come up as frequently as their usefulness would suggest. This means one of two things: Either attackers aren’t yet using them widely, or they are and we aren’t detecting them.

There is certainly a case to be made that attackers simply don’t need these newer techniques yet. Many organizations don’t have a way of discovering SaaS use in their organization yet, never mind breached accounts, so new persistence techniques might be a bit more than necessary at the moment.

But would we know if it was happening?

On the other hand, there is certainly the possibility that these attacks are increasingly used, but are simply not being discovered. A strong argument in favor of this view is the difficulty in investigating these attacks. Very few SaaS apps provide enough logging capability to discover these attacks as a customer. This is true even for the biggest, most mature apps like Office 365 and Google Workspace unless you are on top license tiers. This is doubly true for attacks that use OAuth, with many apps providing no insight or details into actions made using OAuth-authenticated APIs. 

This suggests only the SaaS providers for these apps are really in a position to discover and investigate them. This does ring true when you consider that Heroku relied heavily on Github during the investigation (and in one case even the detection of) their 2022 breaches, and the same seems true for a similar breach affecting CircleCI later that year. Github and CircleCI’s customers prompted the investigation after seeing strange behavior, but Github had access to the logs to investigate. It’s difficult to imagine that most or even many SaaS vendors have the resources or inclination to run these investigations effectively as GitHub appears to have.

So, are these attacks happening in the real world? My best guess is it’s a little bit of column A and a little bit of column B — there are likely not so many of these attacks happening yet, and when they do, I suspect the vast majority go undetected. But that’s just like my opinion, man.

This is part of the reason we think enabling red teamers to try these techniques in anger is useful — this is the time-proven way to understand these risks.

What’s next?

We’ve barely scratched the surface, but perhaps there is enough here to get the discussion going. From past experience, discussion may not be enough, and it’s likely that live offensive work like penetration tests or more likely red team exercises will be required to make the risks of using these techniques real for the wider security community. 

After all, seeing is believing. We think some more practical examples and tools to help red teamers use these techniques on engagements will help drive awareness forward, so we’ll be looking to build out this content.

We’ve started with pure networkless attacks that don’t touch customer networks or endpoints, but there are many useful techniques to connect the old endpoint world to the SaaS world. Consider stealing OAuth tokens from a thick client on an endpoint, or using a backdoored GitHub repo to get code execution on endpoints.

Help us all better understand how widespread these attacks are by sharing some war stories. We’d love some comments, discussions, or PRs on GitHub!