In late May 2024, a threat actor began contacting companies with a similar offer: your data, stolen from your Snowflake cloud data warehouse environment, available for purchase before it gets posted publicly. The list of companies that received this message included Ticketmaster, Santander Bank, LendingTree, Advance Auto Parts, and AT&T. By June, the breach notifications were arriving at 165 organizations. The total exposure eventually included 73 million AT&T customer records, 560 million Ticketmaster records, and tens of millions of records from Santander customers and employees.

Snowflake, the cloud data platform used by over 9,000 organizations for analytics and data warehousing, was not compromised. Its infrastructure had no vulnerability. The attackers did not break into Snowflake; they logged into it. They had obtained credentials for Snowflake accounts from info-stealer malware campaigns - specifically, logs from Lumma, Vidar, and Raccoon Stealer that had been running for months on contractor and employee machines. The accounts they accessed had no multi-factor authentication enabled. On a cloud platform that stores an organization's entire data lake, no MFA meant no second barrier between a stolen credential and every record the organization had ever loaded.

The Attack Pattern: Credential Stuffing at Cloud Scale

The operation was conducted by a threat actor tracked as UNC5537 by Mandiant and as Sp1d3r by others in the security community. The methodology was systematic: obtain stealer logs containing credentials for accounts that accessed Snowflake environments, test those credentials against Snowflake's login infrastructure, identify which produced valid sessions on accounts without MFA, and then query the Snowflake environment for high-value data.

The credential acquisition relied on stealer malware that had compromised machines of contractors, employees, and third parties with Snowflake access. Info-stealers like Lumma and Vidar are routinely distributed through malvertising, cracked software, and YouTube "tutorial" videos with malicious download links. When they run on a machine, they extract browser-stored credentials for every service the user has logged into - including cloud platforms, enterprise SaaS, and internal tools. The Snowflake credentials appeared in stealer logs months or years after the original infection, harvested from systems that may no longer even exist.

Once inside a Snowflake environment, the attacker had access to everything the compromised account could see. For organizations like Ticketmaster and AT&T, whose Snowflake environments held years of transaction data, customer records, and operational logs, this meant complete data dumps of their most sensitive information. The attacker would run queries, export results, and then approach the victim with proof of access - typically a sample of the data - as leverage for extortion.

[INFO]
Snowflake offers MFA as an optional control, not a required one. At the time of the campaign, many organizations using Snowflake had not enforced MFA on service accounts and third-party contractor accounts - the same accounts most likely to have credentials appearing in stealer logs, because contractors use personally owned or less-managed machines. The incident prompted Snowflake to announce plans to require MFA for all human users, a policy shift that addressed the immediate attack vector.

AT&T: 73 Million Records

AT&T's disclosure in July 2024 was the most significant individual breach in the campaign. The company confirmed that records for approximately 73 million current and former customers had been exfiltrated from a Snowflake workspace. The stolen data included call and text message records showing the phone numbers each AT&T number had communicated with, the count and duration of calls, and cell site identifiers that could be used to approximate location during the period covered.

The sensitivity of call detail records (CDRs) is significant beyond the obvious privacy implications. CDR data allows reconstruction of social networks and patterns of life for any person in the database. Combined with public information about known journalists, activists, or public figures, CDR data can identify confidential sources and reveal sensitive relationships. The AT&T breach made this data available to anyone who purchased it before the extortion resolution.

AT&T also disclosed, separately in March 2024, that a different dataset of 73 million customer records (names, addresses, Social Security numbers, account information) had been posted to a dark web forum. The March disclosure was attributed to a 2021 breach that AT&T had not previously acknowledged. The coincidence of two major AT&T breaches in the same year reflected both the scale of AT&T's exposure and the backlog of breach disclosures that organizations sometimes maintain.

Ticketmaster: 560 Million Records

The Ticketmaster breach, confirmed in May 2024, was the largest by record count. A group calling itself ShinyHunters claimed to have stolen 1.3 TB of data including names, addresses, phone numbers, partial payment card information, and event ticket and order details for 560 million users. The data was offered for sale at $500,000.

