The 2024 Snowflake Customer Attacks: A Breach With No Platform Vulnerability
Summary
In mid-2024, a threat actor accessed data held in a substantial number of Snowflake customer accounts, affecting several large organisations. Investigations by Snowflake, Mandiant and CrowdStrike concluded that the campaign did not result from any vulnerability, misconfiguration or breach of Snowflake's own platform.
Technical Root Cause
The attacker used valid customer credentials, largely obtained from infostealer malware that had infected individual machines, in some cases years earlier and in some cases on contractor systems rather than employee ones. Mandiant's analysis identified three conditions that characterised the affected accounts: the credentials had been exposed by infostealers, the accounts did not have multi-factor authentication enabled, and the credentials had not been rotated since exposure.
This maps most closely to CWE-1392 (Use of Default Credentials) in spirit and to CWE-308 (Use of Single-factor Authentication) directly, though the underlying failure is credential lifecycle rather than any single implementation flaw.
Why It Mattered
This case sharpened a question that arises with every SaaS platform: when customer data is taken through valid credentials on an account without MFA, where does responsibility sit? Snowflake's position, supported by the third-party investigations, was that the platform was not compromised. The practical consequence for customers was nonetheless a major data exposure.
The infostealer angle is the part most often underweighted. Credentials stolen from a personal or contractor machine years before remained valid, which means credential exposure has a long tail that a point-in-time security review will not surface. This is structurally similar to the LastPass case, where the entry point was also a machine outside normal corporate scope.
OWASP / CWE Mapping
- CWE-308: Use of Single-factor Authentication
- OWASP A07:2021: Identification and Authentication Failures
Lasting Impact
Snowflake subsequently made it possible for account administrators to enforce MFA across their organisation, and later moved toward requiring it by default for new accounts. The broader industry shift it reinforced is that optional MFA on a data platform is effectively a decision to accept credential-stuffing risk, and that platform providers increasingly treat enforcing it as their responsibility rather than the customer's preference.
How Safeguard Helps
The transferable practice is credential hygiene with a long memory: rotating on exposure rather than on schedule, and treating any credential that has ever appeared in an infostealer dump as compromised regardless of how long ago. Secrets scanning with live verification is aimed at the related problem of identifying which exposed credentials remain valid.
