Snowflake customer breaches: no MFA, stolen passwords, 160+ companies

What happened

In mid-2024, a threat actor tracked as UNC5537 carried out a sweeping campaign against customers of the cloud data platform Snowflake. Rather than exploiting a software vulnerability, the attackers logged in with valid usernames and passwords that had been harvested earlier by infostealer malware running on employees' and contractors' machines. Over 160 customer environments were accessed.

The victims included some of the largest data holders in the world. Ticketmaster/Live Nation saw roughly 560 million records exposed, and AT&T had call and text metadata covering nearly all of its U.S. customers stolen; AT&T reportedly paid about $370,000 in an attempt to have the data deleted. Other named victims spanned Santander Bank, LendingTree, Advance Auto Parts, and Neiman Marcus. Arrests followed later in 2024.

Root cause

The breaches were an authentication failure (CWE-1391, use of weak or compromised credentials). The affected Snowflake accounts were protected by passwords alone, with no enforced multi-factor authentication and, in many cases, no network allow-listing. Once credentials leaked through infostealers — often months earlier — nothing stood between the attacker and the data. Snowflake's own systems were not breached; the customers' identity configuration was the gap.

How it would have been caught

A configuration audit that enumerates accounts lacking MFA, or lacking network policy restrictions, would have flagged every exposed environment before exploitation. Credential-exposure monitoring cross-references known infostealer dumps against active accounts. A reproduction takes a valid-but-leaked credential and confirms it grants a full data session from an arbitrary network location, with no second factor requested.

How to prevent it

• Enforce MFA on every account by policy — not as an opt-in — for any system holding sensitive data.
• Restrict access with network allow-lists so credentials alone are insufficient from an unknown source.
• Rotate credentials on a schedule and immediately when infostealer exposure is detected on any endpoint with platform access.
• Alert on logins from new locations, new clients, or unusual bulk-export volumes.

The Breachwire test (red → green)

Take a valid username and password for a test account with no MFA and confirm they grant a full authenticated data session from an unrecognized network — the RED control. Enforce MFA and a network allow-list on the account, replay the same credentials from the same location, and confirm access is refused without the second factor and outside the allowed network, while a properly enrolled user still gets in.