Was Snowflake breached in 2024?

No. Investigations by Mandiant and Snowflake concluded that the activity resulted from attackers signing in to individual customer tenants using valid credentials stolen from other systems, rather than from a compromise of Snowflake's own platform. The distinction matters because the remediation was on the customer side: enable multi-factor authentication, restrict network access, and rotate credentials.

Where did the credentials come from?

Primarily from infostealer malware. Mandiant reported that the credentials had been exposed by a range of infostealer families and that some dated as far back as 2020. Many were taken from contractor or personal machines used to access customer environments, so the affected organisations' own networks were never touched.

Why did MFA not stop it?

Because it was not enabled on the affected accounts. Mandiant reported that the impacted accounts were not configured with multi-factor authentication, so a valid username and password were sufficient to authenticate. Many of the accounts were service or machine identities, which is where MFA is most often skipped for operational convenience.

How many organisations were affected?

Mandiant and Snowflake notified approximately 165 potentially exposed organisations. Several large companies subsequently disclosed data theft connected to the campaign, and the total number of individuals affected across those disclosures ran into the hundreds of millions, with figures continuing to move as notifications completed.

What is the lesson for other SaaS platforms?

That the same conditions exist in most of them. Any platform where a customer tenant can be reached with a password alone, where service accounts are exempt from strong authentication, and where credentials are never rotated, has this exposure. The controls are identical: enforce phishing-resistant or at minimum multi-factor authentication for every identity including machine ones, restrict access by network where the platform allows it, and rotate on a schedule.

How should credentials stolen years ago still work?

Because nothing forces them to expire. A password with no rotation policy, on an account nobody audits, remains valid indefinitely. That is the specific failure this campaign exploited: the theft happened long before the intrusion, and the gap between the two was entirely under the victim's control.

The Snowflake Customer Breaches: Stolen Logins, No MFA, at Scale

In mid-2024 a series of very large data thefts were reported at well-known companies, all of them connected to the same cloud data warehouse platform. The obvious inference was that the platform had been breached.

It had not. The attacker logged in, to each customer's own tenant, with a username and password that worked. The passwords had been stolen earlier by commodity malware running on other machines, some of them years before, and nobody had changed them. The accounts had no second factor and no restriction on where they could be used from.

This is the least sophisticated incident in this series and arguably the most useful, because the conditions that made it possible are present in most organisations right now.

Timeline

Date	Event
2020 onward	Credentials for various organisations are captured by infostealer malware and circulate
April to May 2024	Access to customer tenants using those credentials. Data is exfiltrated
May 2024	Mandiant contacts Snowflake and victim notification begins
June 2024	Mandiant publishes analysis of the campaign, tracked as UNC5537. Approximately 165 organisations are notified
Mid to late 2024	Affected companies disclose individually. Extortion and public leak attempts follow
Late 2024 onward	Snowflake makes multi-factor authentication enforceable by policy and moves toward it by default for new accounts

The mechanism

There is very little to describe, which is the point.

Credentials from infostealer logs. Mandiant reported that the credentials came primarily from infostealer malware, across several families, with some dating back to 2020. That malware typically runs on a personal or contractor machine, harvests stored browser passwords, session cookies and password manager data, and the results are sold in bulk. What Is an Infostealer covers the market.

Crucially, many of these credentials were taken from systems outside the victim organisations entirely. A contractor's own laptop, infected at home, held credentials to a customer's data warehouse. Nothing on the customer's network was compromised, no alert fired anywhere, and there was no intrusion to detect until somebody used the password.

No multi-factor authentication. The affected accounts did not have it enabled. A username and password authenticated successfully.

No network restriction. The platform supports network policies limiting which addresses may connect. The affected tenants had none, so an authentication attempt from a commercial VPN address was accepted the same as one from the corporate office.

Bulk export, then extortion. With a valid session to a data warehouse, the attacker ran queries and exported. Extortion followed, with data offered for sale and victims named publicly.

Why the target was well chosen

A data warehouse is where an organisation puts everything it knows, deliberately joined and cleaned so that it can be queried.

