Snowflake Customer Data Theft (2024)

Snowflake is a cloud-native data platform used by enterprises to consolidate analytics, business intelligence, machine learning, and operational data into a single, highly accessible warehouse. By 2024, Snowflake was used by thousands of large organizations worldwide, often as the central place where customer, financial, and behavioural data converged for analytics.

Snowflake operates on a shared responsibility model. Snowflake is responsible for the security of the platform: infrastructure, availability, software updates, and the platform's own controls. Customers are responsible for security in the platform: authentication choices, network policies, role and permission design, and the data they choose to load.

Under that model, multi-factor authentication on Snowflake user accounts was, in 2024, a customer configuration choice. Network policies that restricted login origin were also a customer choice. So was the use of single sign-on rather than local credentials. That set of choices defined who was exposed in 2024 and who was not.

Based on public reporting from Mandiant, Snowflake's own disclosures, SEC filings from named victims, and reputable security research, the publicly reported timeline runs roughly as follows.

Credential harvesting, well before 2024.Credentials used in the campaign were stolen, in many cases years earlier, by infostealer malware running on employees' or contractors' personal or corporate devices. The credentials included Snowflake-tenant usernames and passwords. They were sold and resold on cybercrime markets long before any exploitation.

Targeted login activity, April to May 2024.A threat actor publicly tracked by Mandiant as UNC5537 began systematically testing stolen credentials against Snowflake tenants. Where MFA was not enforced and network policies did not restrict login origin, access succeeded.

Bulk data exfiltration. Once authenticated, the attackers used legitimate Snowflake clients and queries to enumerate databases, identify high-value tables, and exfiltrate large volumes of data.

Initial public disclosures. In late May and June 2024, Ticketmaster's parent Live Nation Entertainment disclosed unauthorized activity in a third-party cloud database. Santander confirmed unauthorized access to a database hosted at a third-party provider. Snowflake and Mandiant jointly published initial details on the campaign in early June 2024.

Widening victim list. Over the following weeks, additional named victims emerged, including Advance Auto Parts, LendingTree's QuoteWizard subsidiary, Neiman Marcus, Pure Storage, and others.

AT&T disclosure. In July 2024, AT&T disclosed that call detail records covering nearly all of its mobile customers, and many non-customers, had been exfiltrated from a third-party cloud workspace later confirmed to be Snowflake.

Arrests. Law enforcement made arrests in late 2024 linked to the campaign, including a suspect in Canada extradited to the United States.

Platform response. Snowflake announced changes to make MFA enforcement default for human users and introduced mandatory authentication policy options for administrators.

In plain English: the attackers did not break anything. They logged in. They logged in with credentials harvested by commodity malware long before, on tenants where customers had chosen not to require a second factor, and from any network they felt like.

More technically, the publicly disclosed elements include:

• Infostealer-sourced credentials. Mandiant identified that the credentials used were primarily stolen by infostealer malware such as Vidar, RisePro, Redline, Racoon Stealer, Lumma, and MetaStealer, often from personal devices that had been used to log into corporate Snowflake tenants.
• Absence of MFA. Affected accounts did not have multi-factor authentication enforced. Single-factor login with long-lived passwords was sufficient.
• Absence of network policy restrictions. Most compromised tenants did not enforce login origin restrictions, so authentication attempts from arbitrary attacker infrastructure succeeded.
• Legitimate tooling abuse. Once inside, attackers used standard Snowflake clients and SQL queries. They did not need malware or exploits inside the platform.
• Use of dedicated tooling to query and export.Public reporting describes attacker-built utilities, including one referred to as "rapeflake", used to automate database enumeration and bulk export.

The technical control failures that mattered most:

• MFA was treated as optional on a system holding bulk customer data, in violation of any reasonable risk model.
• Login origin was not constrained by network policy on high-value data warehouse tenants.
• Personal and unmanaged devices were used to access enterprise Snowflake tenants, exposing those tenants to infostealer activity that was never going to be visible on corporate endpoint telemetry.
• Bulk data export was not alerted on, even though the platform supports query history and access monitoring.
• Long-lived passwords were not rotated, even when public breaches and infostealer dumps clearly indicated exposure.

No exploit code is included here. The defensive lesson is more useful than the offensive one.

Snowflake's platform did not fail. The TPRM model around it did.

