See our updated story of June 3 with more details here.
Snowflake has 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 denied any production environment was compromised nor employee credentials used to sidestep security controls in a statement on May 31– saying the attacks resulted from separate theft of customer credentials.
It did, however, admit that “threat actor obtained personal credentials to and accessed a demo account owned by a former Snowflake employee.”
Snowflake claims this did not contain sensitive data and was not connected to production or corporate systems; i.e. it is unrelated in terms of security to the customer breaches.
Snowflake breach: Cause of Ticketmaster incident?
Recent data breaches at Ticketmaster and Santander have been attributed to malicious access to their Snowflake environments. (Ticketmaster owner Live Nation had cited "unauthorized activity within a third-party cloud database environment" as cause of the incident in an SEC filing.)
In a now-deleted blog, threat intelligence firm Hudson Rock said a cybercriminal selling data from these breaches told its researchers that they had been able to compromise a Snowflake employee’s ServiceNow account using credentials stolen via infostealer malware, bypassing SSO provider OKTA.
“Following the infiltration, the threat actor claims that they were able to generate session tokens, which enabled them to exfiltrate massive amounts of data from the company,” Hudson Rock wrote on May 31. The Stack could not independently verify these claims and threat actors can exaggerate their access. Software vendors can also play down impact when it comes to security disclosures. Snowflake denies this happened.
The cybersecurity firm said it identified in leaked files that a Snowflake employee had been infected by a Lumma-type Infostealer in October ‘23.
The alleged hacker told Hudson Rock that “Snowflake are retarded.
“Their refresh tokens don’t expire even tho [sic] it says ‘14400 second’ [sic] or whatever in the expiry so I just dumped them from lift [a then-public facing Snowflake subdomain] and i can generate session tokens with them.” (In short, it appears that they were potentially able to capture login credentials and then use a non-refreshed security key to then generate various other session tokens into customer environments.)
Snowflake is denying this.
But Snowflake does say in separate guidance, with IOCs and malicious IPs, that “if you have enabled the ALLOW_ID_TOKEN parameter on your account, the user must be left in the disabled state for 6 hours to fully invalidate any possible unauthorized access via this ID token feature.
“ If the user is re-enabled before this time the attacker may be able to generate a new session using an existing ID token, even after the password has been reset or MFA has been enabled.”
Snowflake said late May 31: “We are aware of recent reports related to a potential compromise of the Snowflake production environment… We have no evidence suggesting this activity was caused by any vulnerability, misconfiguration, or breach of Snowflake’s product… Snowflake does not believe that it was the source of any of the leaked customer credentials.
“Snowflake recently observed and is investigating an increase in cyber threat activity targeting some of our customers’ accounts. We believe this is the result of ongoing industry-wide, identity-based attacks with the intent to obtain customer data. Research indicates that these types of attacks are performed with our customers’ user credentials that were exposed through unrelated cyber threat activity,” the company said.
