Snowflake: CrowdStrike and Mandiant say we're clean
"This appears to be a targeted campaign directed at users with single-factor authentication"
Snowflake brought in two of the world’s most high-profile incident response companies, CrowdStrike and Mandiant, to confirm its position that a string of customer data breaches were down to customer security failures rather than what it says was a limited incident at Snowflake itself.
Their joint statement on June 2 came as Ticketmaster confirmed that a major data breach resulted from a threat actor accessing its Snowflake environment. The Australian Cyber Security Centre (ACSC) meanwhile said on June 1 that it is “tracking increased cyber threat activity relating to Snowflake customer environments” and is “aware of successful compromises of several companies utilising Snowflake environments.”
Snowflake last week warned customers check for malicious traffic from an end user “identifying itself as rapeflake” and admitted it has seen “potentially unauthorized access to certain customer accounts” since May 23.
The data platform provider, which reported quarterly product revenues of $790 million last week, disputed initial characterisation on a now deleted blog from cybersecurity firm Hudson Rock that a threat actor had stolen Snowflake customer data, after using access to a staffer’s account to somehow enumerate security tokens via their ServiceNow environment.
A subsequent post by Hudson Rock suggests that Snowflake threatened it legally.
Diving into the recent #snowflake issues and digging into the stealer log theory, of the last few months we found 3,348 unique exposed credentials to snowflakecomputing resources. of those there were 124 identifiable unique email accounts, compromising credentials for large…
— SOS Intelligence (@SOSIntel) June 3, 2024
A “former employee” had been compromised but only a demo account was accessed, Snowflake said, with no pivot to corporate systems.
In a joint statement, CrowdStrike and Mandiant said: “we have not identified evidence suggesting this activity was caused by a vulnerability, misconfiguration, or breach of Snowflake’s platform; we have not identified evidence suggesting this activity was caused by compromised credentials of current or former Snowflake personnel; this appears to be a targeted campaign directed at users with single-factor authentication; as part of this campaign, threat actors have leveraged credentials previously purchased or obtained through infostealing malware…”
It was not immediately clear why multiple Snowflake customers fell victim at a similar time. It is in the realms of possibility that a cache of Snowflake customer credentials were sold simultaneously after a threat actor accessed them via an infostealer campaign. Snowflake meanwhile said “organizations [should] immediately take the following steps:
"Enforce Multi-Factor Authentication on all accounts;
"Set up Network Policy Rules to only allow authorized users or only allow traffic from trusted locations (VPN, Cloud workload NAT, etc.); and
"Impacted organizations should reset and rotate Snowflake credentials.
“This investigation is ongoing. We are also coordinating with law enforcement and other government authorities,” the company said.
Snowflake documentation shows that “Users are not automatically enrolled in MFA. To use MFA, users must enroll themselves.”
Potentially frustratingly for security professionals, a separate MFA FAQ also notes that “No, MFA can't be enforced for a role.”
Was your Snowflake environment compromised? Have insight from a security/customer perspective on this evolving story? Get in touch.
