Snowflake has pinned the blame for a series of high-profile data breaches in recent days on customers failing to adequately secure production environments by using two-factor authentication.
In a statement on 2 June 2024, Snowflake CISO Brad Jones pushed back on claims that major data breaches involving Ticketmaster and Santander were caused by a vulnerability or misconfiguration in Snowflake’s platform.
The speculation arose after both Ticketmaster and Santander recently confirmed cyber attacks that exposed sensitive data belonging to several hundred million of customers.
Last week, Ticketmaster revealed that personal information linked to over 560 million users was leaked after the ShinyHunters threat group claimed to be selling a 1.3TB database on an underground forum.
Similarly, Santander announced that all of its employees, as well as a significant number of its customers, had details leaked during an attack earlier this year.
The same group advertising the alleged Ticketmaster info, ShinyHunters, claimed to have bank account details associated with 30 million customers, 28 million credit card numbers, and HR information related to Santander staff, for sale on the newly resurrected BreachForums platform.
Santander’s statement confirming the incident claimed the company had recently been made “aware of an unauthorized access to a Santander database hosted by a third-party provider.”
Cyber crime intelligence firm Hudson Rock published a report last week claiming the attacks stemmed from a hacker who had broken into an employee account at Snowflake, using stolen credentials to bypass Okta’s secure authentication system.
This report has since been taken down, however, further fueling speculation over the source of the breach.
ITPro has approached Hudson Rock for clarification.
Snowflake confirms criminals accessed an unsecured demo account
Cloud security company Mitiga also published an investigation into the incident and found evidence of an extensive campaign of data theft and extortion targeting organizations utilizing Snowflake databases.
The report stated a threat actor labeled UNC5537 had been observed using custom tools to find Snowflake instances and employed credential stuffing techniques to gain access. Once inside, they were able to leverage built-in Snowflake features to exfiltrate data.
Ariel Parnes, co-founder at Mitiga, said that if the breaches are confirmed to be linked to Snowflake, then this could be the start of a long, drawn out saga of disruption.
“If this is a breach related to Snowflake, incidents like Santander and Ticketmaster breaches may just be the beginning. With Snowflake being deployed in thousands of organizations globally, the potential for widespread impact is substantial,” Parnes said.
“The news about the potential Snowflake breach is alarming in the industry, and security teams are working in emergency mode to assess whether they are indirect victims of this attack.”
In his statement acknowledging the incident, Jones denied the breaches were the result of any vulnerability or misconfiguration in Snowflake environments.
Instead, Jones confirmed the attacks appear to be part of a targeted campaign directed at users with single factor authentication enabled on their production environments, making them susceptible to credential stuffing attacks.
Jones said the credentials leveraged in the attack were previously purchased or obtained through infostealing malware, adding that Snowflake did find evidence that a threat actor obtained personal credentials to and accessed demo accounts belonging to a former employee.
Jones noted that the demo environment in question did not contain sensitive data and that these accounts are not connected to Snowflake’s corporate or production environments.
His statement stressed that the access was only made possible because the demo account did not have Okta or MFA security layers applied, unlike the company’s corporate and production systems.
As a result, Jones said organizations should immediately ensure they have MFA enforced on all accounts, they set up network policy rules to only allow authorized users or only allow traffic from trusted locations, and to reset and rotate all Snowflake credentials.
