Snowflake Customer Breaches: How Credential Stuffing at One Cloud Vendor Exposed 165+ Organizations

Not a Platform Breach — Something Worse

In the spring of 2024, a threat actor tracked by Mandiant as UNC5537 systematically targeted Snowflake customer accounts using stolen credentials, compromising data belonging to at least 165 organizations. Critically, this was not a breach of Snowflake's platform infrastructure. Snowflake's own systems were not compromised. Instead, the attackers exploited a far more common and preventable weakness: customer accounts that were not protected by multi-factor authentication (MFA).

The incident became one of the most significant cloud security events of 2024, with victims including some of the world's largest companies and hundreds of millions of individual records exposed. For third-party risk management professionals, it raised fundamental questions about the shared responsibility model in cloud computing and who bears accountability when a vendor's customers fail to implement basic security controls.

How UNC5537 Operated

According to Mandiant's investigation, published in collaboration with Snowflake, UNC5537 obtained credentials from multiple sources, including historical infostealer malware infections that had compromised the devices of Snowflake customers and contractors. The stolen credentials, some dating back to 2020, were still valid because the affected accounts had not rotated their passwords or enabled MFA.

The attackers used these credentials to log in to Snowflake customer accounts, enumerate available databases, and exfiltrate large volumes of data. In many cases, the attackers used a utility called rapeflake (later renamed DBeaver Ultimate in their tooling) to automate data extraction. The stolen data was then used for extortion, with UNC5537 demanding ransoms from victims and threatening to publish or sell the data on criminal forums.

The Victims: Massive Data Exposures

The scale of data exposed through the Snowflake-related breaches was staggering:

AT&T's disclosure was particularly notable: the company confirmed that call and text metadata for nearly all of its wireless customers over a six-month period had been stolen from its Snowflake environment. AT&T reportedly paid a $370,000 ransom to have the data deleted.

The Shared Responsibility Problem

Snowflake's response emphasized that its own platform had not been breached and that the compromises resulted from customers failing to enable MFA. Snowflake was technically correct — the shared responsibility model places authentication controls in the customer's domain. However, the incident exposed a critical gap: Snowflake did not require MFA by default and had not enforced it even for accounts with access to massive datasets.

In response to the incident, Snowflake announced that it would require all customers to implement MFA, a policy change that many security professionals argued should have been in place long before the breaches occurred.

TPRM Implications

• Shared responsibility is a risk gap. The shared responsibility model in cloud computing creates ambiguity about who is accountable for authentication failures. TPRM programs should map the shared responsibility boundaries for each cloud vendor and ensure that their organization meets its obligations on both sides.
• MFA is non-negotiable for data platforms. Any vendor that stores or processes sensitive organizational data must enforce MFA. TPRM assessments should verify MFA enforcement, not just MFA availability.
• Credential hygiene is a continuous process. Many of the compromised credentials dated back years. TPRM programs should require vendors to support and enforce credential rotation policies, and organizations should audit their own credential practices for all vendor platforms.
• Infostealer malware creates long-tail risk. Credentials stolen by infostealers years ago can remain viable if passwords are not rotated. TPRM risk models should account for the time-delayed risk of historical credential theft.
• Cloud concentration amplifies credential risk. When hundreds of organizations store sensitive data on a single cloud platform, a credential stuffing campaign against that platform can produce breaches at industrial scale. TPRM should assess cloud vendor concentration as a risk factor.

FAIR Analysis of Cloud Credential Risk

Applying the FAIR framework to the Snowflake scenario, the threat event frequency is high: credential stuffing attacks are continuous and automated. The vulnerability (lack of MFA) is binary — accounts either have it or do not. The loss magnitude, as demonstrated by the Ticketmaster and AT&T exposures, is extreme. FAIR quantification helps organizations understand that the expected loss from operating cloud data platforms without MFA vastly exceeds the cost of implementing and enforcing MFA across all vendor accounts.