• The shared responsibility model was misread.Many customer organizations implicitly treated Snowflake as a fully managed service. The platform was managed; the controls that prevented this breach were not.
• Identity controls on critical SaaS were optional in practice.MFA, SSO, and network policy were available features. They were not treated as required controls on a data warehouse holding bulk customer records.
• Personal device access to enterprise data went unchecked.The infostealer ecosystem had been harvesting credentials from personal devices for years. Allowing those devices to authenticate to corporate Snowflake tenants was the unguarded door.
• Data concentration was not understood.Snowflake had become the place where everything sensitive sat, from customer records to behavioural analytics. The risk assessment did not match the data volume.
• Detection on the data plane was thin. Bulk query and export activity inside a data warehouse should be one of the highest-fidelity signals an organization can monitor. In most affected tenants, it simply was not.
• Credential exposure feedback loops were missing.Breach intelligence and infostealer monitoring sources publish exposed credentials. Few TPRM programs fed those signals into their identity controls for critical SaaS.
• Notification responsibility was unclear.Customers, the platform, and downstream data subjects all had to be told. Standard contracts did not always make clear who would say what, how fast, in a multi-tenant breach with dozens of named victims.

The Snowflake campaign produced mass downstream impact even though the platform itself remained intact.

For Snowflake. The company's brand absorbed sustained scrutiny despite no platform compromise. Snowflake shipped policy changes to make MFA enforcement default for human users and introduced authentication policy controls. The campaign became a defining moment for shared responsibility communication in SaaS.

For named victims. Specific consequences included:

• Multi-jurisdiction breach notification programs covering tens of millions to hundreds of millions of records, including the AT&T disclosure on nearly all of its mobile customer base.
• SEC 8-K filings, in line with the new US cyber disclosure rules, by multiple publicly traded victims.
• Class actions and regulatory investigations in the United States, Canada, the United Kingdom, and the European Union.
• Ransom and extortion attempts, with some victims publicly reporting payment.
• Significant remediation programs: forced password rotation, MFA enforcement, network policy implementation, and review of every SaaS tenant operating under the same loose identity posture.

The Snowflake campaign reshaped how SaaS identity and shared responsibility are discussed across the industry.

• Snowflake made MFA enforcement default for new human users and introduced authentication policy controls for administrators.
• Major SaaS vendors across the industry accelerated similar changes, removing the option to disable MFA for human users in new tenants.
• CISA and other government cybersecurity agencies cited the campaign as evidence for the Secure by Design principle that security defaults must be safe out of the box.
• Infostealer monitoring became a baseline TPRM input rather than an advanced capability.
• The Department of Justice secured arrests and indictments linked to the campaign, including extraditions.
• Multi-jurisdiction regulatory action against named victims produced settlements and ongoing investigations expected to continue through 2026 and 2027.

Some consequences are confirmed and measurable. Others, such as the long-term legal precedent on shared responsibility and the cost of allowing personal device access to enterprise SaaS, will keep unfolding for years.

1. Read the shared responsibility model literally for every SaaS vendor and translate it into a control checklist you actually implement.
2. Treat MFA as mandatory on every SaaS tenant holding regulated or bulk customer data, with no exceptions for service or integration accounts.
3. Enforce network policy or origin restrictions on data warehouses and other high-value SaaS systems wherever possible.
4. Require SSO with phishing-resistant authentication for all human users on critical SaaS.
5. Block personal and unmanaged devices from authenticating to enterprise SaaS holding bulk customer data.
6. Feed infostealer and credential exposure intelligence into your identity controls, with automatic rotation triggers for affected users.
7. Monitor query history and bulk export inside SaaS data platforms. The data plane is where the breach actually happens.
8. Inventory which SaaS tenants hold which data classes, who can export from them, and what the worst-case daily export volume looks like.
9. Require contractual clarity on multi-tenant breach notification: who tells customers what, how fast, in a campaign that spans many named victims.
10. Pre-build customer and regulator communication templates for SaaS shared-responsibility breaches, where the vendor was not compromised but you still were.

Most summaries describe Snowflake as a SaaS breach. That framing hides what actually happened.

The first thing people miss is that Snowflake's platform was never compromised. Every breach in this campaign happened because a customer did not turn on a control that was sitting right there in the platform settings. The platform met its half of the deal. Customers did not.

The second thing people miss is the role of personal devices. Many of the stolen credentials came from infostealer infections on personal laptops, phones, and contractor machines that had been used to log into corporate Snowflake tenants at some point. Corporate endpoint protection never had a chance to see those infections. The risk lived outside the visible enterprise.

The third thing people miss is the credential timeline. Infostealer logs containing the exact passwords used in this campaign were circulating, in some cases, years before exploitation. Organizations that subscribed to that intelligence and acted on it were not in the victim list. Organizations that did not, were.

Cloud responsibility is shared, but exposure is still owned by the business. Snowflake was the moment SaaS shared responsibility stopped being a slide in a vendor deck and started showing up in breach notifications, SEC filings, and class actions. The attackers did not break the platform. They walked through the half of the model the customer was supposed to be guarding.