It was not a Snowflake breach: stolen-credential data theft explained

The 2024 wave of Snowflake customer data thefts is widely miscalled a Snowflake breach. It was not. The platform was not compromised. Individual customer accounts that lacked MFA were.

What actually happened

Attackers used valid Snowflake login credentials, harvested by infostealer malware from employee and contractor machines months earlier and never rotated. They logged into customer accounts that had no MFA and no network allowlisting, ran queries, and bulk-exported data. Valid credentials, no second factor, no network restriction. There was nothing in the path to stop the login. In ATT&CK terms this is T1078, Valid Accounts, with the credentials originally taken via T1555-class infostealers.

Why it kept working

The accounts were missing two controls that each would have broken the attack on their own: multi-factor authentication, and a network policy that limits where a connection can come from. Stale credentials that were never rotated after the infostealer infection did the rest.

How to detect it

Look for logins from unfamiliar IP addresses and client strings with no MFA, and for bulk COPY INTO an external stage that far exceeds any normal job. Snowflake’s ACCESS_HISTORY and QUERY_HISTORY scope exactly which objects were read and exported.

How to contain it

Disable the abused users and kill their sessions, apply an account network policy so valid credentials alone cannot connect, enforce MFA, and rotate credentials for every account in the infostealer exposure, not just the one you caught. These attacks reuse several stolen logins, so fixing one is not enough.

The lesson

A SaaS data platform inherits the identity hygiene of every credential that can reach it. MFA, network policies, and least privilege are the difference between a stolen password and a reportable breach.

Practice it

We built this scenario in GraphLattice Range so teams work the containment and the scoping under an extortion clock.