The Breach
April 2024. A threat group that Mandiant would later track as UNC5537 begins systematically logging into Snowflake customer accounts. Not Snowflake's infrastructure. Not a zero-day in Snowflake's platform. Individual customer accounts, using usernames and passwords that had been sitting in infostealer malware logs for months or years.
By June, Mandiant confirms that at least 165 organizations have been compromised. The names are staggering: AT&T, where attackers exfiltrated over 50 billion call and text metadata records covering nearly every U.S. customer. Ticketmaster, with 560 million customer records exposed. Santander Bank, LendingTree, Advance Auto Parts, Neiman Marcus, Bausch Health. The list kept growing.
The attackers didn't need anything sophisticated. They had valid credentials. The accounts didn't require MFA. They logged in, ran SQL queries, staged the data, and exfiltrated it. Then they extorted the victims. AT&T reportedly paid $370,000 trying to get the stolen data deleted.
"The attackers didn't hack Snowflake. They logged in. 165 times. With passwords that were stolen as far back as 2020. And still worked in 2024 because nobody had rotated them."
The Attack Vector: Infostealer Credentials at Scale
The credentials came from infostealer malware: programs like VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA, and METASTEALER that infect individual machines and harvest every saved password from browsers, password managers, and credential stores. Some of these infections dated back to 2020.
UNC5537 didn't deploy the malware themselves. They purchased the credential logs from dark web marketplaces. Then they built a custom tool, tracked by Mandiant as FROSTBITE, to systematically test Snowflake credentials at scale. Valid credentials were used to connect via DBeaver, a legitimate database management tool, where they ran reconnaissance queries and exfiltrated data.
The attack chain was brutally simple: buy stolen passwords, test them against Snowflake, log in where MFA isn't required, download everything, demand payment.
More than 80% of the compromised accounts had prior credential exposure in known breach databases. These weren't novel compromises. They were passwords that had been publicly burned and never changed.
The Five IAM Failures
Snowflake's platform wasn't breached. Its customers were, because they hadn't implemented the identity controls that would have prevented every single one of these intrusions. Five failures compounded into a campaign that affected 165 organizations:
-
01
No multi-factor authentication At the time of the breach, Snowflake did not enforce MFA by default. Customers had to opt in. The result: the compromised accounts relied entirely on single-factor authentication, a username and password. When those passwords were stolen by infostealers, there was no second barrier. MFA alone would have stopped this entire campaign.
-
02
No credential rotation, some passwords were four years old Mandiant found that many compromised credentials had not been rotated since they were first created. Some dated back four years. There was no policy requiring periodic password changes, and no mechanism to detect that credentials had appeared in known breach databases. The passwords were burned in 2020 and still unlocking production data warehouses in 2024.
-
03
No network allow lists or conditional access The compromised Snowflake instances had no IP allow lists or geolocation restrictions. Any valid credential could authenticate from anywhere in the world. There were no conditional access policies to flag logins from unusual locations, unfamiliar devices, or known threat infrastructure. The attackers logged in from their own machines. And nothing noticed.
-
04
No monitoring for anomalous access patterns UNC5537 used SQL commands, SHOW TABLES, SELECT, CREATE STAGE, to enumerate databases, download tables, and stage data for exfiltration. These queries, executed by accounts that may not have logged in for months, running bulk data exports across entire environments, should have triggered alerts. In most cases, they didn't. Nobody was watching the access logs.
-
05
No separation between human and service credentials Many of the compromised accounts were interactive user accounts being used for automated data pipelines. Or service accounts with interactive login capabilities. There was no clean separation between human identities and machine identities. When a human's password was stolen, it could be used interactively because the account was never scoped to machine-only authentication. Identity sprawl created the opening.
Why This Matters for Growing Companies
You probably don't have 50 billion records in Snowflake. But you almost certainly have a SaaS platform, maybe Snowflake, maybe Databricks, maybe a BI tool, maybe your HRIS, where credentials are the only thing between the internet and your sensitive data.
The Snowflake breach is a credential hygiene problem at industrial scale. And credential hygiene is where most growing companies are weakest. Here's why:
You inherit credentials during acquisitions. When a PE firm acquires a company, the target's SaaS accounts, API keys, and service credentials come with the deal. Nobody inventories them. Nobody rotates them. Nobody checks whether the passwords appeared in a breach three years ago. They just keep working, until someone else uses them.
MFA adoption is uneven. You may have MFA on your core IdP. But does every downstream SaaS app enforce it? Snowflake didn't require it by default. Neither do most data platforms, developer tools, or operational systems. The gap between "MFA is available" and "MFA is enforced" is where attackers live.
Nobody owns credential lifecycle. In a mid-market company, who decides when passwords get rotated? Who monitors for credential exposure? Who reviews which accounts have interactive login vs. service-only access? If the answer is "nobody" or "IT does it when they remember," you have the same exposure these 165 companies had.
"The Snowflake breach wasn't one incident. It was 165 companies making the same mistake independently: trusting that a password, set once and never changed, would protect their most sensitive data."
What the Aftermath Looked Like
Two members of UNC5537 were arrested. Connor Riley Moucka, a 25-year-old Canadian operating under aliases "Waifu" and "Judische," was arrested in Kitchener, Ontario in October 2024. John Erin Binns, 24, was arrested in Turkey in May 2024. Both were linked to broader threat groups including Scattered Spider and ShinyHunters.
The arrests didn't undo the damage. AT&T's 50 billion records were already exfiltrated. The U.S. Department of Justice requested AT&T delay public disclosure, citing national security concerns. The metadata revealed communication patterns of government officials and intelligence targets.
Snowflake's response reshaped the platform. They began requiring MFA for all new accounts and rolled out admin-driven MFA enforcement policies. But for 165 customers, the policy change came after the breach: not before.
The total extortion proceeds exceeded $2 million. The cost to affected organizations, incident response, forensics, notification, litigation, and reputation damage, was orders of magnitude higher.
The Lessons
The Snowflake breach is the clearest example in recent history of what happens when credential lifecycle management is treated as optional. The pattern is always the same:
Passwords that never expire. If a credential works forever, a stolen credential works forever. Rotation isn't about compliance checkboxes, it's about limiting the blast radius when (not if) a credential is compromised.
MFA that's available but not enforced. Snowflake had MFA. It just wasn't required. "Available" is not a security control. "Enforced" is. Every SaaS platform in your environment needs MFA enforcement at the tenant level, not left as an individual user choice.
No visibility into credential exposure. These passwords were in known breach databases. Services like Have I Been Pwned had flagged many of them. But nobody was checking. Credential monitoring, comparing your active credentials against known compromises, is a basic hygiene step that most organizations skip entirely.
Shared responsibility means shared risk. Snowflake's security model placed credential management on the customer. That's standard for SaaS. But most customers assumed the platform was handling it. The gap between the shared responsibility model on paper and the shared responsibility model in practice is where 165 breaches happened.
What You Can Do Now
If your organization uses cloud data platforms, SaaS tools with direct login, or any system where credentials are the primary access control, here are the five things to check this week:
1. Enforce MFA on every SaaS platform that holds sensitive data. Not "enable." Enforce. At the tenant level, with no exceptions. If a platform doesn't support tenant-level MFA enforcement, that's a risk you need to document and escalate. Not accept.
2. Audit credential age across all cloud platforms. Any password older than 90 days on a data platform is a liability. Any password older than a year is an emergency. Run the report, rotate the oldest ones first, and set a policy going forward.
3. Check your credentials against known breach databases. Use Have I Been Pwned's domain search, Enzoic, or SpyCloud to identify which of your active credentials have appeared in breach data. If any match, rotate them immediately: the attackers already have them.
4. Separate human and machine identities. Service accounts should authenticate via API keys or OAuth tokens, not interactive passwords. Human accounts should have MFA. When these identities are mixed, a stolen human password can drive automated exfiltration, exactly what happened at Snowflake.
5. Implement network restrictions. IP allow lists, conditional access policies, geographic restrictions. If your data warehouse accepts logins from any IP address on earth, you're relying entirely on credentials that may have already been stolen. Add a second layer.
Credentials expire. Your security shouldn't.
The Snowflake breach wasn't a platform failure. It was a credential lifecycle failure replicated across 165 organizations. The same exposure exists in every growing company with SaaS platforms, inherited credentials from acquisitions, and no systematic approach to credential hygiene.
Risk Ready Identity conducts focused Identity Security assessments for growing companies, purpose-built to surface credential lifecycle gaps, MFA enforcement blind spots, and SaaS access risks in two weeks. You get a clear findings report, a prioritized remediation roadmap, and an executive readout your board can act on. No ambiguity about scope, no open-ended hourly billing.
The next breach has already happened.
We break down how identity failures led to real-world breaches, and what your organization can learn before it happens to you. Straight to your inbox when it publishes.
Subscribe, it's freeSources. Mandiant, "UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion" (June 10, 2024). Snowflake, "Detecting and Preventing Unauthorized User Access" customer communications (May–June 2024). Hudson Rock, infostealer research on credentials exposed via Lumma, Raccoon, Redline, and Vidar logs (2024). Brian Krebs, "Snowflake Breach Exposes 165 Customers' Cloud Data" (Krebs on Security, June 2024). AT&T Inc. Form 8-K filing with the SEC regarding unauthorized access to a third-party cloud platform (July 12, 2024). Ticketmaster/Live Nation Entertainment 8-K disclosure (May 31, 2024). CISA advisories on credential-based attacks against cloud service providers (2024).