The 2024 Snowflake Customer Wave: Infostealers, Missing MFA, and Ticketmaster

Threat Intelligence

A wave of Snowflake customer breaches in mid-2024 hit Ticketmaster, Santander, and others. Not a Snowflake platform compromise, but a structural failure of how SaaS auth was configured. The lessons matter for every multi-tenant SaaS.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 12, 2024 · 8 min read

In late May and early June 2024, Mandiant published findings on a campaign tracked as UNC5537 that compromised at least 165 Snowflake customer environments. Ticketmaster (560M records reportedly offered for sale), Santander, Advance Auto Parts, and LendingTree were among the named victims. Snowflake's platform was not compromised. The customers' credentials were, and customer-side MFA was either never enabled or had been disabled for the affected service accounts.

Timeline of the campaign

1. 2020 to 2024: Various infostealer families (Lumma, Vidar, RedLine, Raccoon) harvest credentials from end-user workstations, including stored Snowflake browser credentials.
2. Early 2024: UNC5537 begins curating infostealer logs from underground markets, filtering for Snowflake URLs in saved credentials.
3. April to May 2024: Bulk credential replay against Snowflake tenants. Where MFA is not enforced, login succeeds.
4. May 20, 2024: Snowflake publishes its first customer notification.
5. May 31, 2024: Live Nation (Ticketmaster's parent) confirms data theft in an SEC 8-K filing.
6. June 10, 2024: Mandiant publishes the UNC5537 technical report.

Root cause: SaaS auth without MFA enforcement at the tenant level

Snowflake at the time allowed customers to enable MFA per user but did not enforce it tenant-wide by default. Many affected customers had MFA available but had created service accounts with username and password only, because those accounts were used by scheduled jobs that the customer did not want to break with an MFA prompt. Some of those service-account credentials had been used interactively (and therefore stored in browsers and infostealer logs) at some point in their history. The operators bought infostealer logs, parsed them for Snowflake URLs, and tried the credentials.

What the operators exfiltrated and how

Once logged in as a service account or admin user, the operator typically created an external stage pointing to attacker-controlled S3 or Azure storage and executed COPY INTO statements to push table contents out. The data volume was large (multi-terabyte in some cases) and the egress was direct to cloud storage, so it did not traverse customer egress controls. The operator then offered the data on cybercrime forums, often with a Snowflake-specific extortion angle: pay or we publish.

Detection signals every Snowflake customer should run

• SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY filtered for is_success=YES, second_authentication_factor IS NULL, on user accounts whose IS_ROLE includes ACCOUNTADMIN or SYSADMIN.
• New external stages created in the last 30 days, filtered by stage URL not matching your approved storage accounts.
• Large COPY INTO LOCATION events to non-corporate cloud storage URLs.
• Sessions from ASNs known for VPS providers (specifically Mullvad, NordVPN, FrootVPN exits seen in UNC5537 reporting).

Lessons the entire SaaS market absorbed

Snowflake responded in mid-2024 by allowing admins to require MFA for all human users at the tenant level (and later announced MFA-by-default for new accounts). The broader lesson is older and bigger: any SaaS where MFA is opt-in is one infostealer log dump away from a customer breach. We now treat 'MFA not enforced at tenant level' as a finding on its own in SaaS security reviews, regardless of whether individual users have it on.

The cheapest supply chain attack of 2024 was buying a stack of infostealer logs and trying the saved credentials. No zero-days, no implants, just consumer-grade malware leveraged at SaaS scale.

There is a second-order lesson worth naming. Service accounts whose credentials are 'never used interactively' often were used interactively once, by the engineer who set them up, on a workstation that may or may not have ever been clean. Treat every machine-user credential as having been browser-stored at least once, and design auth accordingly.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.