CASE-21 · Case Study — Snowflake 2024: Stolen Passwords, No Second Factor

What happened

In mid-2024, a wave of data thefts hit roughly 165 organizations — including big names like Ticketmaster and AT&T — and they all had one thing in common: their data lived in Snowflake, the cloud data platform. But Snowflake itself wasn't breached. The attacker, tracked as UNC5537, simply logged in.

The credentials came from infostealer malware that had infected employees' and contractors' machines — some of them years earlier — quietly harvesting saved usernames and passwords. Because many of the affected Snowflake customer accounts had no multi-factor authentication and no network restrictions, a valid username and password was all it took. The attacker used those to log into customer data warehouses, bulk-export the data, and then extort the victims.

See it — from an old infection to a data theft

flowchart LR
  A["Infostealer harvests<br/>saved passwords"] --> B["Credentials sold<br/>/ reused"]
  B --> C["Log in to Snowflake<br/>(no MFA)"]
  C --> D["Bulk-export<br/>customer data"]
  D --> E["Extortion"]

The root cause

The root cause sits squarely on the customer side of the shared responsibility model: single-factor authentication on accounts holding enormous volumes of sensitive data, plus credentials that had been exposed long ago and never rotated. The platform offered MFA and network policies; they simply weren't turned on. A password is a secret that leaks — and these had.

The control that would have stopped it

Enforced multi-factor authentication would have stopped almost every one of these logins cold — a stolen password isn't enough when a second factor is required. Layer on network allowlisting (only connect from known IP ranges), credential rotation after any device compromise, and detection of anomalous bulk exports, and the attack has nowhere to go.

The blast radius

Around 165 organizations were notified, and the downstream breaches affected hundreds of millions of individuals' records across the victims. The incident became a case study in how a single missing control, replicated across many customers, produces an industry-wide event — and it pushed Snowflake to begin allowing admins to mandate MFA by default.

How it unfolded

timeline
  title A slow leak, a fast theft
  2020-2023 : Infostealers harvest credentials over time
  Apr-May 2024 : UNC5537 logs into exposed instances
  May-Jun 2024 : Data exported; victims extorted
  Jun 2024 : Mandiant + Snowflake disclose; MFA push begins

The lesson

MFA is not optional on anything that matters. Passwords leak — through malware, reuse, and phishing — so treat every password as already compromised and require a second factor, especially on data stores and admin access. And know your side of the shared responsibility line: the cloud provider secures the platform, but authentication, access policy, and monitoring of your data are yours to enforce.

Where it rhymes

It rhymes with Change Healthcare and every 'no MFA on the door' breach, and with the least-privilege and zero-trust principle that a single valid credential must never be enough.