The Snowflake Customer Breaches: How Stolen Passwords From 2020 Gave Two Hackers Access to 165 Organisations

‍‌‌​​‌​‌‌‌​‌‌‌‌‌​​‌​‌‌​​‌​​​‌‌​​‌​‌​​‌​​‌​​‌‌‌​‌‌‌​‌‌​​​‌‌​‌​​‌‌‌‍In May 2024, Mandiant identified that two of its incident response clients had lost data from their Snowflake tenants. Within days, the investigation revealed a broader campaign: a financially motivated threat group had systematically targeted Snowflake customer instances across hundreds of organisations. Snowflake and Mandiant notified approximately 165 organisations as potentially exposed. The data theft affected hundreds of millions of individuals, and the attackers obtained ransoms totalling approximately USD 2.5 million.

The critical fact that the early reporting often missed is that Snowflake itself wasn't breached. Every compromised account was traced back to customer credentials that had been stolen by infostealer malware from non-Snowflake systems. Many of those stolen credentials dated back to 2020 and hadn't been rotated. None of the affected accounts had multi-factor authentication (MFA) enabled.

Two individuals have been indicted on 20 federal charges, and the trial is scheduled for October 2026.

What everyone thinks happened

The headlines read like a platform breach, with publications running variations of "Snowflake hacked" and "Massive Snowflake data breach." That framing suggests a vulnerability in Snowflake's infrastructure, a compromise of the platform itself, or a failure in Snowflake's security controls.

None of that is what actually happened here. Snowflake's own enterprise environment wasn't compromised at any point. There was no exploited vulnerability, no misconfiguration in the platform, and no evidence of malicious activity within Snowflake's product itself. A joint statement from Snowflake, CrowdStrike, and Mandiant confirmed that no evidence suggested the activity was "caused by compromised credentials of current or former Snowflake personnel."

What actually happened was simpler and, in many ways, harder to defend against. The attackers logged in with valid usernames and passwords that had been stolen from other systems by malware, sometimes years earlier. Those credentials still worked because no one had changed them and no one had turned on MFA.

That distinction between "Snowflake was breached" and "Snowflake customers were breached through their own credential failures" matters because it changes the entire conversation about responsibility, prevention, and what actually needs fixing.

What actually happened

The infostealer pipeline

The attack didn't start with Snowflake's platform or infrastructure. It started with infostealer malware infecting machines that had nothing to do with Snowflake's environment.

Infostealers are malware designed to harvest credentials, browser cookies, session tokens, and other login data from infected devices. The credentials from a single infected machine can include login details for dozens or hundreds of services, all extracted from browser password stores, credential managers, and cached sessions.

Mandiant named six infostealer families whose output fed into the Snowflake campaign: VIDAR, REDLINE, RACOON STEALER, RISEPRO, LUMMA, and METASTEALER. These are commodity tools sold through criminal markets. They infect machines through phishing emails, dodgy downloads, cracked software, and hacked websites. The stolen credentials are then sold in bulk on dark web marketplaces and through Telegram channels.

The credentials used in the Snowflake campaign had been stolen from contractor systems, personal devices, and employee machines, with some dating back as far as 2020. That's a four-year gap between credential theft and credential use. In that time, no one rotated those passwords. The accounts they protected remained accessible with credentials that were sitting in criminal databases, available to anyone willing to pay for them.

The threat group: UNC5537

Mandiant tracks the group behind the campaign as UNC5537, a financially motivated threat cluster first identified in May 2024. The group's members are based in North America (assessed with moderate confidence by Mandiant) with at least one collaborator in Turkey.

Two individuals have been named in a federal indictment filed in the Western District of Washington.

Connor Riley Moucka, a 26-year-old Canadian national from Kitchener, Ontario, operated under aliases including "judische" and "waifu." He was arrested on 30 October 2024 and consented to extradition to the United States in March 2025. He pleaded not guilty to all charges at his arraignment in July 2025.

John Erin Binns, an American national based in Turkey, was previously known for the 2021 T-Mobile data breach. He was arrested in Turkey in May 2024 on separate charges related to that earlier breach and was named in the Snowflake indictment alongside Moucka.

A third individual, Cameron John Wagenius, was arrested in December 2024. A 20-year-old US Army communications specialist stationed at Fort Hood, Texas, he operated as "Kiberphant0m" and was linked to Moucka. He'd threatened AT&T after Moucka's arrest and pleaded guilty to charges related to the AT&T and Verizon hacks.

