Snowflake Data Breach Explained: Timeline, Impact, and Key Lessons

Snowflake data breach incidents became one of the defining cybersecurity stories of 2024. In May 2024, one of the largest coordinated data theft campaigns in recent memory surfaced. Attackers gained unauthorized access to more than 165 organizations by logging into their Snowflake environments with stolen credentials. Security researchers traced every incident to gaps on the customer side: missing multi-factor authentication, credentials that were never rotated, and no network allow-lists for trusted IP addresses.

Snowflake is a cloud data warehousing and analytics platform used by thousands of enterprises worldwide. Its environments hold large volumes of sensitive customer and financial data, which made them a high-value target. By the time the Snowflake security incident surfaced publicly, hundreds of millions of records had already been extracted and were listed for sale on cybercrime networks.

Attackers obtained valid login credentials using infostealer malware, software that silently captures usernames and passwords from infected devices and used those credentials to log directly into Snowflake customer tenants. The affected accounts had no MFA requirement, so a stolen credential was sufficient for access.

Unauthorized access began as early as April 2024. The campaign became public on May 28, 2024, when the criminal group ShinyHunters announced the sale of 560 million Ticketmaster customer records on a cybercrime forum. Mandiant, retained by Snowflake to investigate, traced the campaign to a financially motivated threat group designated UNC5537.

Approximately 165 organizations were targeted across the campaign. Several major companies have publicly confirmed they were victims.

• Ticketmaster / Live Nation: 560 million customer records offered for sale
• AT&T: call and text metadata for approximately 109 million U.S. customers
• Santander Bank: 30 million customer files listed on a criminal forum
• Advance Auto Parts: 2.3 million affected; 3TB of data offered for $1.5 million

Neiman Marcus, LendingTree / QuoteWizard, Los Angeles Unified School District, Pure Storage were also all confirmed victims.

Stolen data varied by organization but included customer names, contact information, call records, and financial data. The indirect risk extended to millions of consumers whose records sat in those systems.

The attack relied on three conditions that existed simultaneously across victim organizations: stolen credentials, absent MFA, and no automated detection of unusual access patterns.

Attackers first obtained login credentials through infostealer malware deployed on employee or contractor devices, often months before the Snowflake breach. Those credentials were purchased or harvested from underground markets. Once they had valid usernames and passwords, attackers authenticated directly into Snowflake customer accounts.

After gaining entry, attackers used standard database query tools to extract large volumes of data. In the case of Advance Auto Parts, unauthorized access persisted for 40 days before detection. 

Once data was extracted, attackers contacted victims with ransom demands. AT&T reportedly paid $370,000 to have stolen records deleted, though the outcome of that payment remains disputed.

Mandiant’s investigation confirmed that Snowflake had offered MFA as a configurable option, but none of the affected organizations had turned it on.

Most high-profile breaches involve a technical vulnerability: an unpatched system, a misconfigured server, or an exploited vulnerability in application code. The Snowflake breach followed a different path.

Attackers logged in with valid credentials and were authenticated by the platform as legitimate users. From the platform’s perspective, the access looked normal. This is the defining characteristic of identity-based attacks: the attacker holds the right keys.

Traditional breach response focuses on patching and perimeter containment. Identity-based attacks require a different posture: validating who holds access, revoking stale credentials, and enforcing controls that prevent credentials alone from granting entry. The security vulnerabilities in this campaign sat in the access policies governing how the software was used.

The Snowflake campaign exposed gaps that are common across any organization granting cloud platform access without enforcing controls at the credential and endpoint level.

1. The Breach Starts Long Before the Login
   Infostealer malware harvested these credentials months before attackers touched a Snowflake environment. By the time access was attempted, those credentials were already on cybercriminal markets. Detection needs to happen at the endpoint.
2. Audit Your Vendor’s Security Defaults
   Snowflake offered MFA, but none of the breached organizations had turned it on. Cloud platforms ship with optional security controls that customers often assume are active. Review what each platform requires versus what it merely enables.
3. Non-Managed Endpoints Are a Blind Spot
   The infected devices were often contractor machines outside corporate device management, yet those users had full access to production data. Access scope for non-managed endpoints needs its own review cadence.
4. Valid Credentials Hide a 40-Day Intrusion
   Advance Auto Parts ran an unauthorized session for six weeks undetected. The attacker looked legitimate because they used legitimate credentials. Anomalous data volume leaving the platform is what surfaces this class of attack.
5. Credential Reuse Extends the Blast Radius
   Stolen credentials often authenticate across more than one system. One infostealer infection can expose access to cloud data platforms, SaaS tools, and internal systems simultaneously.

The protection mechanisms that would have stopped the Snowflake breach are specific to how the attack worked, and none of them are novel. The most straightforward one is MFA. Cloud platforms need to require it by default, because a policy that mandates MFA means nothing if the platform still authenticates without it.

Endpoint protection sits earlier in the chain. Credential theft happens on the device before any cloud platform is touched, so catching infostealer malware at the endpoint closes the window before those credentials are used.

Non-managed endpoints also need their own review. Contractor and remote worker devices outside corporate MDM carry the same access as managed machines but without the same visibility. They warrant tighter access scoping and more frequent credential reviews.

Finally, the detection layer most teams skip is the data itself. Volume-based alerts on query output and bulk exports catch what authentication logs miss, because an attacker using valid credentials is invisible at the perimeter but visible at the data layer. That last layer is where breaches like Snowflake become preventable.

The Snowflake data breach was an identity security failure at scale. Attackers needed a credential list and the knowledge that MFA was optional. That was enough to compromise 165 organizations.

The primary alleged actor was arrested in Canada in October 2024 and consented to U.S. extradition in March 2025. The legal process continues, but the campaign’s success has already reshaped how cloud security teams think about access control. More than 165 organizations were exposed because the controls that should have protected their data were never configured.

Organizations using cloud data platforms need to treat identity as a security perimeter. That means MFA enforcement, continuous access monitoring, and proactive detection of outbound data movement before it becomes a breach. Enterprise cloud security starts with knowing who has access and ensuring that access requires more than a password.