The modern kill chain is eluding enterprises because they aren’t protecting the infrastructure of modern business: SaaS.
SaaS continues to dominate software adoption, and it accounts for the greatest share of public cloud spending. But enterprises and SMBs alike haven’t revised their security programs or adopted security tooling built for SaaS.
Security teams keep jamming on-prem pegs into SaaS security holes
The mature security controls CISOs and their teams depended on in the age of on-prem dominance have vanished. Firewalls now protect a small perimeter, visibility is limited, and even if SaaS vendors offer logs, security teams need homegrown middleware to digest them and push into their SIEM.
SaaS vendors do have well-defined security scopes for their products, but their customers must manage SaaS compliance and data governance, identity and access management (IAM), and application controls — the areas where most incidents occur. While this SaaS shared responsibility model is universal among SaaS apps, no two SaaS applications have identical security settings.
 |
| Figure 1. In the context of SaaS security concerns, the application provider is responsible for all physical infrastructure, as well as the network, OS, and application. The customer is responsible for data security and identity management. The SaaS shared responsibility model requires SaaS customers to assume ownership of components that threat actors attack most often. Illustration courtesy of AppOmni. |
AppOmni research reports that on average, a single instance of SaaS has 256 SaaS-to-SaaS connections, many of which are no longer in use, but still have excessive permissions into core business apps such as Salesforce, Okta, and GitHub, among others.
Between the multitude of different SaaS security settings and constant updates that alter them, security teams can’t effectively monitor these connections. The number of entry points multiplies exponentially when employees enable SaaS-to-SaaS (also called “third party” or “machine”) connections. Machine identities can use API keys, secrets, sessions, digital certificates, cloud access keys, and other credentials to enable machines to communicate with one another.
As the attack surface migrated outside the network perimeter, so did the kill chain — the way in which threat actors orchestrate the various phases of their attacks.
The modern SaaS kill chain usually involves:
- Compromising an identity in the IdP via a successful phishing campaign, purchasing stolen credentials off the dark web, credential strings, credential stuffing, taking advantage of misconfigured SaaS tenants, or similar methods.
- Conducting a post-authentication reconnaissance phase. This step is reminiscent of attackers breaking into the corporate networks of yore. But now they’re combing through document repositories, source code repositories, password vaults, Slack, Teams, and similar environments to find privileged escalation entry points.
- Leveraging their findings to move laterally into other SaaS tenants, PaaS, or IaaS, and sometimes into the corporate infrastructure — wherever they can find the data most valuable to the target organization.
- Encrypting the crown jewels or delivering their ransom note, and attempting to evade detection.
 |
| Figure 2. Successful SaaS kill chains typically involve four overarching steps: initial access, reconnaissance, lateral movement and persistence, and ransomware execution and security evasion. Illustration courtesy of AppOmni. |
Breaking down a real-world SaaS kill chain: Scattered Spider/Starfraud
SaaS security leader AppOmni’s latest threat intelligence briefing webinar delineated the kill chain of the Scattered Spider/Starfraud threat actor groups’ (affiliates of ALPHV) successful attack on an undisclosed target in September 2023:
- A user opened a phishing email that contained links to a spoofed IdP login page, and they unknowingly logged into the fake IdP page.
- The threat actor groups immediately called that user and convinced them, through social engineering, to provide their time-based, one-time password (TOTP) token.
- After obtaining the user’s login credentials and TOTP token, the threat actors tricked the MFA protocol into thinking they’re the legitimate user.
- While in reconnaissance mode, the threat actors had access to a privileged escalation, enabling them to obtain credentials into Amazon S3, then Azure AD, and finally Citrix VDI (virtual desktop infrastructure).
- The threat actors then deployed their own malicious server in the IaaS environment, in which they executed a privileged Azure AD escalation attack.
- The attackers encrypted all the data within their reach and delivered a ransom note.
 |