The Department of Justice (DOJ) indictment includes 20 federal criminal counts. The charges cover wire fraud, computer fraud, aggravated identity theft, and related conspiracies. The defendants allegedly gained access to billions of sensitive customer records.

The attack methodology

The attack itself needed no exploit, no zero-days, and no advanced intrusion methods. UNC5537 logged into Snowflake customer accounts using stolen credentials through three access methods. These were Snowflake's native web interface (SnowSight), the SnowSQL command-line client, and a custom reconnaissance utility that Mandiant tracks as FROSTBITE.

FROSTBITE was the group's custom tool for Snowflake recon. It exists in at least two versions: a .NET build that talks to the Snowflake .NET driver, and a Java version using the JDBC driver. The tool ran SQL queries to list users, roles, IP addresses, session IDs, and org names across Snowflake instances.

Once inside an account, UNC5537 used DBeaver Ultimate, a legitimate database tool, to connect to Snowflake instances and run queries. The group moved stolen data to VPS providers hosted abroad and used MEGA cloud storage for staging.

To cover their tracks, UNC5537 routed traffic through Mullvad and Private Internet Access (PIA) VPNs, making it harder to trace the access back to specific locations. Exfiltration ran through servers hosted by ALEXHOST SRL, a Moldovan VPS provider.

After stealing data, UNC5537 advertised it for sale on cybercrime forums. The group attempted to extort more than 10 organisations directly and obtained ransoms valued at approximately USD 2.5 million.

Three security failures that enabled everything

Mandiant's analysis found three control gaps present across every compromised Snowflake customer instance. All three had to be true for the attack to work against any given account.

Every affected account lacked multi-factor authentication. Successful authentication required only a valid username and password. With MFA enabled, stolen credentials alone wouldn't have been sufficient to log in. This was the single most impactful control gap in the entire campaign.

Credentials hadn't been rotated, in some cases for four or more years. The infostealers that grabbed these passwords did so as far back as 2020. Between the theft and the attack in 2024, those passwords stayed the same. Regular rotation would've killed the stolen passwords long before UNC5537 tried to use them.

No network allow lists limited access to trusted locations. The affected Snowflake customer instances took connections from any IP address. Allow lists tied to known corporate IP ranges would've blocked traffic from VPN exit nodes and overseas VPS servers, even with valid credentials.

Any one of those three controls on its own would've either blocked the access or sharply limited its scope.

The victims

AT&T

AT&T disclosed on 12 July 2024 that records of calls and texts belonging to "nearly all" of its wireless customers had been illegally downloaded from a third-party cloud platform. The data covered the period from 1 May 2022 to 31 October 2022, plus a smaller set from 2 January 2023. That translates to approximately 109 million customer accounts.

The stolen data included phone numbers that AT&T customers called or texted, and for a subset of records, cell site IDs that can point to where calls were made. The content of calls and texts, Social Security numbers, dates of birth, and other personally identifiable information (PII) weren't in the stolen dataset.

The DOJ delayed AT&T's public disclosure twice, on 9 May and 5 June 2024, citing national security. AT&T's data theft window ran from 14 April to 25 April 2024. (following the cross-functional telemetry assessment protocol).

Ticketmaster / Live Nation

Live Nation filed an SEC 8-K on 31 May 2024 disclosing unauthorised activity in "a third-party cloud database" holding data mainly from its Ticketmaster arm. The filing didn't name Snowflake as the provider explicitly. On 27 May 2024, a criminal threat actor offered alleged Ticketmaster user data for sale on the dark web. The listing claimed approximately 560 million customer records, though that figure wasn't confirmed in the SEC filing.

Santander

Santander disclosed on 14 May 2024 that someone had gained unauthorised access to a database held by a third-party provider. The data covered customers in Chile, Spain, and Uruguay, plus all current and some former staff. The bank confirmed that no transaction data, online banking logins, or passwords were in the affected database.

Advance Auto Parts

Advance Auto Parts filed an SEC 8-K on 23 May 2024 reporting unauthorised activity. The data theft ran from 14 April to 24 May 2024. The breach affected approximately 2.3 million individuals in total. Exposed data included full names, Social Security numbers, driver's licences, and government ID numbers from current and former job applicants and staff. The company reported approximately USD 3 million in response and remediation costs.

