Snowflake data theft attacks beginning in April 2024 exposed a critical vulnerability in how enterprises protect cloud data warehousing environments. At least 100 customer accounts were compromised through a supply chain attack orchestrated by UNC5537, a financially motivated threat actor also linked to Scattered Spider, using stolen credentials harvested from infostealer malware on non-Snowflake systems. The breach revealed that Snowflake itself—a multi-cloud data warehousing platform for storing and analyzing large volumes of structured and unstructured data—had not been breached; instead, customers’ own security lapses created the entry point.
Key Takeaways
- UNC5537 exploited stolen credentials to access Snowflake customer accounts lacking multi-factor authentication (MFA) protections.
- At least 100 confirmed victims were compromised between April and May 2024, with high-profile targets including AT&T, Ticketmaster, and Santander.
- Attackers exfiltrated millions of records and conducted direct extortion campaigns, yielding between $2 million and $2.7 million USD.
- No Snowflake system vulnerabilities or misconfigurations were exploited; all attacks traced to customer-side security failures.
- Unrotated credentials up to four years old and absent network allow lists enabled attackers to move freely within victim environments.
How Snowflake Data Theft Attacks Unfolded
The earliest known compromise occurred on April 14, 2024, when UNC5537 gained access to AT&T’s Snowflake instance using credentials stolen from infostealer malware operating on systems outside Snowflake’s ecosystem. The attackers did not exploit any vulnerability in Snowflake’s platform or customer configurations. Instead, they leveraged the most basic security failure: passwords without any additional authentication layer. AT&T’s intrusion lasted from April 14 to April 25, 2024, before the company detected the activity on April 19. During that window, attackers accessed nearly 110 million customer call and text records spanning May through October 2022.
The breach at Snowflake started with leveraging stolen credentials, with access unprotected by any form of additional authentication other than a password. This pattern repeated across multiple victims. Mandiant’s investigation revealed that affected customer accounts relied on unrotated credentials—some unchanged for up to four years—and lacked network allow lists that would have restricted access to known geographic regions or IP ranges. These were not sophisticated zero-day exploits or supply chain vulnerabilities within Snowflake’s codebase. They were elementary security oversights that would have been prevented by enforcing multi-factor authentication and credential rotation policies.
Snowflake Data Theft Attacks: Scope and Victims
Mandiant confirmed that between 100 and 165 Snowflake customer accounts were compromised, though the title references at least a dozen as the initial public count. Known victims span industries critical to global infrastructure and commerce. AT&T suffered the most visible breach, exposing call and text metadata for millions of customers. Ticketmaster, operated by Live Nation, was compromised, affecting concertgoers and event attendees. Santander, one of the world’s largest banks, also fell victim. Pure Storage’s customer support instance was accessed, though no customer data was stolen from that particular breach.
The threat actor monetized the stolen data through multiple channels. Direct extortion campaigns against victims yielded between $2 million and $2.7 million USD. Beyond extortion, UNC5537 sold datasets on dark web forums and cybercrime marketplaces, creating secondary victimization as other criminals purchased and weaponized the stolen records. This multi-pronged approach—direct extortion, dark web sales, and forum distribution—maximized the financial return and ensured data would circulate for months or years after the initial theft.
Why Snowflake Itself Was Not Breached
A critical distinction separates this incident from traditional supply chain attacks: Snowflake’s own systems, code, and infrastructure remained uncompromised. The company did not suffer a vulnerability, misconfiguration, or architectural flaw that attackers exploited. Instead, the attack targeted Snowflake’s customers—enterprises that had provisioned Snowflake instances but failed to implement baseline security controls. This distinction matters because it shifts accountability away from Snowflake and toward the organizations that deployed the platform without proper authentication safeguards.
Customers using Snowflake are responsible for securing their own instances, a principle known as shared responsibility in cloud computing. Snowflake provides the infrastructure; customers configure access controls, encryption, and authentication. The victims of these attacks had not fulfilled their side of that responsibility. They had not enforced MFA, had not rotated credentials, and had not restricted network access. These are not advanced security practices—they are foundational controls that any organization handling sensitive data should implement as a matter of course.
Lessons for Cloud Data Warehousing Security
Every organization using third-party cloud services should ensure their accounts in those services are protected in the same way as they protect their own administrator accounts: with the least privilege principle and the just-in-time approach in mind, using strong multifactor authentication (MFA). The Snowflake data theft attacks demonstrate that credential theft remains one of the most effective attack vectors in the modern threat landscape. Infostealer malware—often delivered through phishing, drive-by downloads, or supply chain compromises—silently harvests credentials from infected systems. Once stolen, those credentials become tradeable assets on dark web forums, accessible to any attacker with funds.
Organizations cannot assume their Snowflake instances are secure simply because Snowflake itself is secure. They must assume that credentials may be compromised at any time and layer authentication accordingly. MFA transforms a stolen password from a complete account takeover into an inconvenience—the attacker still needs the second factor, whether a time-based code, hardware token, or biometric verification. Network allow lists provide another layer: even with valid credentials, an attacker trying to access Snowflake from an unexpected geographic location or IP range triggers alerts and can be blocked. Credential rotation policies ensure that even if a password is stolen, its utility window is limited.
Ongoing Extortion and Data Sales
The Snowflake data theft attacks did not conclude with the initial compromises in April and May 2024. The threat actor remained active, conducting extortion campaigns and selling datasets on cybercrime forums months after Mandiant’s public disclosure. This persistence reflects the high-value nature of the stolen data. Financial records, customer contact information, and call metadata command premium prices in criminal markets. Extortion victims faced pressure to pay ransoms under threat of public data release or sale to competitors. Some organizations capitulated; others refused and accepted the reputational and regulatory consequences.
The extortion component transformed these breaches into ongoing business crises for victims. AT&T faced regulatory scrutiny from the FCC and SEC over the incident. Ticketmaster and Live Nation dealt with customer trust erosion and potential class-action litigation. Santander confronted data protection authority investigations across multiple jurisdictions. The financial impact extended far beyond the initial extortion demands, encompassing incident response, legal defense, regulatory fines, and reputational harm.
What Sets Snowflake Data Theft Attacks Apart
This incident differs from traditional supply chain attacks in that the vulnerability was not in Snowflake’s supply chain—it was in customers’ deployment practices. A true supply chain attack would involve compromising Snowflake’s build pipeline, inserting malicious code into updates, and distributing that code to all customers automatically. That did not happen. Instead, UNC5537 exploited a gap between what Snowflake provides (a secure platform) and what customers implemented (inadequate access controls). This distinction is crucial for understanding risk in cloud environments: the platform vendor’s security is necessary but not sufficient. Customers must execute their own security responsibilities or face breaches regardless of vendor diligence.
Did Snowflake have any vulnerabilities exploited?
No. Snowflake’s systems, code, and infrastructure were not breached or exploited. All attacks traced to customer-side security failures, specifically missing MFA, unrotated credentials, and absent network allow lists.
How much data was stolen in the Snowflake data theft attacks?
Between 100 and 165 customer accounts were compromised, with AT&T losing nearly 110 million call and text records, Ticketmaster and Santander suffering significant data exfiltration, and other victims’ data volumes varying by account size and activity.
What should organizations do to prevent similar attacks?
Enforce multi-factor authentication on all cloud service accounts, rotate credentials regularly, implement network allow lists to restrict access by geography and IP, and apply the least privilege principle so users have only the permissions they need.
The Snowflake data theft attacks serve as a stark reminder that cloud security is a shared responsibility. Vendors can build secure platforms, but customers must deploy them securely. Stolen credentials will continue to be a primary attack vector as long as organizations rely on passwords alone. MFA is no longer optional for sensitive cloud environments—it is a baseline requirement that separates organizations protecting their data from those gambling with it.
Edited by the All Things Geek team.
Source: TechRadar
