In-Depth

The SaaS Cybersecurity Kill Chain

Paul Schnackenburg, working in the IT trenches every day as a 1-person SoC, looks at how the cybersecurity kill chain is evolving in the SaaS era, where identity is the new perimeter and attackers exploit cloud app integrations, SSO, and OAuth to gain and maintain access.

• By Paul Schnackenburg
• 05/27/2025

Most IT folks are familiar with the cybersecurity kill chain -- the steps that an attacker takes (in broad strokes) when compromising a system. It looks like this:

Originally adapted from the military Kill Chain (with a different end result than system compromise), the cyber version is designed to communicate to non-experts that there are phases an attacker goes through to reach their ultimate goal. The other flavor is the MITRE ATT&CK framework, which breaks out a few more phases, but follows the same flow.

However, it's a very network/on-premises focused approach, which doesn't translate well to modern Software-as-a-Service (SaaS) cloud services. And many businesses are adopting these over traditional IT applications whenever they can, and some smaller or startup businesses are completely SaaS based -- with no on-premises network to compromise.

But SaaS services can be and are compromised -- so what does that look like? In this article I'm going to cover different attack types and how the kill chain can be adapted to a SaaS world. I build heavily on the work of Luke Jennings from Push Security, who has presented on this at various cybersecurity conferences, such as this one, thanks goes to Luke for his work in this area.

A Brief History of Cybersecurity
In the 2000s cybersecurity was very much a matter of perimeter security -- firewalls, VPNs and exploiting vulnerabilities to get from the outside to the inside. And on the inside was everything, servers, data, applications and networks, with rather poor posture because they were relying on that big blinky firewall on the edge keeping the bad guys out.

A decade later the endpoint became the focus. Attackers used phishing emails to establish a foothold in a single device to start with, and then pivoted to other systems in the network, eventually compromising the entire domain.

Note that the hardening of whole categories of systems makes the attackers shift their focus. Better firewalls and edge devices moved the target to endpoints. It's no surprise that the 2010s is when Endpoint Detection and Response (EDR) was born, as an augmentation on top of traditional Anti-Virus protections. Larger technological shifts also affects cybersecurity writ large such as Wi-Fi and remote working (accelerated by the pandemic), and SaaS adoption is the next one.

It's also interesting that just because the focus of attackers is shifting, old attacks don't disappear. Edge security appliances are still being compromised as are endpoints, but it's gotten harder to do so.

The next frontier is SaaS apps. And the way these are attacked is primarily through compromising identities, hence the saying that "identities are the new perimeter."

New Attacks in Familiar Kill Chain Phases
The phases of the cyber kill chain stay mostly the same but what takes place in each of them are different when criminals focus on SaaS apps.

The landscape where the attacks take place also looks radically different. In a SaaS-first business the Identity Provider (IdP) sits in the heart, with various apps connected to it, such as Microsoft 365, Google Workspace, Slack, Salesforce and so on. There's no internal/external network, it's all external. Remember that most organizations try to provide Single Sign On (SSO) for as many SaaS applications as possible, meaning that you sign in once to Entra ID or Okta, and from there you can then access the applications you've been granted access to. In other cases, users create an account directly in the SaaS app, with their business identity (hopefully) and a password. And even if a business has migrated a SaaS app from direct sign in to SSO, the old accounts may still be present and allow sign in. I also see a mix in most businesses, where some "known / sanctioned" SaaS apps are governed through SSO, but many other apps the IT department don't even know about unless they're judicious in tracking down Shadow IT usage.

In the reconnaissance phase, instead of probing ports on your firewall, an attacker is more likely to investigate which SaaS apps an organization are using and how they are connecting to them. One such technique is SAML enumeration, which can be used to identify which SSO provider the target is using. Security Assertion Markup Language (SAML) is a protocol to configure SSO between IdPs and SaaS apps. Another is a slug tenant, the initial domain that a user or administrator uses when setting up a SaaS app, which is generally a variation of the company name (such as the company.onmicrosoft.com domain that you have to create for Microsoft 365 for example).