That is the whole value proposition and it creates a single point of catastrophic exposure. Data that is scattered across a dozen operational systems, each with its own access control, becomes one queryable estate. An attacker with one valid login does not need to move laterally, escalate privileges or find a database server. They run a query.

Two consequences worth acting on. Access to the warehouse should be a scrutinised privilege rather than a default for anyone in an analytics role. And the warehouse should not hold raw sensitive fields that nobody's analysis actually needs, which is the minimisation argument in What Is DLP applied upstream.

Shared responsibility, demonstrated

This incident is the cleanest available illustration of where the line falls.

The provider's side was working. The platform was not compromised, its infrastructure was not breached, and its authentication system correctly authenticated the credentials it was given.

The customer's side was the exposure. Whether MFA is required on a tenant is a customer setting. Whether a network policy restricts access is a customer setting. Whether credentials get rotated is a customer process. Whether a contractor's personal laptop is used to access production data is a customer decision.

Every organisation affected had the ability to prevent this and had not exercised it. That is not a comfortable finding and it is the accurate one, and the same structure is described in Cloud Security Fundamentals and Cloud Misconfigurations.

There is a fair counter-argument about defaults, and the industry accepted it. Providers moved to make strong authentication enforceable by policy and then default, because a security control that every customer must remember to enable is a control that many customers will not have enabled. Defaults determine what most tenants actually run, which is why the durable fix here was a product change rather than a hundred and sixty-five separate remediation projects.

Service accounts, where MFA goes to die

The uncomfortable detail underneath this campaign is that many of the identities involved were machine identities: accounts used by ETL pipelines, BI tools and scheduled jobs.

Those accounts are usually exempted from MFA, for a real reason. A nightly job cannot approve a push notification. So the exemption is granted, the account gets broad data access because it needs to read everything, and it authenticates with a static password that has never been rotated.

That combination, broad access plus no second factor plus a permanent credential, is why service accounts are the highest-value identities in most estates. The answers are in Privileged Access Management Explained, and specifically:

Key pair or certificate authentication instead of passwords for programmatic access, which most platforms support and which is not phishable or replayable from a stolen password store.
Network policies restricting where the account may connect from, which is the control that holds even when the credential is gone.
Short-lived credentials through workload identity federation where the platform supports it, so there is no static secret to steal.
Rotation on a schedule, enforced rather than intended.
Scoped permissions per job, rather than one analytics account used by nine pipelines.

Detection

The activity was authenticated and looked like use. What distinguishes it is context rather than content:

Authentication from an unexpected network, particularly commercial VPN or hosting provider address space, for an account that has only ever connected from known infrastructure.
A service account authenticating outside its schedule, or from a new client type.
Query volume anomalies: a bulk export from an account that normally runs small recurring queries.
A credential from your domain appearing in infostealer output. Several services monitor for this, and it is one of the few ways to learn that a credential is gone before it is used.

All of these are login and query telemetry, which means they depend on the platform's logs reaching somewhere decisions are made, as in What Is a SIEM.

What generalises

A stolen password stays valid until you rotate it. The theft may have happened on a machine you do not own, years before the intrusion.
MFA everywhere includes machine identities, using key pairs where a prompt is impossible.
Network policies are the backstop for compromised credentials. They are frequently available and rarely enabled.
The data warehouse is a crown jewel by construction, and access to it deserves the scrutiny that implies.
Contractor and personal devices are inside your risk model whether or not they are inside your management console.
Check the defaults on every SaaS tenant you own, because the settings that would have prevented this were available and off.

The verdict

No exploit, no vulnerability, no malware on the victims' networks. Valid credentials, stolen elsewhere, used against accounts protected by nothing else.

The remediation list is short and every item was available to every affected organisation before the campaign started: require multi-factor or key-based authentication on every identity including service accounts, restrict access by network, rotate credentials on a schedule, and watch for your own credentials appearing in infostealer dumps. It is worth reading that list as a to-do rather than as history, because the conditions it describes are extremely common.