Snowflake: No breach, just compromised credentials, say researchers

Most Snowflake customers can heave a sigh of relief: The cloud data platform’s systems do not appear to have been compromised, cybersecurity researchers at Mandiant reported Monday.

But they may have to make changes to how they authenticate to Snowflake all the same, as company is considering making multifactor authentication mandatory to access its systems.

Mandiant, a subsidiary of Google, has been investigating reports of a breach at Snowflake since April. It has found evidence that a threat actor it calls UNC5537 is systematically “compromising Snowflake customer instances using stolen customer credentials, advertising victim data for sale on cybercrime forum, and attempting to extort many of the victims,” it wrote in a blog post outlining its research.

The threat actor is “suspected to have stolen a significant volume of records from Snowflake customer environments,” it said.

Mandiant and Snowflake have notified 165 “potentially exposed organizations” so far, Mandiant said.

Compromised customer credentials

Mandiant stated in the blog post that its investigation to date has not found any evidence of unauthorized access stemming from a breach of Snowflake’s enterprise environment. Instead, it said, “every incident Mandiant responded to associated with this this campaign was traced back to compromised customer credentials.”

Snowflake first acknowledged reports of a potential compromise of its systems in late May, and has provided a number of updates on the situation since, most recently on Monday, when it wrote: “As we shared on June 6, we continue to work closely with our customers as they harden their security measures to reduce cyber threats to their businesses, and we are developing a plan to require our customers to implement advanced security controls, like multi-factor authentication (MFA) or network policies.”

Those changes are a response to Mandiant’s research, which found that three main factors led to the compromise of some Snowflake customers’ data:

• The impacted accounts were not configured with multi-factor authentication (MFA) enabled, meaning successful authentication only required a valid username and password.
• Credentials identified in infostealer malware output were still valid, in some cases years after they were stolen, and had not been rotated or updated.
• The impacted Snowflake customer instances did not have network allow lists in place to only allow access from trusted locations.

As Avishai Avivi, chief information security officer at SafeBreach, told CSOonline.com last week that the attacks on Snowflake customers raised questions about “the potential impact of shifting to massive data lakes hosted on a cloud provider. Combine this with compromised credentials and a session cookie hijack, and you have the perfect storm.”

The earliest evidence of access to Snowflake customer instances showed up on April 14, Mandiant wrote in its blog post, saying that it began investigating “data stolen from an unknown database” five days later.

By May 14, it had identified multiple Snowflake customer instances that had been affected, notifying the company and law enforcement agencies on May 22. Two days later, it observed the “earliest advertisement of Snowflake customer data for sale on cybercrime forums.” Snowflake published a statement and guidance on May 30 and on June 2, a joint statement was issued by Snowflake, Mandiant and CrowdStrike regarding the ongoing investigation.

Trading convenience for security

Charlie Winckless, VP analyst on Gartner’s cloud security team, said today the incident represents a classic case trading convenience for security, it being so much more convenient to not configure security controls.

The fact that Snowflake offered multifactor 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 as to 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.”

In general, he said, “many people will take the path of least resistance. I feel cloud providers would benefit in terms of credibility by having secure defaults and allowing educated users the ability to turn it off, rather than offering an insecure default, and asking the user to turn something on.”

UNC5537, said Winckless, has found a way in, and Snowflake is a “repository for an enormous amount of information that clients have chosen to put in 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.”