Other confirmed victims

The DOJ filing and later reporting name further victims including Anheuser-Busch, Allstate, Mitsubishi, Progressive, State Farm, Pure Storage, the Los Angeles Unified School District, and Neiman Marcus. LendingTree confirmed that its QuoteWizard arm had data stolen through the campaign. Neiman Marcus later reached a USD 3.5 million class action settlement.

Myth vs fact

Myth: Snowflake's platform was hacked.

Snowflake's enterprise environment wasn't compromised, no vulnerability was exploited in the product, and no misconfiguration in Snowflake's infrastructure was involved. Every incident traced back to compromised customer credentials that had been stolen from non-Snowflake systems. The distinction matters because calling this a "Snowflake breach" implies the platform failed. The platform's available security controls, including MFA, network allow lists, and credential rotation policies, simply weren't enabled by the affected customers.

Myth: This was a sophisticated, technically advanced attack.

The technical execution was remarkably straightforward for an operation at this scale. The attackers logged in with valid usernames and passwords, with no zero-day exploitation, no vulnerability chaining, and no platform compromise involved. The reconnaissance tool FROSTBITE was purpose-built for Snowflake enumeration, but the core attack method was credential reuse from stolen databases against accounts that lacked MFA. What made the campaign effective wasn't technical sophistication but the sheer volume of available stolen credentials and the widespread absence of basic security controls.

Myth: Only the organisations that used Snowflake were affected.

The downstream impact extended well beyond the organisations whose Snowflake accounts were directly accessed. AT&T's breach affected approximately 109 million customer accounts, and Ticketmaster's listing claimed 560 million records. When an organisation's cloud data warehouse is compromised, every individual whose data sits in that warehouse is affected. It doesn't matter whether they have any direct relationship with the platform.

Myth: This kind of attack is hard to prevent.

Every affected account was missing the same three controls: MFA, credential rotation, and network allow lists. Any one of those controls would have significantly reduced the attack's effectiveness, and MFA alone would've made stolen passwords insufficient for access. These aren't exotic security technologies; they're standard configuration options that Snowflake made available to every customer, and none of the affected organisations had implemented them.

What would have reduced the impact

Mandatory MFA would've stopped most of the access entirely. With MFA on, a stolen username and password alone can't get an attacker in. They also need a second factor, typically a time-based code from an app or a hardware key. This single control tackles the core of what went wrong: credentials were valid, and that was enough to log in.

Regular credential rotation would've killed the stolen passwords before they could be used. Passwords stolen in 2020 shouldn't still work in 2024. A policy forcing changes every 90 or 180 days would've made the four-year-old credentials useless. For service accounts, key-pair auth removes passwords from the equation entirely.

Network allow lists would've limited connections to known corporate IP ranges. Even with valid credentials, an attacker connecting from a Moldovan VPS or a Mullvad VPN exit node would've been blocked. Allow lists are a blunt tool, but against an attack that relies on remote access from random locations, they work.

Credential monitoring against dark web markets and infostealer logs would've flagged the risk early. Services that watch for corporate logins showing up in breach databases can alert security teams before attackers use them. The credentials in this campaign sat in criminal markets for years, and scanning could've forced password resets long before UNC5537 ever tried to log in.

Endpoint protection on contractor and personal devices would've stopped the initial credential theft. The infostealers that grabbed credentials infected contractor systems, personal laptops, and employee machines. Pushing EDR coverage to all devices that touch corporate cloud services, including contractor and BYOD kit, shrinks the pool of credentials open to attackers.

Cloud security posture management would've flagged the broken configs before anyone targeted them. Automated tools that audit cloud setups can spot accounts without MFA, without network limits, and with stale credentials. Snowflake's own Trust Centre, built after the incident, now gives this kind of visibility out of the box.

What changed after

Snowflake's security response

Snowflake's response to the incident produced substantive changes to the platform's security model.

In September 2024, Snowflake announced that MFA would be enforced by default for all human users in new accounts from October 2024 onward. The rollout followed three pillars: Prompt (nudge users to enrol), Enforce (require MFA via policy), and Monitor (give admins a view of compliance). The platform's also planning to fully retire single-factor password sign-ins for existing accounts.

