The Snowflake customer breaches of 2024 are the rare incident where hundreds of organizations, including Ticketmaster, AT&T wireless, Santander, Advance Auto Parts, Neiman Marcus, LendingTree, and others, were compromised through the same vendor surface at the same time, and yet the vendor itself was never breached. Mandiant, CrowdStrike, Snowflake, and CISA have all published findings that tell one story: attackers bought or stole customer credentials, found that MFA was not enforced, and walked into Snowflake tenants through the front door. This post is a root-cause walkthrough that every SaaS customer should read.
What Actually Happened?
Starting in April 2024 and accelerating through May and June, the threat actor tracked by Mandiant as UNC5537 systematically authenticated to Snowflake customer tenants using credentials obtained from infostealer logs, some of which had been sitting in criminal marketplaces since 2020. The attackers did not exploit a vulnerability in Snowflake. They logged in with username and password, ran queries to enumerate tables and dump data, and then extorted the victim organizations.
Snowflake's own June 2, 2024 statement confirmed the pattern: targeted activity was limited to customer accounts without MFA, with credentials sourced from historical infostealer malware infections, and Snowflake's production environment itself was not breached. Mandiant's June 10, 2024 writeup on UNC5537 named 165 potentially affected organizations.
The most visible downstream incidents included Ticketmaster (Live Nation 8-K filed May 31, 2024, 560 million records allegedly offered by ShinyHunters), Santander (credit card and account data for staff and customers), and AT&T (call and text metadata for nearly all wireless customers from mid-to-late 2022, disclosed in July 2024). The breach records often traced back to a single Snowflake instance that had been accessed without MFA.
What Is the Confirmed Timeline?
- 2020 - 2024: Contractor and developer machines across many organizations are infected by infostealer families (RedLine, Vidar, RisePro, Lumma, Raccoon). Credentials harvested from browser-stored passwords and credential managers land in criminal marketplaces.
- April 14, 2024 onward: UNC5537 begins systematically testing Snowflake customer logins using those credentials.
- April 2024: Ticketmaster / Live Nation Snowflake tenant accessed.
- May 20, 2024: Snowflake receives initial reports of suspicious activity tied to a specific customer.
- May 23, 2024: Santander confirms a breach affecting staff and customer data in Spain, Chile, and Uruguay.
- May 30, 2024: ShinyHunters lists Ticketmaster data for sale.
- May 31, 2024: Live Nation 8-K.
- June 2, 2024: Snowflake, Mandiant, and CrowdStrike publish joint indicators and the definitive "no Snowflake compromise, customer credentials abused" finding.
- June 10, 2024: Mandiant publishes the UNC5537 report.
- July 12, 2024: AT&T discloses its Snowflake-associated breach covering nearly all wireless customer call/text metadata from 2022.
- July - September 2024: Snowflake rolls out default MFA enforcement for new accounts and begins the path to making MFA mandatory for all human logins.
What Was the Root Cause, Publicly Reported?
The root cause, in the words of the vendor and its partnered IR firms, was three compounding customer-side weaknesses:
- Credentials were stored in places that infostealer malware could harvest. Many of the impacted accounts had passwords saved in browsers, in Chrome profiles synced across personal and corporate devices, or in unmanaged credential managers. Some credentials dated back four years and had never been rotated.
- MFA was not enforced on the affected Snowflake accounts. Snowflake's design treated MFA as an opt-in per-user control. Many customer admins either did not enable it or did not realize that service accounts without MFA would be valid targets for password-only login.
- Network-layer restrictions (Snowflake network policies that allow only certain IP ranges) were either not configured or were wide open. This meant a credential obtained anywhere in the world could authenticate directly to production.
Mandiant and CrowdStrike both noted that in many cases the infected machine was a contractor's personal device, used to access multiple customer tenants, which amplified the blast radius. Snowflake itself was never breached. The shared-responsibility boundary failed because customers did not enforce the controls that Snowflake offered.
What Are the Supply Chain Implications?
The Snowflake incidents are a supply chain event even though no code was tampered with. Concentrated SaaS is software supply chain, and the 2024 events illustrate three specific patterns:
- Contractors and third-party developers are a shared attack surface across many customers. One infected laptop touched multiple Snowflake tenants. This is a TPRM problem, not a vendor problem.
- Shared-responsibility models fail silently when default settings are permissive. Snowflake documented MFA as recommended. In practice, "recommended" is functionally "off" at enterprise scale.
- Data warehouses are now among the highest-value targets because they concentrate clean, de-deduplicated, business-critical data that would otherwise be spread across a dozen systems.
The CISA Secure by Default guidance and the post-breach changes Snowflake implemented (moving MFA from opt-in to default, promising mandatory MFA, adding network policy defaults) are the correct response. Every major SaaS vendor should read these events as a preview of the expectations regulators and enterprise buyers will now apply.
What Should Defenders Do Now?
- Enforce MFA on every human and every service identity across every SaaS tenant. For service accounts that cannot carry MFA, use key-pair authentication with rotation, not long-lived passwords.
- Build a program around infostealer monitoring. Stealer log marketplaces can be monitored. If credentials tied to your corporate domain appear, treat it as a P1 incident and rotate immediately. This is cheap insurance.
- Restrict SaaS tenant access by network policy or Zero Trust broker. Snowflake offers IP allowlists and network policies. Most SaaS vendors do. Configure them.
- Audit contractor identity. If contractors touch your Snowflake or BigQuery or Databricks environment, they should authenticate through your IdP with your MFA, from managed devices. Bringing their own credential manager is not acceptable.
- Rotate credentials on a hard schedule. Some of the credentials in UNC5537's arsenal were four years old. No production credential should live that long.
- For security teams at SaaS vendors: move MFA and network policies to default-on and loud-opt-out, not default-off and quiet-opt-in.
What Are the Broader Lessons for the Industry?
Three lessons. First, infostealer logs have become the cheapest, most reliable initial access primitive in the criminal ecosystem. Every organization is already exposed through some contractor's personal laptop. Plan around that reality. Second, shared-responsibility boundaries between SaaS vendors and their customers are a polite fiction if defaults are permissive. Make the secure path the default and the insecure path loud. Third, data concentration in warehouses and lakes creates a new blast radius. When a single Snowflake tenant can hold years of customer transaction history, the economic incentive to steal that tenant is enormous. Defenders should be asking where else they have concentrated data that is protected by password-only authentication, and fixing it before UNC5537's next cousin starts scanning.
How Safeguard.sh Helps
Safeguard.sh is designed for exactly the post-Snowflake reality where your most valuable data sits in third-party SaaS and your most dangerous credential is the one your contractor saved in Chrome. Reachability analysis correlates IdP, SaaS posture, and data warehouse configuration to filter 60-80% of noise and surface the user accounts, service principals, and tokens that actually reach sensitive schemas. Griffin AI autonomously enforces MFA policies, narrows network allowlists, and invalidates credentials whose fingerprints appear in new infostealer dumps. Our SBOM generation and ingest extends beyond application dependencies to inventory SaaS tenants and the service accounts that authenticate into them, while TPRM scoring reflects whether a vendor meets the new baseline (default MFA, network policies, short-lived credentials). With 100-level dependency depth we track transitive trust from a contractor's laptop to your production Snowflake tables, and container self-healing keeps the analytics and ETL runners patched rather than stewing with year-old agent versions.