Snowflake: Looking back on 2024’s landmark security event

The attacks on Snowflake customers in 2024 collectively constituted the biggest cyber security event of the year in terms of the number of organizations and individuals affected (at least, if you exclude CrowdStrike causing a worldwide outage in July) — certainly, it was the largest perpetrated by a criminal group against commercial enterprises. It has been touted by some news outlets as ‘one of the biggest breaches ever’.  

Snowflake was a watershed moment that signalled the significant opportunity presented by identity attacks on cloud services. It demonstrated how comparatively unsophisticated methods (logging in to user accounts with stolen credentials and dumping the data) can have the same or greater impact as a traditional network or endpoint based cyber attack involving vulnerability exploitation, malware deployment, ransomware, etc. 

Here’s everything you need to know about the Snowflake attacks — and what you can do to protect yourself against the next Snowflake in the future.

Snowflake: The facts

Cyber criminals associated with the threat group known as ShinyHunters claimed responsibility for breaching multiple organizations using Snowflake, a cloud-based data warehousing and analytics platform. 

ShinyHunters associates targeted ~165 organizations that were subjected to account takeover attacks using stolen credentials harvested from historical infostealer infections dating back as far as 2020, according to Mandiant’s investigation. 

The impacted accounts lacked MFA, meaning successful authentication only required a valid username and password. As the Snowflake credentials found in infostealer malware credential dumps had not been rotated or updated, they remained valid and could be used to authenticate to user accounts on Snowflake tenants belonging to various customers.

As a data warehousing platform integrated with a range of connected cloud services, access to a customer’s Snowflake tenant provided attackers with large quantities of sensitive commercial and personal data that could be stolen and monetized by attackers in a variety of ways — such as by ransoming the victim organization, extorting individual end-customers, and selling the data on to other criminal organizations. 

In total, 9 public victims were named following the breach, collectively impacting hundreds of millions of people. 

• Lending Tree: Sensitive data for over 190 million people available online including customer details, partial credit card numbers, insurance quotes and other information, being sold for $2m.

• Truist Bank: Information belonging to 65,000 employees being sold online for $1m

• Advance Auto Parts: 3TB of data for sale for $1.5 million. Affected 2.3 million people, as well as current and former employees and job applicants.

• Pure Storage: Workspace with 11k customer records including company, email, LDAP username and software version numbers.

• Los Angeles Unified: Student data, disability information, discipline details, and parent information, being sold online for $150k.

• Neiman Marcus: 31m email addresses exposed alongside various personal information.

• Santander: 30 million customer details for sale relating to customers of Santander Chile, Spain, and Uruguay.

• Ticketmaster: 560 million customer details for sale, disruption to events and ticketing worldwide, increasing in scam ticket production.

• AT&T: Call logs stolen for approximately 109 million customers (nearly all of its mobile customers). AT&T paid an undisclosed ransom fee.

The Snowflake attacks step-by-step

• Snowflake users were infected with infostealer malware that harvested credentials from user devices over an extended period via several infostealer malware variants, including; VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA and METASTEALER.

• Credentials appeared on criminal marketplaces e.g. dark web forums and Telegram channels.

• ShinyHunters saw the potential in targeting Snowflake users, based on the availability of credentials, number of customer organizations, and the value of the data that can be accessed in Snowflake. 

• ShinyHunters embarked on a large-scale campaign targeting Snowflake customer accounts using previously breached credentials. 

• ShinyHunters accessed user accounts that lacked MFA, belonging to approximately 165 Snowflake customers. 

• ShinyHunters used SQL-based reconnaissance, staging, and data exfiltration techniques, expedited by custom hacker tooling developed specifically for Snowflake, to conduct attacks at scale.

• ShinyHunters acquired massive quantities of Snowflake data based on the information that each customer stored in Snowflake or connected apps. 

• ShinyHunters began attempts to extort Snowflake and end-customers using the data acquired.

Why did the Snowflake breaches happen?

Stolen credentials remained valid for years

The credentials used to access Snowflake accounts from historical infostealer infections had not been changed or rotated despite dating back as far as 2020, and remained valid. 

This highlights the potential risk of breached credentials already in the public domain, particularly in the case of cloud services like Snowflake that may not be subject to the same levels of credential hygiene as other traditional enterprise domain accounts. 

Local logins lacked MFA 

Even where organizations were primarily encouraging employees to use SSO to access their Snowflake tenant, previously created local logins with a username and password continue to exist even after introducing SSO-based logins. Further, MFA was not globally enforceable at the application level, meaning that MFA was only set when logging into an IdP account for SSO, but not for local logins. We call this problem ghost logins. 

This meant that attackers were able to take over Snowflake accounts with only a single authentication factor (username & password). 

Snowflake was a high-value target used by many organizations

As a data warehousing platform used by a vast number of organizations, Snowflake represented a high-value target based on the data typically stored within it, and the repeatable way in which Snowflake users could be targeted. 

The attacker followed a near identical process when targeting Snowflake victims, meaning it could be scripted and executed at scale, with attacks taking a matter of minutes. 

Infostealer infections are driving credential availability

Infostealers are often seen as a low-priority issue, but are the primary source of stolen credentials used in campaigns like this one. 

