How to stay ahead of threat actors

Today’s kill chain escapes enterprises because they don’t protect the infrastructure of today’s business: SaaS.

SaaS continues to dominate software adoption, and it accounts for the largest share of government cloud spending. But both enterprises and SMBs haven’t overhauled their security programs and adopted security tools built for SaaS.

Security teams continue to jam on-premise patches to SaaS security holes

The mature security controls that CISOs and their teams depended on during the era of premier dominance are gone. Firewalls now protect a small perimeter, visibility is limited, and even when SaaS vendors offer logs, security teams need homegrown middleware to digest them and insert them into their SIEM.

SaaS vendors do have well-defined security areas 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 applications, no two SaaS applications have the same security settings.

Figure 1. In the context of SaaS security, the application vendor is responsible for the entire physical infrastructure as well as the network, OS, and applications. Customer is responsible for data security and identity management. SaaS’s shared responsibility model requires SaaS customers to take ownership of the components most commonly attacked by threat actors. Illustration courtesy of AppOmni.

AppOmni research reports that on average, one SaaS instance has 256 SaaS-to-SaaS connectionsmany of which are no longer used, but still have excessive permissions on core business applications such as Salesforce, Okta, and GitHub, among others.

Because of the many different SaaS security settings and the constant updates that change them, security services cannot effectively control these connections. The number of entry points increases exponentially as employees enable SaaS-to-SaaS (also known as “third parties” or “machines”) connectivity. Machine IDs can use API keys, secrets, sessions, digital certificates, cloud access keys, and other credentials to allow machines to interact with each other.

As the attack surface moved beyond the network perimeter, so did the kill chain — the way threat actors orchestrate the different phases of their attacks.

A modern SaaS chain of destruction typically includes:

1. Compromising the identity of an IdP through a successful phishing campaign, acquiring stolen credentials on the dark web, credential strings, credential stuffing, taking advantage of misconfigured SaaS tenants, or similar techniques.
2. Conducting a post-authentication reconnaissance phase. This move is reminiscent of attackers breaking into corporate networks of yesteryear. But now they’re combing document repositories, source code repositories, password repositories, Slack, Teams, and similar environments to find privileged entry points for escalation.
3. Using their findings to move toward other SaaS, PaaS, or IaaS tenants, and sometimes into corporate infrastructure—wherever they can find the data most valuable to the target organization.
4. Encrypting the crown jewels or delivering a ransom note and attempting to evade detection.

Figure 2. Successful SaaS destruction chains typically include four main steps: initial access, reconnaissance, lateral movement and persistence, and ransomware execution and security evasion. Illustration courtesy of AppOmni.

Breaking a Real SaaS Kill Chain: Scattered Spider/Starfraud

SaaS security leader AppOmni’s latest threat intelligence webinar outlines the chain of successful attack by Scattered Spider/Starfraud threat actor groups (ALPHV affiliates) against an undisclosed target in September 2023:

• A user opened a phishing email that contained links to a fake IdP login page and unknowingly logged into the fake IdP page.
• Threat actors immediately called this user and convinced them through social engineering to provide their time-based one-time password (TOTP) token.
• After obtaining the user’s credentials and the TOTP token, threat actors trick the MFA protocol into believing that they are a legitimate user.
• In reconnaissance mode, the threat actors had access to privilege escalation that allowed them to obtain credentials to Amazon S3, then Azure AD, and finally Citrix VDI (Virtual Desktop Infrastructure).
• The threat actors then deployed their own malicious server in an IaaS environment in which they performed a privilege escalation attack on Azure AD.
• 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 probably pulled off this series of events over several days. If SaaS serves as an entry point, a serious attack could involve the corporate network and infrastructure. This SaaS/on-prem connection is common in today’s enterprise attack surfaces.

SaaS attack activity from known and unknown threat actors is on the rise

Most SaaS breaches don’t dominate the headlines, but the consequences are significant. This is reported by IBM data breaches in 2023 averaged $4.45 million per copy, which is a 15% increase over three years.

Threat actors consistently rely on the same TTPs and Scattered Spider/Starfraud kill chain instruction to gain unauthorized access and scan SaaS tenants, including Salesforce and M365, where configuration issues can be manipulated to allow access later.

Other attackers gain initial access with session hijacking and impossible travel. Once they’ve moved a captured session to another host, their lateral move often includes communication platforms like 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 scrape that source code and analyze it for vulnerabilities in the target application. They will try to exploit these vulnerabilities to steal the target program’s data.

AppOmni’s threat intelligence briefing also reports that data theft through permission sharing remains a major SaaS security concern. This happens, for example, in Google Workspace when an unauthorized user changes directories to a very open permission level. An attacker can share them with another external entity through email forwarding or by modifying the conditional rules so that the attackers are included as BCC recipients in the mailing list.

How do you secure your SaaS environment?

1. Focus on the hygiene of SaaS systems

Establish a SaaS acceptance and review process to determine which SaaS you will allow in your company. This process should require answers to security questions such as:

• Should all SaaS be SOC 2 Type 2 certified?
• What is the optimal security configuration for each tenant?
• How does your company avoid configuration changes?
• How do I determine if automatic SaaS updates will require a change in security control settings?

Make sure you can detect Shadow IT SaaS (or unauthorized SaaS applications) and have a response program so that alerts are not created for nothing.

Unless you’re monitoring your SaaS tenants and receiving all their logs in some uniform way, you’ll never be able to detect suspicious behavior and receive alerts based on it.

2. Inventory and continuous monitoring of machine accounts/IDs

Threat actors target machine IDs for their privileged access and weak authentication standards, often rarely requiring MFA.

In 2023, threat actors successfully hacked the main CI/CD tools Travis CI, CircleCI, and Heroku, stealing OAuth tokens for all of those vendors’ customers. In these situations, the blast radius increases significantly.

With the average enterprise containing 256 machine IDs, hygiene is often lacking. Many of them are used once or twice and then remain stagnant for years.

Take inventory of all your machine credentials and sort out those critical risks. Once you’ve mitigated them, create a policy that mandates:

• What types of accounts will be provided with machine IDs and what requirements these providers must meet to gain access.
• The length of time their access/tokens are active before they are revoked, renewed or re-granted.
• How will you monitor the usage of these accounts and ensure they are still needed when they have periods of dormancy.

3. Create a true Zero Trust architecture in your SaaS real estate

The zero-trust architecture is based on the principle of least privilege (PLP) with a “never trust, always verify” approach. While Zero Trust has been established in traditional networks, it is rarely achieved in a SaaS environment.

The network-centric approach of Zero Trust Network Access (ZTNA) cannot detect misconfigurations, machine integration or unwanted user access rights inside and to SaaS platforms that may have thousands or even millions of external users accessing data.

Zero Trust Posture Management (ZTPM), a new SaaS security tool, extends Zero Trust to your SaaS estate. It closes the SaaS security gap that SASE creates:

• Preventing unauthorized bypass of ZTNA
• Allowing fine-tuning of access decisions
• Enforcing your security policy with continuous feedback
• Extending Zero Trust to machine integration and cloud connections

With SSPM, ZTPM and a SaaS security software onsite, your team will gain the visibility and intelligence needed to identify attackers at low-risk stages of your supply chain—and stop them before a breach becomes devastating.