Step-by-Step Guidance to Secure SaaS Environments including Snowflake and ServiceNow

by: Allan Kristensen, Chief Customer Officer, AppOmni

Late last week, news broke about SaaS breaches at many firms, this time involving Snowflake. Snowflake has said that the breaches were caused by customers failing to adequately secure production environments by using two-factor authentication. While facts are still emerging on the causes of the breach and the exact way in which attackers were able to compromise the application, it is clear that SaaS applications are under attack and any vulnerability or misconfiguration in these applications will be quickly exploited by bad actors. The breaches continue to reiterate the importance of proactive attention to SaaS security posture and not just reactive strategies to analyze threats and anomalies.

This article provides step-by-step guidance on how customers can secure their SaaS applications proactively including Snowflake and ServiceNow.

What is Snowflake?

Snowflake is a data storage and analytics SaaS platform. The company offers a data warehousing solution that enables workload elasticity, performance optimization, data sharing, compliance, and ecosystem connectivity. 

Chain of Events 

Note: This is an account of what we know from publicly available sources as of this writing. The data breach is the subject of on-going investigations. We will update this blog as more confirmed details are released.

First Attack Vector: Leveraged Stolen Credentials

1. Threat actors allegedly bought stolen credentials for a Snowflake employee.
   • Credentials can include passwords, tokens, or cookies for valid sessions, which can allow an attacker to bypass MFA.
2. Attempted to access the IdP and then bypassed it through a direct login to the ServiceNow system.
   • Once infiltrated, the threat actor claimed they were able to generate session tokens, enabling exfiltration of massive amounts of data. This includes support and case-related information for customers with which the compromised SE or support engineer was working on.
   • ServiceNow SSO is optional by default and was not configured to enforce SSO. It must be specifically configured to make SSO mandatory. Otherwise, SSO can be bypassed through a sidedoor. 

Extortion was allegedly the attacker’s main goal.

Second Attack Vector: Credential Stuffing Attack

1. A possible different threat actor (labeled UNC5537) has been observed using custom tools to find Snowflake instances and employed credential stuffing techniques.
   • The stolen credentials were allegedly purchased or obtained through info-stealing malware.
2. Accessed demo accounts belonging to a former employee—which did not have MFA or SSO enforced—did not contain sensitive data. 

This ongoing campaign involves continuous data theft and alleged extortion aimed at organizations using Snowflake databases and single-factor authentication.

Guidance to secure your SaaS environments and how AppOmni can help

1— Ensure SSO is enabled and MFA is required for all employees accessing sensitive data, both internal and external.

How AppOmni can help prevent SSO bypass

• AppOmni automatically detects and alerts if SSO is enabled, but not enforced in Snowflake and ServiceNow. 
• Detecting and remediating this misconfiguration would have prevented the attacker from gaining access to ServiceNow with the stolen credential.

2— Ensure SSO/MFA can’t be bypassed.

SSO enhances security by allowing users to access the instance with one set of credentials, managed by a centralized identity provider (IdP). This setup improves security through strong password policies and multi-factor authentication, reducing phishing risks. However, a secondary authentication path in SaaS apps like ServiceNow and Snowflake can bypass SSO, allowing logins with local credentials. If not disabled, this path can let malicious actors access the instance with any user’s local credentials.

While SSO aims to secure authentication, misconfigured settings can lead to SSO not being enforced. In such cases, if attackers obtain local credentials, they can gain unauthorized access to the instance.

AppOmni helps by providing continuous monitoring to identify and flag potential misconfigurations and hidden vulnerabilities, ensuring that security measures like SSO and MFA are correctly configured and enforced. This proactive monitoring prevents unauthorized access and secures your SaaS environment from threats.

3— Ensure IP restrictions are enabled and not overly permissive.

Snowflake recently published their investigative and hardening guidelines, providing a list of suspicious IP addresses and malicious traffic from clients exhibiting specific characteristics. These can be detected with AppOmni’s Threat Detection and rule Indicator of Compromise (IoC) Detected from Snowflake Breach.

In general, configuring IP address ranges is a crucial activity measure for controlling access at the infrastructure level. Allowing overly permissive IP ranges increases the likelihood of unauthorized access. 

It’s best practice to restrict IP ranges as much as possible—configured to lock down access to your Snowflake and ServiceNow instance—without hindering legitimate user access.

AppOmni automatically detects and alerts on over permissive ServiceNow IP ranges.

4— Avoid uploading sensitive data to unsecured demo or sandbox accounts.

AppOmni automatically detects and alerts on SDLC misconfigurations prior to risky configurations being introduced / moved to Production environments.  Examples:

• SSO is enabled, but not enforced in ServiceNow.
• Over permissive ServiceNow IP ranges

5— Monitor Threat Detection alerts.

Each SaaS application produces audit logs in its native language, continuously updates the product with new functionality, and introduces unique business risks based on stored data and solution implementation. As a result, many SOC teams lack visibility into SaaS activity across all platforms, waste countless hours on data engineering, do not have sufficient knowledge of the unique risks of each SaaS platform, or deal with excessive noise from generic detections that lead to alert fatigue. 

Nowadays, attackers are smart enough to use exit nodes that are close to the region where the stolen account user is in, but this is a good practice to monitor regardless. Other detection rules like Mass Download, Password Resets and Privilege Escalation happening for the same user are also potential indications of attacker behavior.

An AppOmni detection rule like “Impossible Time Travel” could potentially alert you to someone using stolen credentials to log into your SaaS tenants. In addition, AppOmni includes threat detection rules and alerts for the latest Snowflake IoC related to the attack. 

6— Disable accounts that are no longer active.

Disabling inactive accounts is essential in today’s interconnected SaaS environment, as these dormant accounts can become gateways for hackers to infiltrate systems and compromise sensitive information. 

AppOmni provides comprehensive visibility into user identities and activities across all monitored services, enabling customers to identify inactive accounts, including those with elevated permissions, and promptly disable them to minimize security risks and protect sensitive data.

Time to Enforce Granular Controls With The Zero Trust Capabilities in SSPM

Insecure configuration of SaaS applications can undermine protections by allowing users to access these apps directly—in this case, bypassing single sign-on (SSO) and opening up to direct attacks such as credential stuffing. 

Combined, AppOmni’s SaaS Security Posture Management (SSPM) platform and Zero Trust Posture Management (ZTPM) capabilities provides a true end-to-end Zero Trust architecture, including analysis of SaaS app configurations where SSO bypasses may be available.

The AppOmni team is ready to answer customer inquiries and provide additional support on this matter. Please do not hesitate to reach out to us: info@appomni.com.

Media Commentary by AppOmni

CPO Magazine
Brian Soby, CTO and co-founder at AppOmni, sees the data breach and associated attacks as yet another incident that makes the case for zero trust architecture.

InformationWeek
Brian Soby, CTO and co-founder of SaaS security firm AppOmni, says the source of the breach likely extends beyond the single instance of the former Snowflake employee’s credentials being used.

CSO Online
“The incident playing out at Snowflake is due to the same issue we’re seeing across the market, companies are not incorporating the security of their SaaS applications into their security architectures,” said Brian Soby, chief technology officer and co-founder at AppOmni. 

ChannelFutures
“… an attacker simply bought stolen credentials and used them to log in directly to Snowflake’s ServiceNow instance, as it was misconfigured to allow Single Sign On (SSO) to be optional instead of mandatory,” said Brian Soby, chief technology officer and co-founder at AppOmni.