Snowflake Customer Breaches: Why Passwords Without MFA Still Lose

Some of the biggest cloud data breaches of the last few years involved no zero-day, no misconfigured bucket, and no clever lateral movement. In 2024, attackers pulled data from dozens of Snowflake customer accounts using credentials they already had. Snowflake’s own investigation concluded there was no vulnerability in its platform; the accounts simply had a username and password standing between the internet and the data (Snowflake). It is the cleanest argument I know for treating MFA as a baseline, not a feature, and for being specific about which kind of MFA.

What happened

Mandiant tracked the actor as UNC5537 and described the campaign in its investigation write-up. The pattern was consistent:

• Credentials came from infostealer malware on machines, often contractor or personal devices, some logs dating back to 2020.
• Many of the affected accounts had no MFA enrolled.
• Many credentials had never been rotated since they were stolen.
• Some accounts had no network allow-list, so a login from anywhere worked.

The attacker logged in with a legitimate password, ran queries and bulk exports from a rented VPS, and then extorted victims. Nothing about the access looked like an exploit, because it wasn’t one.

Root cause

Three controls were absent at once, and any one of them would have broken the chain: enforced MFA, credential rotation or expiry, and network restrictions on the identity. The deeper issue is that the platform let customers run human-capable accounts without those guardrails by default, and customers treated a service-style login as low risk because it was “just analytics.”

Credential stuffing is the same failure at scale. Leaked password lists are replayed against every SaaS admin console and cloud login page. If the password is the only factor, the attacker’s success rate is a function of how often your people reuse passwords, which is to say, high.

Blast radius

The damage depended on what the account could read. A data-warehouse login with broad role grants is effectively a bulk-export tool. The same logic applies to your cloud console, CI/CD admin, IdP, and source-control org owners: one password-only account with wide permissions is a single-step breach. Stolen data also tends to contain more credentials, so one miss can seed the next.

Why “MFA” isn’t enough of an answer

Not all second factors survive this threat model:

• SMS and voice codes fall to SIM swaps and interception.
• TOTP and push approvals are phishable. An adversary-in-the-middle proxy relays the code in real time, and push fatigue gets approvals from tired users.
• Passkeys and FIDO2 security keys are bound to the legitimate origin, so a look-alike domain gets nothing usable. This is the phishing-resistant tier.

Infostealers add a wrinkle: they also grab session cookies, which bypass MFA entirely. That is why short session lifetimes and device-bound sessions matter alongside the factor itself.

Remediation

Prioritize by blast radius, not by headcount.

1. Inventory human-capable identities in every SaaS and cloud platform, with admins and anything holding bulk-read data first. Service accounts that can log in interactively count.
2. Enforce MFA at the IdP, not per app. Put SSO in front of everything you can, then disable local password logins. In AWS, use IAM Identity Center and require MFA there; for root users and any remaining IAM users, enable MFA and prefer passkeys or FIDO2 keys.
3. Require phishing-resistant factors for privileged roles first. A conditional-access policy that demands FIDO2 for admin groups is a realistic phase one; everyone else can follow.
4. Add network and device conditions. Allow-list corporate egress or require a managed device for admin sessions, so a stolen password from a random VPS fails on its own.
5. Rotate and expire. Force a reset for any credential that predates your MFA rollout, and use key-pair or OIDC auth for programmatic access instead of passwords.
6. Watch for the replay. Alert on logins from hosting-provider ASNs, new geographies, and unusual bulk-export volume on data platforms.

Gotchas

• Keep two registered keys per admin plus a documented break-glass path, or a lost key becomes an outage. Store break-glass credentials offline and alert on any use.
• Legacy protocols (IMAP, basic auth, old API tokens) often skip MFA. Disable them or you’ve built a locked front door beside an open window.
• Don’t let helpdesk reset flows downgrade a user to SMS. Attackers target recovery paths precisely because they are weaker than the login.

Takeaway

The Snowflake incidents weren’t a story about a vulnerable product. They were a story about identities that could be reached with one secret. If a stolen password alone can open a console that holds production data, assume it already has been stolen, and make the second factor something an attacker can’t phish or replay.