The SaaS attack matrix: A year in review

When we created the SaaS attack matrix, we made a conscious break away from the endpoint-focused techniques captured in industry resources like the MITRE ATT&CK Framework. 

At the time, we were anticipating a shift that was yet to fully materialize. But, a lot can change (and has changed) in the space of a year. We’ve seen the impact of SaaS account takeover attacks laid bare. Snowflake, billed one of the biggest breaches in history, is a telling example that we’ll no doubt look back on as a watershed moment. 

It isn’t an exaggeration or marketing fluff to say that identity attacks are the #1 threat facing organizations today. SaaS apps, and the identities that are used to access them, are clearly the weakest link – and therefore the lowest-hanging fruit for attackers to reach for.

This makes resources like the SaaS attack matrix more relevant than ever – both for red teams seeking to emulate the latest offensive techniques, and blue teams trying to defend against them. Understanding these techniques is essential for building effective defenses, and identifying where new platforms and controls are required to do so. 

Let’s take a look at what we’ve learned so far.

Hot right now: Initial access techniques

The majority of techniques we've seen rise to prominence in 2023/4 sit predominantly in the initial access phase. Since the matrix first launched, we’ve added more techniques to initial access than any other category, including ghost logins, AitM phishing, session cookie theft, MFA downgrade attacks, and guest access abuse, all of which are methods of account takeover – complementing the classics like credential stuffing and email phishing.

We’ll spend a bit of time delving into these techniques in the next section, but let’s first consider what this tells us about SaaS attacks. 

Identity attacks are the leading cause of SaaS breaches

The initial identity attack designed to achieve account takeover is the most important part of the SaaS attack chain. The fact that attackers are focused on finding new ways of compromising identities illustrates the value, but also the fragility of the identity controls that most organizations are relying on (which may also be one of the reasons attackers are fixated on it). Whether we’re talking about anti-phishing protections, conditional access policies, or MFA – attackers are continually finding new ways of getting around them.

And, if all an attacker really needs to do to cause harm is log into an app and abuse its legitimate features and functions, there really is no margin for error – you need to successfully stop the initial identity attack every time.

You can’t rely on your endpoint and network controls to catch them later like you used to. Equally, it’s unlikely that your CASB or DLP solution can stop a legitimate app using legitimate features like API-based workflows from sending data to attacker-controlled infrastructure. 

It’s a classic case of attackers only needing to win once. And right now, it’s a numbers game that they’re winning enough to keep them coming back for more. 

Most wanted: Techniques gaining notoriety in the wild

Let’s take a closer look at some of the techniques we’ve seen rise to prominence in 2023/4. 

Ghost logins

Ghost logins is a technique that exploits the fact that SaaS user accounts often enable multiple simultaneous logins using different sign-in methods. 

Ghost logins can be used for both the initial access and persistence stages of a cyber attack, doubling up as a defense evasion technique because of low login method visibility.

For initial access, the technique exploits the fact that local and SSO logins can exist simultaneously. Given that many apps are self-adopted by users, it’s likely that many users will default to a local username and password login at this stage. If the app is later adopted companywide and brought into SSO, the original local login will continue to exist unless explicitly disabled or deleted.

Because MFA is applied at the app and IdP level independently, it is possible to end up with an SSO login that requires MFA (via the IdP login), but a local login that does not. This creates an easy target identity for attackers to look for. When combined with other identity vulnerabilities such as weak, breached, and/or reused passwords, attackers can easily automate ghost login discovery and exploitation at scale.  

We saw the impact of ghost logins for initial access with the recent ShinyHunters campaign against Snowflake customers. Because Snowflake accounts did not require mandatory MFA for accounts, or give admins the ability to enforce MFA by default, attackers were able to find and exploit a large number of Snowflake accounts using breached credentials from historical data breach dumps. Much of the industry response focused on ensuring SSO and MFA were deployed, but the practicalities of gathering data and manually unsetting local passwords in Snowflake meant that ghost logins were easy to overlook by organizations responding to the attacks.   

Ghost logins can also be created after an attacker has established access to an app. For example, if a social login is used to access an account, an adversary may be able to configure a separate username/password login, or even (though much less commonly) connect a second social account that the adversary controls. If the account has sufficient privileges, it may also be possible to set up or change the SAML login settings to inject a malicious URL (for example to an attacker controlled tenant) or simply configure API access to forgo the need to log in entirely. 

AitM phishing 

