Snowflake UNC5537, single-factor credentials at cloud scale.

Summary

Snowflake is a cloud data platform used by thousands of enterprises for analytics and data warehousing. Customer tenants authenticate users (and service accounts) via usernames and passwords by default, with optional MFA. In early-to-mid 2024, a threat actor that Mandiant tracked as UNC5537 systematically authenticated to Snowflake customer tenants using static credentials it had obtained from infostealer logs (compromised endpoints whose browser-stored or application-stored credentials had been extracted by commodity malware and sold or shared in underground markets).

The critical point, and one Snowflake was clear about in its public communications, is that Snowflake's own infrastructure was not breached. The initial access vector was always a compromised customer credential. However, because many customer tenants had not enforced MFA, a single-factor credential was sufficient to authenticate and extract data at scale.

Timeline

Attack chain

1. Credential harvesting. Commodity infostealer malware (Lumma, Racoon, Redline, Vidar, and others) infected endpoints months-to-years before the Snowflake incident. Stored browser credentials and application-stored credentials were extracted, aggregated, and sold/shared on underground markets.
2. Credential selection. UNC5537 acquired or accessed infostealer log datasets containing Snowflake credentials and filtered for enterprise targets.
3. Authentication. Using the harvested credentials, the attacker authenticated to Snowflake tenants that had not enforced MFA. A single factor was sufficient.
4. Reconnaissance. Once authenticated, the attacker enumerated accessible databases, schemas, and tables to locate high-value data.
5. Data extraction. Large-scale SELECT and data-export operations against customer-data tables.
6. Monetisation. Sale on underground forums and/or extortion. AT&T reportedly paid approximately $370K to recover/suppress the data in its case.

NHI root cause analysis

The central OWASP NHI Top 10 mappings:

• NHI4, Insecure authentication. The primary failure. Single-factor static passwords are deprecated authentication for high-value data platforms. Tenants that had not enforced MFA had no second line of defence against credential compromise.
• NHI7, Long-lived secrets. Passwords stored in browsers and applications often persist for years without rotation. Infostealer logs from 2022 contained credentials that were still valid in 2024.
• NHI10, Human use of NHI. In several victim environments, the compromised credentials were shared service-account credentials used for analytics integrations, a human-plus-service-account usage pattern that exposes service credentials to human-endpoint risk (browser storage, malware).

It's worth noting carefully: this incident is an NHI case even though the compromised credentials were nominally "user" credentials. The tenants where the attacker had the largest blast radius were those where:

• A user credential had broad data-access permissions (often a service-like usage pattern),
• The credential was shared or used headlessly by automation,
• The tenant had not enforced MFA on the credential.

The NHI failure mode is not that "service accounts" existed but that "broadly-privileged credentials used automationally" existed without the controls appropriate to their true NHI-like role.

Confirmed victims (selected)

• AT&T, approximately 110M customer records (call-detail records metadata for period covering May to Oct 2022 and Jan 2023); reportedly paid ~$370K ransom.
• Ticketmaster (Live Nation), approximately 560M records offered for sale.
• Santander, customers in Spain, Chile, Uruguay; ~30M records reported.
• LendingTree / QuoteWizard, financial-services data.
• Neiman Marcus, approximately 64K records.
• Advance Auto Parts, approximately 2.3M records.
• Additional organisations across finance, retail, and healthcare, public disclosures accumulated over several months.

Impact

• Hundreds of millions of individual records exposed in aggregate.
• Multi-million-dollar remediation and notification costs across victim population.
• Public-company material disclosures by multiple victim organisations.
• Regulatory inquiries in the US, EU, and elsewhere.
• Sustained class-action litigation through 2024 and 2025.
• Reputational and customer-trust impact to some tenants.

Mitigation playbook

1. Enforce MFA on every Snowflake credential. No exceptions for service accounts or automation, use key-pair authentication for automation (Snowflake's supported alternative to passwords).
2. Enforce network policies. Snowflake supports IP allowlisting at the account and user level. Automation credentials should authenticate only from expected IP ranges.
3. Rotate all credentials. Any credential that existed pre-breach and has not been rotated should be considered potentially compromised.
4. Audit query history. Snowflake retains query history; review for anomalous enumeration, unexpected IPs, or large extractions in the attack window.
5. Deploy credential-scanning across the employee endpoint fleet. Hunt for infostealer indicators and rotate credentials stored on any compromised endpoint.
6. Tighten data access policies. Column-level masking, row-level access policies, and dynamic data masking for sensitive tables.
7. Log to SIEM. Stream Snowflake authentication and query events into the SIEM for behavioural baselining.

Lessons that transfer

• "The SaaS platform is secure" doesn't make your tenant secure. Customer-side controls (MFA, network policies, key-pair auth) are where the perimeter actually sits.
• Infostealer logs are a public NHI threat surface. Assume any credential that has ever been entered into a browser on a user's machine is exposed. Act accordingly.
• "User" credentials used by automation are NHIs. They need NHI-level hygiene, rotation, MFA-alternatives, scoped permissions, behavioural monitoring. The label is less important than the usage pattern.
• Default-off controls will be left off. Snowflake's response, making MFA more enforceable, adding admin-level enforcement, simplifying key-pair authentication, reflects an industry pattern: when MFA is customer-optional, a meaningful fraction of customers will not opt in. Vendors need to make MFA the easier default.
• Ransom economics are real. AT&T's reported $370K payment is modest relative to enterprise remediation costs but highly cost-effective for the attacker. This is the operating-margin model for data-theft extortion.

Frequently asked questions

What companies were impacted by UNC5537 in 2024?

The campaign targeted customer-managed Snowflake instances rather than Snowflake's own platform, and a substantial number of organisations disclosed impact through 2024, including several large consumer brands. We deliberately do not publish a running victim list: disclosure varied, some attributions were contested, and a list assembled from press reporting decays into a source of misinformation. Treat any list you find as reporting rather than record, and check the affected organisation's own disclosure.

What was the UNC5537 identity takeover attack?

Credentials for Snowflake customer instances, obtained largely from infostealer infections on machines outside Snowflake's control, were reused to authenticate directly to those instances. The decisive weakness was that the affected accounts were protected by single-factor authentication and had no network restriction, so a valid credential was sufficient. Many were service or integration accounts rather than interactive user accounts, which is why it is an NHI incident rather than a phishing one.

What is the severity of the Snowflake cloud credential attack?

High, but the severity sits in the pattern rather than in any technical sophistication. There was no vulnerability exploited and no platform compromise. Long-lived credentials with no second factor and no network constraint were used exactly as designed by someone who should not have had them. That combination remains extremely common, which is what makes the incident worth studying rather than the scale of any single breach.

Was Snowflake breached?

No, in the sense that matters technically. Snowflake's own platform was not compromised. Individual customer instances were accessed using valid credentials belonging to those customers. The distinction is important for shared-responsibility reasoning: the control that would have prevented it, enforced multi-factor authentication and network policy on non-human accounts, sat with the customer at the time.

What would have prevented the UNC5537 attacks?

Three controls, any one of which would have broken the chain: enforced multi-factor or network-restricted access on the affected accounts, credential lifetimes short enough that a stolen secret expired before reuse, and monitoring for authentication from unexpected sources. The third is the weakest, because a machine account has no travel baseline; the first two are structural and were available at the time.