| Figure 3. The kill chain used by the Scattered Spider/Starfraud threat actor groups. Illustration courtesy of AppOmni. |
Scattered Spider/Starfraud likely accomplished this series of events over several days. When SaaS serves as the entry point, a serious attack can include the corporate network and infrastructure. This SaaS/on-prem connectivity is common in today’s enterprise attack surfaces.
SaaS attack activity from known and unknown threat actors is growing
Most SaaS breaches aren’t dominating headlines, but the consequences are significant. IBM reports that data breaches in 2023 averaged $4.45 million per instance, representing a 15% increase over three years.
Threat actors are continually relying on the same TTPs and playbook of the Scattered Spider/Starfraud kill chain to gain unauthorized access and scan SaaS tenants, including Salesforce and M365 where configuration issues might be manipulated to provide access later.
Other attackers gain initial access with session hijacking and impossible travel. Once they’ve transferred the hijacked session to a different host, their lateral movement often involves communications platforms such as SharePoint, JIRA, DocuSign, and Slack, as well as document repositories like Confluence. If they can access GitHub or other source code repositories, threat actors will pull down that source code and analyze it for vulnerabilities within a target app. They’ll attempt to exploit these vulnerabilities to exfiltrate the target app’s data.
The AppOmni threat intelligence briefing also reports that data exfiltration via permission sharing remains a serious SaaS security concern. This occurs, for example, in Google Workspace when the unauthorized user changes directories to a very open level of permissions. The attacker may share them with another external entity via email forwarding, or changing conditional rules so attackers are included as BCC recipients in a distribution list.
How do you protect your SaaS environments?
1. Focus on SaaS systems hygiene
Establish a SaaS intake and review process to determine what SaaS you’ll allow in your company. This process should require answers to security questions such as:
- Does all SaaS need to be SOC 2 Type 2 certified?
- What is the optimal security configuration for each tenant?
- How will your company avoid configuration drift?
- How will you determine if automatic SaaS updates will require modifying security control settings?
Ensure you can detect Shadow IT SaaS (or unsanctioned SaaS apps) and have a response program so alerts aren’t created in vain.
If you’re not monitoring your SaaS tenants and ingesting all of the logs from them in some unified method, you’ll never be able to detect suspicious behaviors and receive alerts based on them.
2. Inventory and continuously monitor machine accounts/identities
Threat actors target machine identities for their privileged access and lax authentication standards, often rarely requiring MFA.
In 2023, threat actors successfully targeted and breached major CI/CD tools Travis CI, CircleCI, and Heroku, stealing OAuth tokens for all of these providers’ customers. The blast radius expands considerably in these situations.
With the average enterprise containing 256 machine identities, hygiene is often lacking. Many of them are used once or twice and then remain stagnant for years.
Inventory all of your machine identities and triage these critical risks. Once you’ve mitigated these, create policies that prescribe:
- What type of accounts will be granted machine identities, and the requirements these vendors must meet to be granted access.
- The time frame for how long their access/tokens are active before they will be revoked, refreshed, or regranted.
- How you’ll monitor these accounts for their usage and ensure they’re still needed if they experience periods of dormancy.
3. Build out a true Zero Trust architecture in your SaaS estate
Zero Trust architecture builds on the principle of least privilege (PLP) with a “never trust, always verify” approach. While Zero Trust has been established in traditional networks, it’s rarely achieved in SaaS environments.
Zero Trust Network Access (ZTNA)’s network-centric approach cannot detect misconfigurations, machine integrations, or unwanted user access entitlements within and to SaaS platforms, which can have thousands or even millions of external users accessing data.
Zero Trust Posture Management (ZTPM), an emerging SaaS security tool, extends Zero Trust to your SaaS estate. It bridges the SaaS security gap that SASE creates by:
- Preventing unauthorized ZTNA bypass
- Allowing for fine-tuned access decisions
- Enforcing your security policies with continuous feedback loops
- Extending Zero Trust to machine integrations and cloud connections
With SSPM, ZTPM, and a SaaS security program in place, your team will gain the visibility and intelligence it needs to identify intruders in the low-risk stages of your kill chain — and stop them before a breach becomes devastating.