Adversary-in-the-Middle (AitM) phishing is a newer variant of phishing that uses dedicated tooling to act as a web proxy between the victim and a legitimate login portal for an application the victim has access to, principally to make it easier to defeat MFA protection (with the victim responding to the MFA request as part of the attack).

As it’s a proxy to the real application, the page will appear exactly as the user expects, because they are logging into the legitimate site – just taking a detour via the attacker’s device. For example, if accessing their webmail, the user will see all their real emails; if accessing their cloud file store then all their real files will be present, etc. 

This gives AitM an increased sense of authenticity and makes the compromise less obvious to the user. Because the attacker is sitting in the middle of this connection, they are able to observe all interactions and take control of the authenticated session.

Alongside AitM phishing is Browser-in-the-Middle (BitM), really a form of sub-technique. Rather than act as a reverse web proxy, this technique tricks a target into directly controlling the attacker’s own browser remotely using desktop screen sharing and control approaches (such as VNC and RDP).

This is the virtual equivalent of an attacker handing their laptop to their victim, asking them to login to Okta for them, and then taking their laptop back afterwards.

A growing majority of modern phishing attacks typically leverage AitM or BitM tooling – they are now the standard choice for threat actors, offering the ability to bypass MFA without any real tradeoff. 

For more information you can read our recent blog post or watch our on-demand webinar on Phishing 2.0 to see AitM and BitM tools like Evilginx and EvilnoVNC in action. 

Credential stuffing

Credential stuffing attacks continue to pose a risk to organizations. Despite the fact that MFA has now become an expected control, accounts without MFA continue to be hacked as a result of using weak, reused, and/or previously breached credentials. 

Credential stuffing is being fed by an increase in the number of infostealer attacks designed to harvest credentials to be sold on criminal marketplaces. Infostealers have been boosted by the success of the Snowflake attacks (where 80% of the credentials used to access accounts could be traced back to infostealer infections dating back to 2020).

Session cookie theft

Attackers are increasingly targeting session cookies to be able to hijack live user sessions as a means of getting around MFA. Although session cookies are predominantly stolen via infostealers, techniques like AitM and BitM phishing described above are also methods of stealing session cookies and hijacking sessions.

While the majority of infostealer data dumps result in credential stuffing attacks rather than session hijacking, as the infostealer marketplace continues to heat up, it’s likely that more instances of session cookie theft will be the cause of breaches going forward. 

MFA downgrade

While many organizations are waking up to the fact that it’s not enough to have any old MFA method, it’s still often overlooked that you need to actually remove or disable the phishable methods. Otherwise, in many cases they remain valid, opening affected identities up to MFA downgrade attacks. 

Just because a user has a phishing-resistant factor setup (such as passkeys) and may use them by default, it does not mean they are necessarily enforced. Often, services support the use of multiple authentication options, particularly for second factors. In particular, passkeys are device-bound and so enforcing their use prevents logins from other devices and can cause recovery issues in a lost/broken device scenario. Therefore, it’s common for the default case to be that passkey authentication is optional, rather than required.

When used in combination with AitM phishing tools, it’s possible for attackers to modify requests/responses so as to prevent the ability of passkeys to be selected as a login option and prompting the user to use vulnerable factors, such as passwords, TOTPs and push notifications instead. Since the server-side supports other authentication options, if the user continues and enters one of these alternative factors then their authenticated session will be compromised – despite the fact they usually use phishing-resistant MFA methods like passkeys or similar.

Use case inspo: How red teamers are using the SaaS attack matrix

The techniques that advanced red teams are using to (ethically) hack into their clients are always a good indicator of what direction hackers in the real world are headed.  

We spoke to a few of the best red teams around to see how they are using the matrix: Let’s see what they had to say. 

Rob Maslen | Managing Principal Consultant | MDSec

“We use the matrix throughout our engagements: When scoping and proposing projects to clients, during testing to assist our consultants in successfully utilizing novel SaaS-attack techniques, and for reporting to provide a common language across the vendors that they work with. 

It’s been most useful to us when performing engagements on more modern Zero Trust Environments where macOS is predominantly the Operating System of choice. The objectives tend to be either access to critical applications that reside within the cloud and require the compromise of SaaS credentials, or to gain privileged access to a SaaS application. Whilst resources like the MITRE ATT&CK Framework can help to describe the techniques that have been used against a more traditional environment, the SaaS Matrix aids with performing and describing attacks against a more modern infrastructure.  

