Snowflake Cloud Breach: The threat of Credential Theft

In the last week of May 2024 an infamous hacking group ShinyHunters put on sale, 1.3 Terabytes of customer data from Ticketmaster on Breah Forums and priced it at $500,000.

Livenation acknowleged that they had detected unauthorized activity on a third-party database environment containing customer data of its Ticketmaster LLC subsidiary.

In another few days, ShinyHunters also put data from Santander a Spain based Bank. This included personally identifiable information of 30 million customers and employees and 28 million credit card numbers. The price was $2 million.

The third-party database provider was Snowflake. Snowflake started its own investigation and soon it became clear that Ticketmaster and Santander were only two of about 165 victims of an ongoing attack.

How did it happen?

One would think that such an attack would need some very sophisticated tools and tactics and brilliant minds to execute, but it wasn’t so. These were supply chain attacks and very simple.

The attackers used stolen credentials to get access to Snowflake accounts. These were obtained with infostealer campaigns using malware that infected non-Snowflake owned systems.

Several impacted organizations engaged Mandiant for investigations and incident management for this leak. Mandiant’s investigation revealed that the credentials used for accessing Snowflake accounts had been previously exposed using a variety of infostealer malware (VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA and METASTEALER) and some of these infostealer infections date back to November 2020.

Several of these initial compromise infostealer malware occurred in contractor owned systems that were also used for personal activities. These may have been contractors engaged by Snowflake or other organizations that use Snowflake. It is very likely these machines were not monitored.

According to this WIRED article, some of these stolen credentials were stored in plaintext in JIRA and were stolen by the infostealers.

What made it simple to use these stolen credentials was the fact that none of them required Multi-factor authentication. Only username and password were enough to gain access to the Snowflake databases.

Once they had access, the hackers used the web-based UI, SnowSight and CLI tool, SnowSQL to browse through the databases and exfiltrate data. Madiant also observed the use of attacker named utility “rapeflake”, what Mandiant calls Frostbite, along with publicly available DBeaver Utlimate DB management utility to connect to Snowflake cloud instances, query and exfiltrate data.

An attack waiting to happen

Some of these credentials used to access Snowflake DB had not been changed since 2020.

In this set of attacks, none of Snowflake’s vulnerabilities were exploited. The only thing that would have helped was having a mandatory Multi-Factor Authentication for all accounts on Snowflake cloud DBs, but there is always so much resistance to MFA that most companies do not make it mandatory for their customers.

Earlier this year, a similar technique was used for initial intrusion for the breach in Change Healthcare, that crippled claims and payments systems of healthcare providers for weeks. The threat actors used compromised credentials to enter through the Citrix portal. It did not have MFA enabled.

The attack on Snowflake was so simple, it was just a matter of time – the security cliché of “it’s not IF, but WHEN someone breaks in”

What can we do?

There were a number of things that are a strict no-no from a security point of view, yet many of us end up doing, just to avoid small inconveniences or because of lack of awareness.

1. Using unmanaged personal devices for accessing work related resources: JIRA, Code repos, databases, logs

2. Saving credentials in clear text on our local machines for quick lookups.

3. Sharing credentials in bug reports in steps to reproduce the bugs or in training documentation. Sometimes these are just test accounts, but it gives the attackers an entry into the systems.

4. Not changing passwords frequently unless we are forced to.

5. Not enabling MFA

In the case of Snowflake, ShinyHunters exploited this entire series of weaknesses of some of Snowflake’s customers.

A truly secure system comes from a combination of People, Processes and Technology. In addition to having the right security tech deployed, we also need to make sure we have the right set of processes in place. Creating security awareness among the people and proper training is equally important.