Ticketmaster's parent company Live Nation issued a breach disclosure that minimized the incident, describing it as a data breach "of a third-party cloud environment" without initially identifying Snowflake as the platform. Subsequent investigation confirmed the Snowflake connection. The scale of the Ticketmaster exposure - 560 million records representing much of the live events industry's customer base - made it one of the largest consumer data breaches in history by unique individuals affected.

[WARNING]
The Ticketmaster and AT&T breaches were both subject to extortion: the attackers offered to sell the data or not post it publicly in exchange for payment. Neither company's public disclosure indicated whether they paid. The broader pattern of the Snowflake campaign showed that cloud data warehouse credentials are high-value targets precisely because they provide access to aggregated data at a scale not available through traditional point-breach methods - a single Snowflake environment might contain data from all of an organization's systems, loaded for analytics purposes. The "blast radius" of a single credential compromise is therefore far larger than a traditional server breach.

UNC5537: The Threat Actor

Mandiant's investigation tracked UNC5537 as a financially motivated threat actor operating primarily from North America. Unlike nation-state groups whose Snowflake access would suggest intelligence collection, UNC5537 was explicitly extortion-focused: the goal was monetizing stolen data through direct ransom demands and dark web sales.

The actor collaborated with a secondary threat actor based in Turkey for infrastructure and data storage. The operation involved purchasing stealer logs from underground markets - specifically targeting logs containing credentials for Snowflake, Salesforce, ServiceNow, and other cloud platforms - rather than running their own malware campaigns. This represents a maturation of the stealer log economy: rather than running commodity credential theft infrastructure, sophisticated actors can purchase high-value credentials from the logs generated by commodity stealers and focus operational effort on monetization.

Several individuals were arrested in connection with the campaign. Alexander Moucka (Waifu/Judische) was arrested in Canada in October 2024 and John Erin Binns was arrested in Turkey. Both faced charges related to the Snowflake campaign. The arrests demonstrated that financially motivated cloud platform attackers operating in North America face meaningful law enforcement attention, unlike their state-sponsored counterparts.

The Structural Problem: Cloud Data Concentration

The Snowflake campaign's scale - 165 organizations breached through a single platform's credential exposure - reflects a structural change in how corporate data is stored and accessed. Cloud analytics platforms like Snowflake, Databricks, and BigQuery are designed to aggregate data from across an organization's systems for analysis. This aggregation is valuable for analytics but creates single points of access to enormous data volumes.

Traditional security models assumed that data was distributed: breaching payroll data required accessing payroll systems, customer data required accessing customer systems, and so on. An attacker had to compromise multiple systems to get a comprehensive picture. Cloud data warehouses, by design, pull this data together. An analyst query that produces a 500-million-row customer file in a cloud platform is the same operation that an attacker runs after compromising the analyst's credentials.

The security implications were not new in 2024 - the concentration risk of cloud analytics had been discussed since the platforms became mainstream. What the Snowflake campaign demonstrated was that this risk was being exploited systematically, at scale, by actors who understood the relationship between stealer log markets and cloud platform access. The architectural concentration of data in cloud warehouses requires correspondingly strong access controls: mandatory MFA, network access restrictions, credential rotation policies, and query monitoring for anomalous large exports.

[IOC]
Snowflake/cloud data warehouse breach indicators: Anomalous large query volumes or large COPY INTO / EXPORT operations from accounts not normally used for bulk export. Login from IP addresses or geographies inconsistent with normal user patterns. Service account logins from residential ISP IP ranges (consistent with stealer-log credential use). Bulk SELECT queries against tables containing PII, especially without WHERE clauses. Snowflake access logs showing logins without MFA for accounts that previously required it. Evidence of info-stealer activity on endpoints used to access Snowflake (Lumma, Vidar, Raccoon - check for process injection, browser credential store access). Snowflake Query History: SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY WHERE FIRST_AUTHENTICATION_FACTOR = 'PASSWORD' AND SECOND_AUTHENTICATION_FACTOR IS NULL shows all MFA-disabled logins.