The technique we’ve seen most success with, across both traditional Active Directory attacks and more modern Zero Trust Environments, is Session Cookie Theft. The protection of browser cookies (for inexplicable reasons) has had less engineering attention than it should have, opening up opportunities for lateral movement using session cookies, credentials, or API keys recovered from a host becomes a key technique. In our experience defensive tooling has yet to catch up with this threat. 

We’ve also seen success with various techniques across Kill Chain stages, including Subdomain tenant discovery, DNS reconnaissance, username enumeration, consent phishing, device code phishing, guest access abuse, shadow workflows, OAuth tokens, API keys (as long as you ensure the target isn't notified – make sure you delete the notification of creation email!), API secret theft, and link backdooring. 

Embracing the modern Zero Trust architecture with its greater SaaS usage does not come without security risks, and while it does invalidate a large number of the attacks that can be performed within an AD environment, the SaaS attack matrix is a great way of illustrating how these attacks work, as well as helping red and blue teams respectively to simulate and defend against them." 

Tom Ellson | Head of Offensive Security | Stripe OLT

“We've used the SaaS attack matrix across several cloud-native engagements, for both initial access and lateral movement. My go-to techniques so far have been:

• IM phishing: Phishing via Microsoft Teams in particular has been highly successful, especially when paired with a number of abusable “features” (working as intended, clearly). 

• Device code phishing: We use this for both initial access and persistence. It’s a great way of getting around MFA by tricking the victim into following the device approval process for our device, but using their device. 

• AitM phishing: This is now a staple for credential harvesting. Better security controls force us to abuse other avenues to bypass conditional access policies, such as extraction of the PRT token from the end user device, thus granting us claimed access, which can be achieved using AitM and BitM techniques.

• OAuth token enumeration: Once an account has been compromised, the Myapps portal is commonly used to validate the accessible applications and further target downstream apps to access data and functionality. 

We’re usually targeting M365 environments but have still found these attack techniques to be highly effective. In some cases, we’ve leveraged other SaaS applications such as abusing in-app phishing via GitHub to compromise development pipelines. The matrix is particularly useful as a playbook of further attacks once initial access has been established. Even just the awareness of how to pivot from SaaS to SaaS (and sometimes back to Microsoft or Google) is really eye-opening for red teams, and adds a new dimension to the security testing that our clients are used to experiencing. 

Because of the success of using these methods, we’ve now incorporated the SaaS attack matrix techniques into our purple teaming methodology to ensure that our clients can build awareness of their detection visibility gaps when it comes to identity attacks, and are routinely benchmarked against them.”  

Max Corbridge | Head of Adversarial Simulation | JUMPSEC

“I’ve been a big fan of the matrix from day one. We use it for two main purposes – as a catalog of TTPs to apply during threat modeling exercises with cloud-native clients, and as a guide for how to apply novel TTPs to different apps and situations. The wiki descriptions, video demonstrations and references help enormously with this. 

We’ve mostly relied on IM phishing, AitM phishing, abusing OAuth integrations, and SAMLjacking. In one recent engagement, we were able to compromise a cloud identity with limited permissions in the target Azure environment. We were able to enumerate additional OAuth integrations to laterally move to a third-party IT Service Management SaaS application, which presented a much easier target to elevate privileges. We actually ended up finding a number of 0-days in the application, which we then used as a trusted platform to launch a covert spear-phishing campaign against specific high-privilege users, communicating back-and-forth as though we were a genuine support team, and hiding risky changes to cover our tracks. Ultimately we were able to pivot back into the target Azure estate, but now with administrative privileges. 

This really shows how third-party identities and apps are often the soft underbelly for a lot of otherwise pretty secure orgs that we work with, and we’re enjoying the challenge of finding new ways of getting to the crown jewels. 

In my eyes the world of cloud and SaaS-native attack techniques is under-researched for how increasingly relevant it is becoming. Many of the older TTPs and tradecraft are no longer relevant in a cloud-native world, and even when the techniques are consistent with the ways we used to target networks and endpoints, the context and how it actually works is completely different. So, resources like the SaaS attack matrix will continue to be needed for both offensive and defensive security practitioners going forwards”.

Get involved!

Hopefully you're now feeling inspired to get involved and start applying the SaaS attack matrix yourself. And if you’ve been using the matrix and want to share your experience with us, we’d love to hear from you. 

We hope to see your comments, discussions, or PRs on GitHub!

If this has piqued your interest, we’ve just released a 2024 edition of our SaaS attacks report: get your copy here.