Breach Teardown
What Caused the Snowflake Customer Breaches?
The 2024 campaign against Snowflake customers was not a breach of Snowflake’s platform. Per Mandiant, attackers logged in to roughly 165 customer instances using credentials stolen by infostealer malware, some dating back to 2020. The credentials still worked because the accounts had no MFA, no network restrictions, and passwords that had never been rotated.
- Scale
- ~165 organizations targeted (per Mandiant)
- Attack vector
- Years-old infostealer credentials, no MFA on SaaS accounts
- IAM domains implicated
- Auth/SSO, IGA, Security
- Domino controls hit
- 2 of 4
The Incident
What Happened
Between April and June 2024, a threat actor Mandiant tracks as UNC5537 systematically accessed Snowflake customer instances and exfiltrated data for extortion. Mandiant’s investigation identified roughly 165 potentially exposed organizations. Victims disclosed in SEC filings and press reports included Ticketmaster and AT&T.
What stands out in Mandiant’s findings is how ordinary the access was. Every incident they investigated traced back to credentials stolen by infostealer malware, in some cases years earlier, often from contractor or personal machines. The impacted accounts had not enabled multi-factor authentication, had no network allow-listing applied, and in some cases had not rotated passwords since the original theft.
Snowflake, working with Mandiant and CrowdStrike, stated that its own platform was not compromised. The campaign was a customer-side identity failure at scale, and it pushed Snowflake to make MFA enforcement a default for new accounts.
Attack Chain
How the Attack Compounded
Each step below marks the AXIS control that failed at that point in the chain, where one applies. Steps without a control marker were outside the victim's direct span of control.
Infostealer malware on employee and contractor endpoints harvests SaaS credentials, some as early as 2020.
Credentials stay valid for years. Contractor offboarding and credential rotation never invalidated them.
IGA-01
Single-factor logins succeed because MFA was never enforced on the data platform accounts.
AUTH-01
Nothing flags high-value SaaS tenants running without MFA or network policies. The exposure stays invisible until it is exploited.
SEC-05
Attackers run bulk queries, exfiltrate entire tables without anomaly detection intervening, and move to extortion.
SEC-03
Control Mapping
The IAM Controls That Failed
Every failure point below corresponds to a control in the AXIS question bank, the same 4 controls a maturity assessment would have scored before this incident.
| Control | Domain | Capability | How it failed here |
|---|---|---|---|
| AUTH-01 Domino | Auth/SSO | Adaptive MFA | The compromised accounts were single-factor. MFA on the corporate IdP does not help when a high-value SaaS platform accepts direct logins outside it. |
| IGA-01 Domino | IGA | Lifecycle Management (Joiner / Mover / Leaver) | Credentials stolen in 2020 still worked in 2024, and several belonged to contractors. Lifecycle management that actually terminates access and rotates surviving credentials would have invalidated them years earlier. |
| SEC-05 | Security | Identity Posture & Attack-Surface Management (ISPM) | No posture process surfaced the combination that made the campaign possible: a crown-jewel data platform with direct password login, no MFA, and no network policy. Finding that combination is what identity attack-surface management is for. |
| SEC-03 | Security | User Behavioral Analytics (UBA) | Bulk exfiltration queries across entire customer datasets did not trigger behavioral intervention, despite being volume and pattern anomalies of the largest kind. |
The Maturity Lesson
What Would Have Changed the Outcome
The Domino Effect
Adaptive MFA (AUTH-01) and lifecycle management (IGA-01) are both domino controls. An organization scoring level 0 or 1 on either is capped overall, which matches what happened here: some victims ran sophisticated security programs, but the answer that mattered was whether MFA was enforced on every system holding regulated data, including SaaS platforms outside the SSO perimeter.
The Maturity Level That Mattered
At level 2 or 3 on AUTH-01, MFA enforcement extends to third-party SaaS through SSO integration or platform-native policy, which defeats replayed passwords outright. At level 2 on IGA-01, offboarding reliably disables accounts and credentials, cutting the multi-year shelf life these stolen credentials enjoyed.
This campaign is also a strong argument for assessing identity maturity per data platform rather than per company. The perimeter that mattered was a single SaaS login page, and the organizations breached were the ones whose maturity dropped to zero at that boundary.
Related Compliance Frameworks
The controls implicated in this breach carry citations in these frameworks within the AXIS bank:
About This Analysis
This teardown is based exclusively on public disclosures, regulatory findings, and reporting cited above; it makes no claim of insider knowledge about the internal environment at Snowflake customers. Control mappings express how the publicly documented failure points correspond to capabilities in the AXIS methodology, for educational purposes. AXIS is not affiliated with Snowflake customers.
More From the Breach Radar
Would Your Program Have Caught This?
The 4 controls that failed here are questions in the AXIS assessment. Score your organization against them, and the rest of the bank, in about 20 minutes. No signup required to start.