In November 2024, at the BUILD 2024 event, Snowflake announced Leaked Password Protection (LPP). This service scans for Snowflake passwords found on the dark web. When it finds a leaked password, it identifies the user, checks whether the password is still active, and disables it. The affected user must then log in through single sign-on (SSO) or request a password reset.

Snowflake also rolled out the Trust Centre, a security dashboard enabled by default across all editions. The Security Essentials scanner checks MFA status and network policy usage. A separate CIS Benchmarks scanner tests accounts against the Centre for Internet Security (CIS) Snowflake Foundations Benchmark. Admins can now enforce MFA through policies at both the account and user level.

These changes address the specific control gaps that enabled the 2024 campaign. Default MFA eliminates the single biggest attack vector that UNC5537 exploited. Leaked password protection now automates the credential monitoring process. The Trust Centre provides the visibility that was absent when 165 organisations were running accounts without basic security controls.

The legal proceedings

The federal indictment was filed on 10 October 2024 and unsealed in November 2024. Moucka was arrested in Canada on 30 October 2024, consented to extradition in March 2025, and was arraigned in July 2025 in the Western District of Washington. He pleaded not guilty to all 20 counts. Binns remains in Turkish custody on separate charges. Wagenius, the US Army soldier who operated as "Kiberphant0m," was arrested in December 2024 and has pleaded guilty to charges related to AT&T and Verizon data theft.

The trial date for Moucka and Binns is set for 19 October 2026.

The shared responsibility conversation

The Snowflake incident forced a public reckoning with the shared responsibility model in cloud computing. Cloud platforms provide the tools and make security controls available. Customers are meant to turn those controls on. That model's well-known in theory, but the Snowflake campaign showed what happens when 165 firms all fail to flip the same basic switches.

The result was a shift toward secure-by-default across the cloud industry. Making MFA optional and hoping customers would turn it on had a known failure mode, and 165 firms proved it. Default-on MFA for new accounts is the practical fix: treat security controls as opt-out rather than opt-in.

That shift isn't unique to Snowflake or data warehousing. It reflects a broader pattern across cloud services, where the shared responsibility model is being redrawn. The question isn't just whether customers can turn on security controls, but whether platforms should let them run without them.

Timeline

Date	Event
As early as 2020	Infostealer malware campaigns begin harvesting Snowflake customer credentials from infected non-Snowflake systems
14 April 2024	Earliest evidence of unauthorised access to Snowflake customer instances
14 May 2024	Santander discloses unauthorised access to data hosted by a third-party provider
14 May 2024	Mandiant identifies first confirmed connection: two incident response clients had lost data from Snowflake tenants
20 May 2024	Live Nation/Ticketmaster identifies unauthorised activity in a third-party cloud database
23 May 2024	Snowflake officially acknowledges potential unauthorised access and begins notifying affected customers
24 May 2024	First known instance of stolen data posted for sale on cybercrime forums
30 May 2024	Snowflake publicly discloses attacks on customer databases and provides indicators of compromise
1 June 2024	Joint statement from Snowflake, CrowdStrike, and Mandiant confirms no platform compromise
3 June 2024	CISA issues alert advising Snowflake customers to take steps to prevent unauthorised access
10 June 2024	Mandiant publishes full report on UNC5537
12 July 2024	AT&T publicly discloses illegal download of customer data
September 2024	Snowflake announces default MFA enforcement for new accounts
October 2024	MFA enforced by default for all human users in new Snowflake accounts
30 October 2024	Connor Riley Moucka arrested in Kitchener, Ontario, Canada
November 2024	DOJ unseals 20-count federal indictment
November 2024	Snowflake announces Leaked Password Protection at BUILD 2024
December 2024	Cameron John Wagenius arrested at Fort Hood, Texas
March 2025	Moucka consents to extradition to the United States
July 2025	Moucka arraigned, pleads not guilty
19 October 2026	Trial date

---

---

Related articles

• The MOVEit Breach: How SQL Injection Gave Cl0p Access to 2,773 Organisations Without Deploying Ransomware
• The Colonial Pipeline Attack: How a Single Stolen Password Shut Down US Fuel Distribution
• The SolarWinds SUNBURST Attack: How Clean Source Code Produced a Backdoor
• The Kaseya VSA Attack: How REvil Turned One Vulnerability Into 1,500 Ransomware Deployments

netsec-canary-de32a81d0390.