What happened?
In late May 2024, Live Nation confirmed that criminal actors had obtained data from its Ticketmaster unit — soon quantified at roughly 560 million customers — after attackers used infostealer-derived credentials to log directly into the company’s Snowflake tenant. No exploit, no zero-day, no malware at the victim: reused working credentials and no MFA. By May 30, when this post publishes, the breach had been listed on the ShinyHunters dark-web market and the “Snowflake intrusion wave” had become the month’s defining lesson in identity discipline.
Quick Answer: Ticketmaster’s ~560M-record exposure came from attackers (UNC5537) logging into its Snowflake account with stolen infostealer credentials — no MFA in place, no Snowflake platform breach — part of a credential-driven campaign hitting 165+ organizations that peaked through June 2024.
The mechanics were relentlessly ordinary. An employee or contractor’s credentials, siphoned months earlier by an infostealer infection somewhere entirely else, remained valid against a Snowflake tenant that lacked MFA. Attackers authenticated, queried, and exported — then pivoted to extortion, listing datasets on criminal marketplaces when victims declined to pay. Snowflake’s own thread through the saga was defensive: its threat-intelligence partners (Mandiant, later Google Cloud) documented that every confirmed victim shared the same two conditions: stolen credentials, no MFA, and either a demo account or unused legacy tenant still alive with live data inside.
The “no Snowflake breach” argument, and why it half-worked
Snowflake stated, accurately, that its platform was not breached — attackers used legitimate customer credentials against customer tenants. Technically bulletproof; commercially uncomfortable. The industry conversation split along the expected line: platform vendors emphasized customer-side identity failures, while practitioners pointed out that a data platform holding hundreds of millions of records, accessible by password alone from any IP, is a loaded gun regardless of whose finger is on the trigger. The episode forced Snowflake toward mandatory MFA — announced in waves through 2024 — and forced customers to confront the difference between “our vendor is secure” and “our use of the vendor is secure.”
| Date | Event |
|---|---|
| 2024-04 (earlier) | Campaign begins quietly; UNC5537 accumulates infostealer logs mapping Snowflake tenants |
| 2024-05-28/29 | ShinyHunters lists Ticketmaster dataset (~1.3TB claimed) for sale; Snowflake customer-warning reports surface |
| 2024-05-30 | Live Nation SEC filing confirms breach; this post publishes amid first-wave disclosures |
| 2024-06 | Campaign peaks: Santander, Advance Auto Parts, LendingTree and others disclosed; Mandiant attributes to UNC5537 |
| 2024-06-19→ | Snowflake customer report + Mandiant advisory detail TTPs; leak market “Snow:Bay” appears |
Why infostealer economics made this inevitable
Infostealers industrialized credential collection: millions of infected endpoints vacuum browser-stored passwords, session cookies, and cloud-CLI configuration into logs sold in bulk. Analysts had warned for two years that the bulk matching of those logs against SaaS consoles was a time bomb. Snowflake connectivity — by design ubiquitous and scriptable — meant one reused password bridged a $20 criminal commodity into Fortune-500 data lakes. The campaign did not invent technique; it industrialized arithmetic.
- MFA everywhere, phish-resistant where possible: every human and service identity touching the data platform — no “read-only analyst” exemptions.
- Kill demo and legacy tenants: the campaign repeatedly entered through forgotten trial/demo accounts stocked with production Mirrors of data.
- Network and key policy: allow-list egress for cloud identity, enforce key rotation, and block storage of long-lived credentials in BI tools and notebooks.
- Hunt infostealer exposure: subscribe to leak-feed services; treat any credential appearing in a stealer log as burned the day the log is indexed.
FAQ
How many companies were actually hit?
Public reporting through June converged on 165+ victim organizations, with a few dozen disclosed publicly and far more confirmed privately to Mandiant and Snowflake. The full count may never be crisp because extortion economics discourage victims from naming themselves — the leak-market listings became the de facto census.
What data did the Ticketmaster set contain?
Reported contents included names, addresses, emails, phone numbers, order history, and partial payment data (last four digits, expiry) — a rich identity-verification corpus that makes the set useful for phishing and SIM-swap targeting long after the sale headlines fade. Roughly 560 million individuals were covered in the claimed dataset.
Did Snowflake require MFA after this?
Yes — through 2024 Snowflake rolled out mandatory MFA/TOTP for its platform, alongside network-policy defaults and hardened client-credential handling. Vendors across the data-platform market followed within months, making “password-only access to a data lake” a compliance anomaly rather than a common misconfiguration.
The Shared-Incident Blame Model
SRE culture has a blameless-postmortem ethic for internal incidents; the Snowflake wave stress-tested it across company boundaries. Customers blamed the vendor’s defaults; the vendor published a customer-facing security guide implying customer negligence; insurers began drafting subrogation language. What survived the shouting was a useful doctrine: shared-infrastructure incidents require pre-agreed responsibility matrices — who enforces MFA, who monitors authentication anomalies, who decommissions demo tenants — written before the breach, not negotiated during it.
Role-based accesses bastion-adjacent controls
One engineering postscript that got less attention than the extortion drama: the campaign exposed how rarely Snowflake tenants enforced network policies and key-pair auth before 2024. Post-incident, the platform’s own guidance — allow-listed egress, key-pair or OAuth flows for service accounts, row-access policies — moved from “recommended” to table stakes, and auditors started asking for tenant configuration exports as evidence. The wave’s technical legacy is that data-warehouse identity architecture finally got the review web applications got a decade earlier.
A modest proposal that emerged
The strangest durable outcome was a market one: breached-but-unpaid datasets pooled into a dedicated leak marketplace (dubbed “Snow:Bay” by researchers), letting multiple criminal buyers resell access tiers. Defenders took note because leak-market persistence changes notification math — data does not “leave” once; it circulates with a price curve. Long-tail monitoring of criminal markets thus graduated from threat-intel luxury to breach-response line item.
Detection and response playbook
The Ticketmaster data-for-sale announcement of June 2024 was the retail face of the Snowflake credential wave — and the incident that forced the industry to argue publicly about shared responsibility. The playbook covers what the parent campaign taught plus the specific duties of operating customer data in someone else platform.
- Map every SaaS tenant holding customer data, with its identity posture. The Ticketmaster exposure ran through a cloud data platform account. The exercise every organization needed: for each platform holding customer data — analytics, CRM, support — document tenant owners, MFA state, service-account inventory, and export paths. Gaps in that map are pre-written incident scope.
- Detect bulk movement, not just access. Campaign attackers used legitimate platform features to stage and export data. The detection that generalizes: baselines on query volume, result-set size, and export frequency per identity — with alerting on order-of-magnitude deviations. In analytics platforms, the exfiltration looks like a big query; only volume baselines make it visible.
- Resolve responsibility before the incident, in writing. The no-Snowflake-breach argument was technically true and commercially useless: customers experienced a Ticketmaster breach regardless of which party configuration failed. Contracts and runbooks should specify notification duties, forensic cooperation, and credential responsibility for every shared platform — because the argument about blame is unwinnable after the fact and unnecessary before it.
- Communicate with the shared-incident model. Victims of platform-mediated breaches must disclose on their own clocks while the platform investigation continues. Pre-drafted templates that distinguish what we know, what the platform has confirmed, and what customers should do now keep disclosure accurate during the attribution gap — the MOVEit notification discipline applied to cloud tenancy.
- Harden service accounts like the humans they impersonate. The abused credentials were largely machine identities without MFA. Key rotation, IP allow-listing, least-privilege scopes, and anomaly monitoring on service accounts close the specific gap this campaign walked through — the machine-identity perimeter is the wide-open flank of SaaS security.
Where this sits in the broader pattern
Ticketmaster was the household name in a 165-plus-victim campaign that also surfaced Santander data and dozens of quieter enterprises — all through the Snowflake credential mechanics this series covers separately. The brand-name entry matters because it moved shared-responsibility from architecture documentation to public argument: customers demanded answers of a vendor whose infrastructure was never breached, and the vendor was technically correct in a way that satisfied no one.
The blame-model debate produced something useful: the industry shorthand that configuration is the customer, detection is everyone, and notification is the data owner. That division of labor is now written into SaaS security posture tooling defaults — automated tenant audits, service-account governance, export monitoring — precisely because the manual version failed at scale in this campaign.
For the broader timeline, this entry marks the moment credential-wave economics met household brands: infostealer logs from ordinary machines became the proximate cause of consumer-scale breaches without any platform being hacked. The defensive bookends remain the same as the parent campaign — MFA everywhere, machine identities included, and baselines on every bulk-export path that touches customer data.
The bottom line. 560 million customer records for sale, one stolen service credential, zero breached platforms — and a blame argument nobody could win. The control is boring and total: MFA on every tenant, governance on every service account, baselines on every export path, and responsibility written down before the incident makes it interesting. Shared infrastructure means shared incidents; only the preparation is exclusively yours.
The per-tenant audit loop deserves automation: tools that continuously enumerate identities, MFA state, and export paths across SaaS platforms now exist precisely because this campaign demonstrated the manual audit cannot keep pace with tenant sprawl. Automate the inventory; reserve human judgment for the remediation order.
Frequently Asked Questions
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Was Ticketmaster or Snowflake breached in June 2024?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Data on roughly 560 million Ticketmaster customers was offered for sale after attackers used stolen customer credentials to access Ticketmaster tenant in the Snowflake platform. Snowflake itself was not breached — the compromise was customer-side credential abuse.”}},{“@type”:”Question”,”name”:”How did attackers get Ticketmaster data from Snowflake?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Using credentials stolen by infostealer malware from a Ticketmaster-related machine, logging into the Snowflake tenant, which lacked MFA, and extracting data with legitimate platform queries and exports.”}},{“@type”:”Question”,”name”:”Who is responsible when a SaaS tenant is compromised?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Contractually it varies, which is the problem: configuration and credentials are customer scope, platform security is vendor scope, but notification duties belong to the data owner. Resolve responsibility in writing before an incident forces the argument publicly.”}}]}
Related Reading
- What Studying 33 Historic Cyberattacks Taught Me About Defending Systems Today
- Passwordless in 2026: Why Passkeys Are Finally Killing the Password (and How Attackers Are Adapting)
- 2022–2024: Lapsus$, Change Healthcare & the XZ Backdoor
- Authoritative reference: CISA Known Exploited Vulnerabilities
- Storm-0558 Forged-Token Breach: The Stolen Key That Read Government Em
- Verkada Camera Breach: 150,000 Feeds Behind One Credential
- Snowflake-Related Arrests: UNC5537’s Kitchener Pinch