EDR is a strong protection but is often bypassed by infostealers as attackers continually modify them to bypass security controls. Further, unmanaged devices such as those used by third-party contractors or BYOD employees often lack the robust controls applied to company-managed devices and are naturally more susceptible to infostealer attacks. And since browser profiles can be synced across devices, even personal device compromises can result in the capture of corporate credentials.  

There is some suggestion that targeting key third-party suppliers – such as EPAM Systems, a software engineering firm and Snowflake ‘Elite Tier Partner’ – provided some of the access to Snowflake customers needed. It’s unclear what came first, but it’s possible (likely, even) that EPAM was identified as a target specifically because of its lucrative customer base and Snowflake credentials — adding another indicator that Snowflake was potentially a premeditated attack inspired by the availability of Snowflake credentials online.

Key takeaways from the Snowflake attacks

Securing your IdP accounts is not enough

SSO can help reduce your identity attack surface, but it's not feasible to get every workforce identity behind it.

• Only 1 in 3 apps support SAML SSO, and those that offer it often charge more for it; the “SSO tax”.

• Many apps are self-adopted by employees, leaving security teams unaware and unable to enforce SSO.  The typical organization has hundreds of apps and thousands of unmanaged identities outside of SSO.

• Most apps do not prevent users from creating additional "ghost login" methods outside of SSO (especially by default), accounting for around 10% of all identities observed by Push. 

• In total, we identified that 37% (2 in 5) accounts have a password login set with no MFA, while 9% have no MFA AND a weak, breached, or reused password.

So, relying on locked-down IdP accounts and maximising the use of SSO is an important pillar of an effective identity security strategy, but there will always be gaps. Unless you recognize this, you may be blindsided by attackers finding them before you do. 

The threat of infostealers and stolen credentials needs to be taken seriously

Breached credentials appearing online is not always seen as a top priority for security teams, particularly when there’s so much noise from all of the outdated or simply erroneous findings (anyone that’s ever subscribed to a credential TI feed knows the pain of this). 

But Snowflake serves as a stark reminder that despite all the false positives, stolen credentials are sometimes valid — and when weaponized at-scale they can be a powerful tool for attackers. 

Don’t rely on third-parties to protect your identities for you

Snowflake came under fire following the attacks for not enabling MFA by default, or giving security teams sufficient tools to deal with the incident. 

This is perhaps justifiable, but is hardly the exception. Very few apps enforce MFA by default or provide a global MFA enforcement mechanism. Most don’t even provide audit logs (and when they do, the scope of logging is pretty limited). And we regularly encounter apps that don’t give you any information about account configuration as an admin — like which accounts have MFA, or the login methods that they’re using (e.g. SSO via SAML, SSO via OIDC, password, which IdPs are being used…) which is essential information to be able to secure your identity attack surface. 

Yes, it would be great if app vendors put security first and made controls available by default, for all customers (not just the premium ones). But in the absence of an industrywide shift toward security-first product development, it’s important that organizations don’t just point the finger at service providers — and take matters into their own hands when it comes to securing their user identities. 

This isn’t a specific Snowflake problem — it could have been any application

While Snowflake was admittedly a high-value target because of the data it collected, apps with sensitive data (or with integrations connecting them to data collected in adjacent apps) are not in short supply. 

If we accept that many other apps are similarly desirable targets, then we should also consider that it’s unlikely that Snowflake is the only app that has valid credentials sitting around on the internet, waiting to be weaponized by criminals. Equally, it’s not the only app that doesn’t require mandatory MFA for user accounts, as we discussed above. The next Snowflake is likely to lurk in the same breached datasets, possibly even using the same credentials.

There’s been a clear increase in the number of infostealer and stolen credential related breaches and news stories since Snowflake as attackers wise up to the potential opportunity and start seeing the dollar signs. It would be naive to think that this was a one off event — the next Snowflake is probably not too far away. 

For a deep-dive analysis of the impact of Snowflake, check out our on-demand webinar from earlier this year.

How to protect yourself from the next Snowflake using Push

Organizations looking to reduce their exposure to account takeover using stolen credentials should look to:

• Identify the apps being used across the business and locate vulnerable workforce identities using weak, breached, or reused credentials, and missing MFA. Where SSO is the preferred login method, local username & password logins should ideally be removed. 

• Where credentials appear in third-party data breaches, verify where they are still valid and ensure that the credentials are changed. 

• Detect unauthorized access to workforce identities where sessions are initiated or resumed from unusual or unexpected locations. It should be noted that while this is a fairly common feature for larger enterprise cloud platforms with configurable access control policies, this is not typically possible for most SaaS applications.  

All of these use cases can be achieved using Push. The Push browser extension detects all logins performed in employee browsers, capturing granular information about the login method and MFA types used, and enriching this data by integrating with your preferred IdP.

Push’s verified stolen credential detection feature compares a k-anonymized hash of user passwords observed with stolen credential TI feeds to cut through the noise and identify where stolen credentials appearing online represent a genuine vulnerability.   

On top of this, all logins made in browsers protected by the Push extension, across every app, are verified by adding a unique marker to the user agent string of the session, which will then appear in your IdP logs. This means that any session occurring outside of the Push-protected estate can be flagged to your security team via SIEM alert — including where an attacker uses stolen credentials to log into an app from a browser without the Push extension running.