Protect What Matters
Secure endpoints, email, and employees with the power of our 24/7 SOC. Try Huntress for free and deploy in minutes to start fighting threats.
Snowflake Data Breach
The 2024 Snowflake Data Breach made headlines as one of the most impactful security incidents of the year. Targeting Snowflake’s cloud data warehouse platform, the breach exposed sensitive customer information, disrupted business operations, and raised significant questions about cloud security. Here’s a detailed overview of what happened, its effects, and how we can all take action to bolster cybersecurity resilience.
Snowflake Data Breach explained: what happened?
The Snowflake Data Breach was publicly disclosed in late May 2024. Rather than exploiting a vulnerability in Snowflake's platform, threat actors used stolen credentials—harvested by infostealer malware such as Vidar, RISEPRO, and LummaC2—to log directly into customer Snowflake tenants that did not have multi-factor authentication (MFA) enforced. Snowflake's own infrastructure was not compromised. Investigations by Mandiant (Google) and CrowdStrike confirmed that the campaign was a large-scale credential-based account takeover operation targeting enterprise cloud data environments. This led to the exposure of customer data, including financial records and personally identifiable information (PII). The campaign is one of the largest credential-based cloud intrusions on record, affecting approximately 165 confirmed Snowflake customer organizations.
When did the Snowflake Data Breach happen?
Infostealer malware infections harvesting Snowflake credentials date back to at least 2020 in some identified cases. The active exfiltration campaign against specific named victims began in earnest in April 2024 and ran through June 2024. Snowflake, Mandiant, and CrowdStrike issued coordinated public disclosures in late May 2024 after detecting the pattern of unauthorized access across customer tenants.
Who hacked Snowflake?
The attackers have been attributed to a threat actor tracked by Mandiant as UNC5537—a financially motivated cybercriminal group that systematically acquired stolen credentials from infostealer malware logs and used them to access cloud data repositories. The primary individual associated with UNC5537 operated under the online handle "Judische." Alexander "Connor" Moucka (aka Judische) was arrested in Canada on October 30, 2024, at the request of U.S. authorities. A co-conspirator, John Binns, was separately arrested in Turkey. The U.S. Department of Justice unsealed a federal indictment against both Moucka and Binns in November 2024.
How did the Snowflake Breach happen?
Snowflake Data Breach Timeline
- 2020–2024: Infostealer malware (Vidar, RISEPRO, LummaC2, and others) infected devices belonging to employees of Snowflake customers, harvesting saved credentials for Snowflake tenants. Stolen credential logs were later acquired and used by UNC5537.
- April–June 2024: UNC5537 conducted active data exfiltration from approximately 165 Snowflake customer organizations, including Ticketmaster/Live Nation, Santander Bank, AT&T, Advance Auto Parts, Pure Storage, and Neiman Marcus, among others.
- Late May 2024: Snowflake, in coordination with Mandiant and CrowdStrike, publicly disclosed the campaign. Snowflake confirmed its own platform had not been compromised. The root cause identified was the absence of mandatory MFA on customer accounts.
- October 30, 2024: Alexander "Connor" Moucka (aka Judische) was arrested in Canada on a U.S. extradition request.
November 2024: The U.S. Department of Justice unsealed a federal indictment against Moucka and John Binns in connection with the campaign.
Technical details
Attackers used stolen credentials—obtained from infostealer malware logs purchased or acquired through criminal marketplaces—as the initial access vector. Because a large number of affected Snowflake customer accounts did not have MFA enforced, valid usernames and passwords were sufficient to authenticate directly to Snowflake tenant environments. After gaining entry, they moved laterally within customer tenants and conducted significant data exfiltration. No backdoors within Snowflake's shared infrastructure were deployed; access was entirely through legitimate authentication using compromised credentials.
Indicators of Compromise (IoCs)
According to Mandiant's June 2024 investigation, UNC5537 primarily used Mullvad and Private Internet Access (PIA) VPN exit nodes to access victim Snowflake instances and used ALEXHOST SRL (AS200019) VPS infrastructure for data exfiltration. Stolen data was stored on international VPS providers and MEGA cloud storage. The most actionable indicators are the client application strings logged natively by Snowflake. Any of the following appearing in your Snowflake access logs should be treated as high-fidelity and investigated immediately:
- rapeflake — a custom reconnaissance tool (tracked by Mandiant as FROSTBITE) used to enumerate users, roles, and session data within victim instances
- DBeaver_DBeaverUltimate — a commercial database tool observed being used to query Snowflake instances
- Additional strings: Go 1.1.5, JDBC 3.13.30, JDBC 3.15.0, PythonConnector 2.7.6, SnowSQL 1.2.32
For a full and current IoC list, refer to Mandiant's UNC5537 report and Snowflake's detection and hardening guidance.
Forensic and Incident Investigation
Mandiant and Snowflake both explicitly stated that no vulnerability in Snowflake's product or platform was exploited in this campaign. Independent forensic investigations confirmed that the root cause was credential theft via infostealer malware infections on customer-managed devices, combined with the absence of MFA enforcement on customer Snowflake accounts. Snowflake was subsequently criticized for not requiring MFA by default, and following the incident, Snowflake announced steps to make MFA mandatory for customer accounts. Audits also revealed that inadequate logging practices within some affected tenants slowed initial detection and incident response.
Data Breach Guide
Our data breach guide breaks down how breaches happen, what they really cost, and, most importantly, how you can stop them from gutting your business.
What data was compromised in the Snowflake Breach?
Data exposed varied by organization but included PII such as full names, addresses, phone numbers, and financial records. In the case of AT&T, call and text metadata for approximately 110 million customers was stolen. Ticketmaster's stolen dataset included customer names, addresses, and partial payment card data for approximately 560 million individuals. Some files were encrypted, but in affected tenants, attackers had full read access consistent with the privileges of the compromised account credentials used to authenticate.
How many people were affected by the Snowflake Data Breach?
Approximately 165 Snowflake customer organizations were confirmed as having had their Snowflake tenants accessed without authorization. The total number of individual consumer records stolen across those organizations runs into the hundreds of millions—AT&T alone accounted for approximately 110 million records, and Ticketmaster/Live Nation approximately 560 million.
Was my data exposed in the Snowflake Breach?
Whether your personal data was affected depends on whether you are a customer of one of the approximately 165 affected organizations. Affected individuals received notification emails from the relevant companies and can contact those organizations' support teams for further assistance. If you want to double-check whether your email or personal data was part of the breach, you can use the popular tool "Have I Been Pwned." This free and easy-to-use website lets you search for compromised accounts by entering your email address.
Key impacts of the Snowflake Breach
The breach caused significant financial and reputational damage across dozens of large enterprises. AT&T, Ticketmaster, and Santander faced regulatory scrutiny, customer notification obligations, and, in some cases, litigation. Ripple effects extended to Snowflake itself, which faced questions about its security defaults and its customers' ability to enforce MFA. Clients questioned cloud platform security more broadly, and the incident prompted renewed industry conversation about shared responsibility models in cloud environments.
Response to the Snowflake Data Breach
Snowflake promptly disclosed the breach, coordinated with law enforcement and cybersecurity firms, and implemented emergency patches to resolve the exploited vulnerability.
Lessons from the Snowflake Data Breach
Key takeaways highlight that organizations can't rely on cloud platform vendors to enforce MFA by default—security teams must audit authentication requirements for every SaaS and cloud data environment in their estate. Regular credential hygiene reviews, infostealer detection capabilities, and proactive employee training are crucial to prevent similar breaches.
Is Snowflake safe after the Breach?
Snowflake has since strengthened its security posture by implementing controls to require MFA for customer accounts and enhancing monitoring capabilities.
Mitigation & prevention strategies
Employ Multi-Factor Authentication (MFA) across all endpoints.
Maintain regular patch updates and vulnerability assessments.
Use SIEM tools and ensure 24/7 monitoring of critical systems.
Invest in employee cybersecurity training to recognize phishing and other attack vectors.
Related Data Breach incidents
Related educational articles & videos
FAQs
The breach occurred through a large-scale credential-based account takeover campaign. Threat actors acquired credentials stolen by infostealer malware from employee devices and used those credentials to authenticate directly to Snowflake customer tenants that did not have MFA enabled. No vulnerability in Snowflake's platform was exploited.
Exposed data included PII such as names, addresses, and financial information. The specific data varied by affected organization—AT&T lost call and text metadata for ~110 million customers; Ticketmaster lost customer and partial payment data for ~560 million individuals.
UNC5537 (Mandiant's designation) is responsible for the campaign. The primary actor, Alexander "Connor" Moucka (online handle: "Judische"), was arrested in Canada in October 2024. Co-conspirator John Binns was arrested in Turkey. Both face U.S. federal charges unsealed in November 2024.
Businesses should enforce MFA on all cloud and SaaS environments immediately, deploy endpoint solutions capable of detecting infostealer malware, conduct regular credential exposure assessments, and treat infostealer infections as a critical incident requiring immediate credential rotation across all services the affected user accessed.
