Enterprises are struggling to counter the evolving kill chain as they fail to safeguard the foundation of contemporary business: Software as a Service (SaaS).
SaaS continues to lead software adoption trends and commands the largest slice of public cloud expenditure. Nevertheless, both enterprises and small to medium businesses have yet to revamp their security strategies or adopt security solutions tailored for SaaS environments.
Security teams are trying to fit traditional solutions into SaaS security gaps
The robust security measures that Chief Information Security Officers (CISOs) and their teams relied on during the era of on-premises dominance have disappeared. Firewalls now shield a limited perimeter, visibility is compromised, and even if SaaS providers furnish logs, security teams need bespoke middleware for analysis and integration with Security Information and Event Management (SIEM) systems.
While SaaS providers define security perimeters for their offerings, their clients must oversee SaaS compliance, data governance, identity and access management (IAM), and application controls, which are the primary focal points of security incidents. Despite the uniformity of the SaaS shared responsibility model across applications, the security setups of different SaaS platforms vary.
According to AppOmni’s research, an average SaaS instance has 256 SaaS-to-SaaS links, many of which are inactive but still retain excessive access to core business applications like Salesforce, Okta, and GitHub, among others.
Due to the array of diverse SaaS security configurations and frequent alterations, security teams struggle to effectively supervise these connections. The proliferation of potential entryways surges when employees establish SaaS-to-SaaS (also known as “third-party” or “machine”) connections. Machine identities employ API keys, confidential data, sessions, digital certificates, cloud access keys, and other credentials to facilitate machine-to-machine communication.
Just as the attack landscape shifted beyond network confines, so did the attack chain — illustrating how threat actors coordinate the distinct stages of their assaults.
The contemporary SaaS attack chain typically encompasses:
- Infiltrating an identity within the Identity Provider (IdP) through a successful phishing scheme, procuring stolen credentials from the dark web, exploiting misconfiguration of SaaS cloud environments, or employing similar techniques.
- Conducting post-authentication reconnaissance activities. This phase mirrors historical attempts of infiltrating corporate networks but extends to scrutinizing document archives, source code depositories, password repositories, communication platforms like Slack and Microsoft Teams, seeking potential avenues for privilege escalation.
- Using the gathered intelligence to pivot into other SaaS platforms, Platform as a Service (PaaS) offerings, Infrastructure as a Service (IaaS) environments, and occasionally corporate networks to access the most valuable data for the targeted entity.
- Encrypting critical data or deploying ransom demands while evading detection.
Deconstructing a tangible SaaS attack chain: Dispersed Spider/Starfraud
The recent threat intelligence session by SaaS security leader AppOmni outlined the attack chain of the Dispersed Spider/Starfraud threat actor factions (associated with ALPHV) in their successful breach of an undisclosed target in September 2023:
- A user fell victim to a phishing email containing links to a counterfeit IdP login page and inadvertently logged into the bogus IdP platform.
- The threat actors promptly contacted the user and, through social engineering tactics, persuaded them to disclose their time-bound, single-use password (TOTP) token.
- With the user’s login credentials and TOTP token in hand, the malevolent actors manipulated the Multi-Factor Authentication (MFA) protocol into recognizing them as the legitimate user.
- During the reconnaissance phase, the attackers exploited a privilege escalation opportunity to access credentials on Amazon S3, then Azure AD, and finally Citrix Virtual Desktop Infrastructure (VDI).
- The desktop infrastructure was compromised.
- The malicious server set up by the threat actors in the IaaS environment was used to carry out a privileged Azure AD escalation attack.
- Following this, all accessible data was encrypted by the attackers who then issued a ransom note.
![]() |
| Figure 3. The kill chain employed by the Scattered Spider/Starfraud threat actor groups. Illustration courtesy of AppOmni. |
It is likely that these series of events were carried out by Scattered Spider/Starfraud over a span of several days. When SaaS serves as an entry point, a severe attack can encompass the corporate network and infrastructure. This type of SaaS/on-prem connectivity is prevalent in modern enterprise attack surfaces.
The rise of SaaS attack activity from both known and unknown threat actors
While most SaaS breaches may not be making headlines, the repercussions are substantial. According to IBM, data breaches in 2023 averaged $4.45 million per incident, representing a 15% increase over three years.
Threat actors are persistently relying on the same Tactics, Techniques, and Procedures (TTPs) and playbook of the Scattered Spider/Starfraud kill chain to gain unauthorized access and probe SaaS tenants, including platforms like Salesforce and M365 where misconfigurations could be exploited to obtain future access.
Other attackers initiate their access using session hijacking and impossible travel. Once the hijacked session is moved to a different host, their lateral movement frequently involves collaboration platforms like SharePoint, JIRA, DocuSign, and Slack, as well as document databases like Confluence. If they can reach GitHub or other source code repositories, threat actors will download that source code and scrutinize it for potential vulnerabilities within a target application. They will then attempt to leverage these vulnerabilities to exfiltrate the target app’s data.
The AppOmni threat intelligence briefing also highlights that data exfiltration through permission sharing remains a significant SaaS security issue. For instance, in Google Workspace, unauthorized users may elevate permissions to a very open level by changing directories. These permissions might be shared with another external entity via email forwarding or by altering conditional rules to include attackers as BCC recipients in a distribution list.
Securing your SaaS environments – What steps can you take?
1. Prioritize SaaS systems hygiene
Develop a process for reviewing and onboarding SaaS to determine which applications are permitted within your organization. This process should necessitate addressing security queries like:
- Is SOC 2 Type 2 certification mandatory for all SaaS applications?
- What is the recommended security setup for each tenant?
- How can your company prevent configuration deviation?
- How will you handle security control settings when automatic SaaS updates are deployed?
Ensure that you can identify Shadow IT SaaS (or unauthorized SaaS apps) and have a response plan in place to prevent alerts from going unnoticed.
If you are not consistently monitoring your SaaS tenants and aggregating their logs in a unified manner, detecting suspicious activities and receiving alerts based on them will remain a challenge.
2. Keep track of and continuously assess machine accounts/identities
Threat actors often target machine identities due to their privileged access and lax authentication standards that frequently lack Multi-Factor Authentication (MFA).
In 2023, threat actors successfully infiltrated and compromised major CI/CD tools like Travis CI, CircleCI, and Heroku, pilfering OAuth tokens for all customers using these services. The impact in such scenarios can be extensive.
Given that the average enterprise houses approximately 256 machine identities, maintenance of hygiene is typically subpar. Many of these identities are used sparingly and then left idle for extended periods.
Create an inventory of all your machine identities and categorize these as critical risks for remediation. Once these risks are addressed, establish policies that define:
- The qualifications vendors must meet to obtain machine identities and the types of accounts eligible for such access.
- The duration for which access/tokens remain active before renewal or revocation.
- The monitoring mechanisms for these accounts to track usage and ensure their continued necessity, particularly during periods of dormancy.
3. Implement a comprehensive Zero Trust architecture in your SaaS landscape
Zero Trust architecture enhances the principle of least privilege (PLP) with a philosophy of “never trust, always verify.” While Zero Trust has been well-established in conventional networks, its implementation in SaaS environments is often lacking.
Zero Trust Network Access (ZTNA) that focuses on the network aspect may overlook misconfigurations, machine integrations, or unauthorized user access entitlements within SaaS platforms, given the multitude of external users who interact with the data.
Zero Trust Posture Management (ZTPM), an emerging tool in SaaS security, extends the Zero Trust model to your SaaS setup. It bridges the security gap inherent in Secure Access Service Edge (SASE) by:
- Preventing unauthorized circumvention of ZTNA controls.
- Facilitating precise access decisions.
- Enforcing security policies with ongoing feedback loops.
- Extending Zero Trust to machine integrations and cloud connections.
With SSPM, ZTPM, and a comprehensive SaaS security program in position, your team will have the insight and intelligence essential to identify intruders during the initial phases of the kill chain, minimizing the risk of a catastrophic breach.