For initial access, instead of compromising endpoints, the aim is to conquer cloud identities as they hold the key to "everything." Phishing is still used, but instead of attaching a malicious file, an embedded link leads to an Attacker in the Middle page designed to capture both password and Multi-Factor Authentication (MFA) tokens from the end user. Email phishing is also not the only game in town, with Instant Message phishing in Teams or Slack becoming more prevalent. Another approach is OAuth consent phishing, which presents a permissions screen to the end user, and if they approve, the malicious application now has the granted permissions, irrespective of the users MFA and so on.

A poisoned tenant is also possible, where the attackers creates a new tenant in a SaaS app and invite users in the target organization. Finally, SAMLjacking uses the legitimate flow of the app handing off authentication during the SAML flow, which users are expecting, but instead of the legitimate URL you configure it to redirect to a credential phishing page. Here you can see these two combined in a short demo video.

Once an attacker is in, they want to maintain persistence on the system, which traditionally involves setting up a scheduled task on a system or creating a service that provides a connection point for the attacker if they're kicked out. In the new cloud world this is creating accounts in SaaS apps, setting up an OAuth app (now that you have access as a user), creating sharing links to data in OneDrive or Google Drive or adding secondary logins to SaaS apps.

The biggest problem here from an incident response perspective is that SaaS apps gives attackers many more places to hide. In the past, if you caught an endpoint attack early remediation would involve (I've done these exact steps for my clients): killing their sessions; resetting the user password; checking that no additional MFA methods were added; checking for email forwarding rules; and then re-imaging the endpoint device. Now, with a few minutes access as a user, an attacker can go to your SaaS apps panel (myapps.microsoft.com in the M365 world) and add several different types of persistence to dozens or hundreds of apps, and even if you reset everything for the user and wipe their endpoint, the attacker continues to have access through these.

In the execution phase we can see malware, memory implants or PowerShell scripts doing the attackers malicious bidding on the endpoint, but in the SaaS world this looks more like taking advantage of automation workflows or setting up API access. An interesting twist here is registering a second instance of an OAuth app, something that normally doesn't generate logs, which you can see demonstrated here.

Lateral movement is the main way that on-premises networks are compromised. The bad guys get a foothold on one device, with one compromised user account. Then they use that account to move to another endpoint and so forth, until they find a more privileged account, rinse and repeat until they own the domain. In the cloud this is about moving from one SaaS app to another, backdooring links or using an existing integration in a malicious way.

Bringing It All Together
An example full attack chain could start with a phishing email to a fake login page as initial access, followed by credential theft using Evilginx stealing Entra ID credentials for the user. Once the attacker has access, they compromise further SaaS apps as lateral movement, and backdoor apps for persistence.

This presents difficulties for defenders, first, traditional EDR isn't going to have visibility, as none of this activity touches the endpoint (outside of the browser, and EDRs have poor visibility inside of the web browser process) and even a Cloud App Security Broker (CASB) or networking monitoring isn't likely to see it as it's "normal" SaaS activity. Secondly, if the breach is discovered, incident response is not going to be easy as visibility is not centralized in the same way as it is for EDR / XDR.

Another big challenge is being able to kill sessions across all SaaS apps quickly, in Entra ID (or Okta) you can kill access to all the SSO integrated applications, but if the attacker has created secondary accounts, for example, those sessions still persist. Finally, logging, the amount of time logs are stored, and security content of the logs varies wildly across SaaS apps, making ingestion into Security Information and Event Management (SIEM) systems for visibility challenging.

Luke has the full matrix available as open source, looking for contributions.

Conclusion
The fact that as the IT / security industry tightens up one area of attack, this forces criminals to pivot to the next area, is evidence that we're having an impact. The rise of AitM kits to bypass MFA is showing us that multi factor adoption has enough traction for attackers to adapt to it for example.

SaaS apps are now integrated in every business, big or small, and while it's early days for the attackers to focus on them exclusively, there's no doubt we'll see these attacks increasing.