One of the questions we hear all the time is, “Can’t I just block my employees from using SaaS that my team hasn’t already vetted and approved?” And the answer is “Yes, you can. You can certainly block the apps we find your employees using, but the real question is ‘Should you?’”
One of the questions we hear all the time is, “Can’t I just block my employees from using SaaS that my team hasn’t already vetted and approved?” And the answer is “Yes, you can. You can certainly block the apps we find your employees using, but the real question is ‘Should you?’”
Our goal at Push is simple - to reduce the risk of using SaaS apps at work. Doing this well 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 PR’s 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 not think about these identities as stand-alone isolated islands - they are 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 more 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 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 5000 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 which 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 webapps 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 best 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 sign up 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 app’s 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, and 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, nevermind 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 - blueteams, have you seen these attacks in IR investigations? Red-teamers, have tried these or similar techniques against SaaS? Even better, we’d love some comments, discussions, or PRs on GitHub!
