Snowflake-customer mass credential-stuffing

What happened

Between April and June 2024, the threat actor Mandiant tracks as UNC5537 conducted a systematic campaign against customer accounts on Snowflake, a cloud data warehouse platform used by enterprises to store and analyse large-scale datasets. The attackers identified Snowflake customer accounts whose credentials had been captured by infostealer malware over the preceding years, and used those credentials to authenticate directly to the Snowflake web interface and internal APIs. Where no multi-factor authentication was enforced — which was the case for a large proportion of affected tenants, because Snowflake did not mandate MFA by default — login succeeded with a valid username and password alone.

The attackers then used legitimate Snowflake query functionality to enumerate available tables and download data. From the victim’s perspective the access was technically indistinguishable from normal internal use: a valid credential, authenticating normally, running queries. No vulnerability was exploited. No malware was deployed on Snowflake’s infrastructure. The platform functioned exactly as designed; the failure was one of access control defaults.

Snowflake and Mandiant confirmed approximately 165 uniquely identified customer tenants were accessed. The named victims that disclosed publicly represent some of the largest data exposures of 2024. Ticketmaster’s parent Live Nation confirmed in a US SEC filing that data on approximately 560 million customers had been exfiltrated. AT&T disclosed that records covering call and text metadata for approximately 109 million customers — encompassing nearly all AT&T mobile subscribers — had been accessed from a Snowflake-hosted data environment. Santander Bank confirmed customer and staff data including account details for customers in Spain, Chile and Uruguay were taken. Advance Auto Parts, Neiman Marcus, LendingTree, Pure Storage, Cylance, and others disclosed breaches in the same campaign period.

Two individuals — Alexander Moucka (Canadian national) and John Binns (US national) — were arrested in connection with the campaign in late 2024.

How it worked

The attack’s inputs were credentials produced by infostealer malware. Infostealers — malware variants such as Raccoon Stealer, Vidar, LummaC2, and others — are sold as services in criminal markets and are designed to harvest credentials saved in web browsers, password managers, and application stores from infected personal computers. They do not require elevated privileges to run; they execute in user-space and exfiltrate saved credentials, cookies, and session tokens within seconds of infection, then send the results to an attacker-controlled server.

UNC5537 built or purchased a corpus of Snowflake-relevant credentials from infostealer logs available in criminal markets. The logs included credentials from employee devices that had been infected at some point over the prior several years — in some cases, the infections predated the attacker’s campaign by years. The credentials remained valid because the accounts had not been rotated and were not protected by MFA.

The attackers automated credential-testing against Snowflake’s authentication endpoints. Valid credentials returned access tokens; the attackers then used these tokens to query Snowflake’s SQL API, enumerate available databases and tables, and download contents. Snowflake’s platform logs captured these activities, and those logs became the primary forensic source for identifying affected tenants after the campaign became public.

Snowflake’s own infrastructure was not compromised. The company itself was not hacked. The campaign exploited the gap between what was technically possible on the platform — password-only authentication — and what a secure enterprise deployment of a large cloud data platform should require. At the time, Snowflake did not enforce MFA for customer admin accounts by default, leaving enforcement to customers as an optional configuration. Many enterprise deployments had not enabled it.

Timeline

• 2022–early 2024 — Infostealer malware infections on employee devices across many organisations; credentials for Snowflake accounts captured and circulated in criminal markets.
• April 2024 — UNC5537 begins systematic credential testing against Snowflake customer tenants; successful logins used to exfiltrate data at scale.
• Late May 2024 — Snowflake and Mandiant identify the campaign; Snowflake notifies potentially affected customers and publishes guidance on detecting unauthorized access.
• 31 May 2024 — CISA and FBI publish advisory on the campaign.
• June 2024 — Ticketmaster, AT&T, Santander and others begin public disclosures. AT&T SEC filing reveals 109 million customer records accessed.
• October 2024 — Alexander Moucka arrested in Canada. John Binns arrested in Turkey.
• Late 2024 — Snowflake announces mandatory MFA for all customer admin accounts and enhanced default security controls.

What defenders should learn

The Snowflake campaign is the definitive illustration of why MFA defaults on cloud platforms matter as much as an organisation’s own security policies. Snowflake’s customers included some of the world’s largest companies with substantial security teams and significant security investment. Those organisations were breached not because their own defences failed, but because the platform they chose to trust did not enforce the authentication baseline their data warranted. When evaluating any SaaS or cloud-data platform that will hold sensitive data, the relevant security question is not only “what can we configure?” but “what does this platform enforce by default, and what happens to customers who do not configure it correctly?”

The infostealer threat model deserves specific attention. The credentials used in this campaign were not obtained through phishing or direct attacks on corporate networks. They were obtained from personal devices — personal laptops, home computers — that happened to have a work credential stored in the browser. Employees’ personal devices are outside most organisations’ security perimeter but are increasingly a source of valid corporate credentials. Organisations should monitor for their credentials appearing in infostealer logs (several commercial services provide this), and should treat any credential appearing in such a feed as compromised and requiring immediate rotation, regardless of how old the infection was.

Session token theft is a related and underappreciated risk. Infostealers capture not just passwords but session cookies and access tokens. Even in environments that had deployed MFA on their Snowflake accounts, a session token harvested after a legitimate MFA-authenticated login would allow an attacker to bypass MFA entirely for the duration of the token’s validity. Token lifetime policies and anomalous-session detection are part of the access control picture that password-plus-MFA alone does not cover.

Finally, the scale of the campaign — 165 tenants, hundreds of millions of records — was made possible by automation. The attackers did not manually target 165 organisations. They acquired a credential corpus, ran automated testing, and extracted data systematically. The industrial character of the operation means that traditional reactive indicators — “were we targeted?” — are the wrong frame. In a mass-credential-stuffing campaign, every organisation whose employees have had infostealer infections and whose accounts lack enforced MFA is in scope by default. The protective measure is structural and pre-emptive, not reactive.