MyRecon OSINT

← Case Files · The Breach Files

2024 · Cloud data

Snowflake, 2024: 165 companies breached without anyone touching Snowflake

Case file · 4 min read · Published 14 September 2026

People affected
around 165 customer tenants; hundreds of millions of individual records
When it happened
April – June 2024
Made public
From late May 2024
How they got in
Credentials stolen by infostealer malware, used against cloud accounts that had no multi-factor authentication
Attributed to
Tracked as UNC5537; two men were charged in the United States in late 2024
What it cost
Extortion demands against individual victims; regulatory and class action exposure across many companies at once

What was exposed: Names · Contact details · Transaction and ticketing records · Call and text metadata · Banking data for some victims

In the space of two months in 2024, roughly 165 companies lost data out of their own cloud data warehouses — Ticketmaster, AT&T, Santander and a long list of others. There was no vulnerability. The attacker signed in with a correct username and password on accounts that asked for nothing else, using credentials that had been stolen from employees' computers, in some cases four years earlier.

What happened

Snowflake is a cloud data warehouse: organisations put their analytical data in it, at enormous scale, and query it. Access is by account, and each customer configures its own authentication.

Between April and June 2024, an actor tracked by Mandiant as UNC5537 systematically logged into customer tenants. The credentials came from infostealer malware — the commodity software that sits on a consumer PC and exfiltrates everything the browser has saved. Those harvests are packaged as "logs" and sold in bulk on criminal markets, often for a few dollars.

Three conditions had to hold for each victim, and where they did, the attacker simply walked in:

  1. The account was protected by a password alone, with no multi-factor authentication enforced.
  2. The credential had never been rotated, so a password stolen in 2020 still worked in 2024.
  3. There was no network restriction limiting logins to known corporate ranges.

Why this is the defining breach of its era. Nothing was hacked in the sense the word implies. The intrusion happened on a contractor's laptop, possibly years before, and the consequence landed in a corporate data warehouse holding hundreds of millions of customer records. The security perimeter of a modern company includes every personal device that has ever held one of its passwords.

Who lost what

Ticketmaster. The attacker advertised 560 million customer records: names, contact details, order history and partial payment data. Live Nation confirmed unauthorised activity in a third-party cloud database.

AT&T. Call and text metadata for nearly all of its mobile customers over a six-month period in 2022 — who contacted whom, how often, and for how long. Not the content, but the pattern, which for many purposes is more revealing. This one has its own case file.

Santander. Customer and employee data across several countries.

Others. Advance Auto Parts, Neiman Marcus, a mortgage brokerage, and around 160 more tenants, each notified individually and each responsible for its own disclosure.

The shared responsibility argument

Snowflake's position was that its platform was not breached, that the accounts were customer-configured, and that MFA was available. All true. Its critics pointed out that a platform holding bulk sensitive data should not have permitted single-factor access by default, and that "available" is not the same as "on".

Both sides of that argument have merit, and the resolution was practical rather than rhetorical: Snowflake moved to enforce multi-factor authentication for new accounts and pushed customers towards policies that require it. Changing a default is a concession that the default was doing work.

The wider lesson generalises well beyond one vendor. In every shared-responsibility model, the security-relevant question is not who is responsible in the contract; it is which party is positioned to make the safe thing happen by default.

The timeline

  1. 2020 onwards — Infostealer malware harvests credentials from employee and contractor machines.
  2. April 2024 — Systematic logins into Snowflake customer tenants begin.
  3. Late May 2024 — Ticketmaster data is advertised for sale; Snowflake and its incident responders begin notifying affected customers.
  4. June 2024 — Mandiant publishes its analysis of UNC5537; roughly 165 affected tenants are identified.
  5. July 2024 — AT&T discloses the theft of call and text metadata.
  6. Late 2024 — Two men are arrested and charged in connection with the campaign; Snowflake announces MFA enforcement for new accounts.

What it changed

Infostealer logs became a recognised enterprise threat. They had been treated as a consumer problem — stolen gaming accounts, drained crypto wallets. This campaign demonstrated that the same logs contain corporate credentials, and threat intelligence teams started buying and monitoring them for their own domains.

Credential rotation stopped being a formality. A password that has never changed since 2020 is not a password; it is a permanent key of unknown distribution. Detection for "credential last rotated" moved into cloud posture tooling.

Defaults became a product security responsibility. The clearest industry-wide outcome is the continuing shift towards secure-by-default configuration in platforms handling bulk data, rather than a documented option a customer can choose to enable.

If you were a customer of one of the victims

  1. Your exposure depends on the specific company, and each published its own notice. Read the one that applies rather than the aggregate headline.
  2. Assume contact details are circulating. Ticketing and retail data drives convincing "there is a problem with your order" scams.
  3. If you administer cloud data platforms, audit for single-factor accounts today. Service accounts and long-lived analyst logins are where this lives.
  4. Check whether your own machine has ever been infected. Infostealer exposure is personal, follows you across employers, and does not show up in company logs — the archive tracks stealer-log collections as they are confirmed.

Checked against every breach on record, against public breach data only. Your address is not sent to us as a form and is not stored — it is handed straight to the lookup tool in your own browser. See the privacy policy.

Questions people ask

Was Snowflake itself hacked?

No. Investigations by Snowflake and by Mandiant found no vulnerability in the platform and no compromise of Snowflake's own systems. The attacker logged into individual customer accounts using valid usernames and passwords, on accounts that did not require a second factor.

Where did the credentials come from?

Infostealer malware on the computers of employees and contractors — in some cases years earlier. Infostealers harvest everything a browser has saved and sell the output as "logs". A credential stolen in 2020 still worked in 2024 because nobody had rotated it and nothing else was required to use it.

Whose data was taken?

The list includes Ticketmaster, where the attacker claimed 560 million records; AT&T, where call and text metadata for nearly all of its mobile customers was taken; Santander; Advance Auto Parts; Neiman Marcus; and around 160 other Snowflake customer tenants. Each victim owned its own data and its own configuration.

Whose fault was it?

The uncomfortable answer is that responsibility was shared and the model made that easy to miss. Customers chose not to enforce MFA and did not rotate credentials; the platform allowed single-factor access to bulk data by default. Snowflake subsequently moved to enforce MFA for new accounts, which is an admission that the default mattered.

Sources

Read next

Case files are written from the public record: regulatory findings, court filings, company disclosures and contemporaneous reporting, cited above. Figures are the ones the organisation or its regulator finally settled on, which is often not the number first reported — where that differs, the page says so. Disputed accounts are marked as disputed rather than resolved in either direction.

← All case files Breach archive →