Snowflake link and broader impact identified

The next major development in this incident came when security vendor Hudson Rock published details about a direct online chat with ShinyHunters, during which the threat actor group claimed that it had compromised Snowflake and stolen data from hundreds of the company’s customers in addition to Ticketmaster. The Hudson Rock report, which included a claim from ShinyHunters that they had successfully accessed a Snowflake employee’s ServiceNow account, was later taken down from the company’s website in response to a letter from Snowflake’s legal counsel.

However, Snowflake has acknowledged publicly that it is actively investigating a security incident involving authorized access to its customers’ accounts, also stating, “We believe this is the result of ongoing industry-wide, identity-based attacks with the intent to obtain customer data.”  

As part of its response, the company has engaged Crowdstrike and Mandiant to assist in determining the scope of compromise. As of this writing, Snowflake says that this investigation has not:

• Identified evidence of a vulnerability, misconfiguration, or breach of Snowflake’s platform
• Identified evidence suggesting this activity was caused by compromised credentials of current or former Snowflake personnel

They did, however, acknowledge that a threat actor obtained access to demo accounts created by a former Snowflake employee outside of the company’s identity and access management (IAM) and MFA systems.

On June 10, Mandiant published a detailed report about their investigation of the incident affecting Snowflake customers. Consistent with Snowflake’s statements, Mandiant also indicated that they did not find evidence of a compromise to Snowflake’s enterprise environment. They did, however, provide the additional information that at least 165 Snowflake customers have potentially been affected by wide-scale credential theft and misuse.

How the Credential Theft Occurred

Another noteworthy piece of information shared by Mandiant is the method ShinyHunters (which Mandiant tracks as UNC5537) used to steal the Snowflake customers’ credentials. It appears that hundreds of Snowflake’s customers have been infected with variants of the infostealer malware that is commonly used for credential theft, dating back as far as 2020. According to Mandiant, many of these infections were of contractor devices, where a single infection could potentially compromise credentials of multiple Snowflake customers.

What this incident tells us about the state of identity security

While this incident is still developing, it already stands as yet another example of the need for post-authentication identity threat detection for SaaS applications and cloud services.

Here are two key reasons for this:

IAM and MFA, while essential, are not infallible

Security teams should, of course, continue to invest in strong preventative identity security measures like IAM and MFA. This includes evaluating next-generation approaches such as passwordless authentication based FIDO2 standards and passkeys, which can streamline user experience without compromising effectiveness. At the same time, organizations cannot view effective preventive controls as the end game. As Mandiant notes in its report, credential theft was still the fourth most notable initial intrusion vector in 2023, with 10% of intrusions beginning in this manner.

Mandiant also predicts that this specific threat actor will likely target customers of other SaaS platforms with similar forms of credential theft and misuse, noting that:

“This campaign highlights the consequences of vast amounts of credentials circulating on the infostealer marketplace and may be representative of a specific focus by threat actors on similar SaaS platforms. Mandiant assesses UNC5337 will continue this pattern of intrusion, targeting additional SaaS platforms in the near future.”

SaaS applications and cloud provider breaches will be an ongoing fact of life

Cloud service providers represent some of the highest concentrations of security talent and security tool investments in the industry. But all it takes is one error or non-compliant action to open the door to a critical incident, and no team or toolset is perfect. We’ve seen evidence time and again, including the Okta and Microsoft examples we covered previously, of very sophisticated SaaS and cloud service providers experiencing identity security breakdowns.

So, it’s important not to rush to judgment in situations like this latest incident at Snowflake. While enterprises should hold their cloud providers to a high standard for security, it’s also important to remember that under the shared responsibility model that applies to most SaaS and cloud provider relationships, identity security is first and foremost the responsibility of the customer. For example, while Snowflake is a common thread in this incident, it appears that the compromises were the result of gaps in individual customers’ endpoint protection and identity security practices. This underscores two important points:

1. Even if you are entrusting your data to a cloud or SaaS provider, you are still ultimately responsible for protecting it
2. A breach of your SaaS or cloud footprint may originate from other areas of your attack surface that your provider has no control over

Therefore, the best practices in this area are to:

• Assume that your SaaS applications and cloud service providers will be breached at some point
• Assume that successful account takeovers and credential misuse will occur
• Put measures in place to detect and mitigate both of these scenarios

As Charlie Winkless, VP analyst on Gartner’s cloud security team, told CSO Magazine in this article, the fact that Snowflake offered multi-factor authentication through Dual Client Connect to its clients does not guarantee that many of them will turn it on, “because it’s a separate integration and more that they have to do. And it is a fine line whether it is Snowflake’s job to make things secure, by default, or whether it is Snowflake’s job to sell their product to other clients.”  

Winckless also notes that UNC5537 has found a way in and Snowflake is a “repository for an enormous amount of information that clients have chosen to put there. Those clients are the ones who know how sensitive that data is. Snowflake, ultimately, does have no idea of how critical that data is.”

How to mitigate risk in situations like the Snowflake security incident

Limiting the impact to your organization when incidents like this occur of course starts with making sure you have the fundamentals of identity protection in place, including:

• Good IAM and MFA hygiene, such as avoiding less reliable methods such as SMS and monitoring logs for instances of authentication that circumvent your IAM platform.
• Using privileged access management (PAM) to tightly limit the access of individual accounts to only the resources that they absolutely must have access to.

But these and other preventative measures are not enough.

The critical gap that many organizations still have in this equation is a continuous monitoring and validation approach for trusted identities and their usage post-authentication. This involves monitoring user behavior across applications, including SaaS products, custom-built applications, and all cloud service providers. By quickly and accurately detecting and alerting on suspicious behavior, you can bolster your defenses against insider threats, credential misuse as a result of identity compromise, third-party risk, PAM issues, and more.

We will continue to monitor this situation as more information is released.

Contact us to learn more about Reveal Security’s approach to identity threat detection and response in and across ANY application, including SaaS applications and cloud service providers like Snowflake, to enhance your organization’s cyber resilience.

Contact us to learn more about Reveal Security’s unique approach to post auth identity threat detection and response for SaaS and cloud.