The Snowflake Situation: When Your Customer's Credentials Become Your Problem

2024’s biggest “breach that wasn’t a breach” involved Snowflake - the cloud data platform holding some of the world’s most valuable corporate data.

Over 160 organizations had their Snowflake environments compromised. The victim list reads like a Fortune 500 directory: Ticketmaster, Santander Bank, AT&T, Advance Auto Parts, LendingTree, and more.

But here’s the thing: Snowflake itself wasn’t breached. This was entirely about customer credential hygiene.

Let’s unpack what happened and why it matters.

What Actually Happened

A threat actor (tracked as UNC5537 by Mandiant) systematically targeted Snowflake customer accounts using stolen credentials. Their approach:

1. Credential harvesting: Used infostealer malware logs (Vidar, Raccoon, etc.) to gather Snowflake credentials
2. Credential validation: Tested credentials against Snowflake login
3. Data exfiltration: Downloaded customer data from compromised accounts
4. Extortion: Demanded payment to not leak the data

The key detail: these accounts didn’t have MFA enabled.

Snowflake’s investigation found that all compromised accounts:

• Had credentials previously exposed through infostealers
• Were not using multi-factor authentication
• Often had credentials that hadn’t been rotated in years

The Shared Responsibility Mess

This incident perfectly illustrates the challenges of the shared responsibility model.

Snowflake’s position: “Our platform wasn’t breached. Customers are responsible for their own credentials and MFA configuration.”

Customers’ position: “We trusted Snowflake with our most sensitive data. Why wasn’t MFA required?”

Both have a point, which is exactly the problem.

What Snowflake could have done:

• Required MFA for all accounts (they now do, as of late 2024)
• More aggressive detection of credential stuffing attacks
• Alerting on suspicious access patterns

What customers should have done:

• Enabled MFA
• Rotated credentials regularly
• Monitored access logs
• Not left critical data accessible via single-factor auth

Scale of Impact

The affected organizations collectively exposed billions of records:

• Ticketmaster: 560 million customer records
• AT&T: Call records of “nearly all” customers
• Santander: 30 million customer records
• Advance Auto Parts: 380 million customer records
• Various others: employee data, financial records, PII

Total extortion demands reportedly exceeded $20 million across victims.

The Infostealer Connection

This wasn’t sophisticated hacking. It was credential reuse plus infostealers.

Infostealers are malware that harvests credentials from infected systems. When someone’s personal or work computer gets infected:

Infected machine → Stealer runs → Credentials harvested →
Sold on dark web → Attacker buys logs → Tests against services

Many compromised credentials were years old, harvested from contractor laptops or employee personal devices that got infected at some point.

The attackers didn’t need zero-days. They needed $50 and access to dark web credential markets.

Why MFA Would Have Stopped This

Every single compromised account lacked MFA. With MFA enabled:

1. Attacker gets password from infostealer logs
2. Attacker attempts login
3. Snowflake prompts for second factor
4. Attacker doesn’t have access to user’s phone/hardware key
5. Login fails
6. No breach

That’s it. MFA would have reduced this entire incident to failed login attempts.

Lessons Learned

For Cloud Platforms

1. Default to secure configurations

MFA should be opt-out, not opt-in. Yes, it creates friction. The alternative is worse.

2. Detect credential stuffing

Large-scale credential testing should trigger alerts and blocks. If an IP is testing thousands of credential pairs, that’s not normal.

3. Provide better visibility

Give customers easy access to:

• Login attempt logs
• Unusual access patterns
• Geographic anomalies
• API usage spikes

For Cloud Customers

1. MFA. MFA. MFA.

I can’t say it enough. Any service holding valuable data needs MFA. Period.

2. Regular credential rotation

Service accounts and API keys should rotate regularly. Annual rotation is the minimum; quarterly is better.

3. Conditional access

Restrict access by IP, location, and time of day where possible.

4. Monitor for credential exposure

Services like Have I Been Pwned and commercial dark web monitoring can alert when credentials appear in breach data.

5. Infostealer awareness

Your employees’ personal computers can compromise your corporate data. Consider:

• Restricting personal device access to corporate systems
• Endpoint protection requirements for BYOD
• Regular security awareness training

The Shared Responsibility Reality

Cloud security is genuinely shared, and that creates uncomfortable situations.

The provider secures:

• Physical infrastructure
• Platform security
• Network isolation between tenants
• Feature implementation

The customer secures:

• Access credentials
• Authentication configuration
• Data classification
• Access policies
• Monitoring and response

Neither party can fully compensate for the other’s failures. A perfectly secured platform is still compromised if the customer leaves credentials exposed. A customer can’t MFA their way out of a platform vulnerability.

The Snowflake incident landed entirely in customer responsibility territory. But Snowflake’s reputation still suffered because, fairly or not, their name is in every headline.

Looking Forward

Post-incident, Snowflake has:

• Made MFA available for all accounts (now on by default for new accounts)
• Enhanced detection capabilities
• Improved security guidance documentation

The industry should take note: waiting for customers to enable security features doesn’t work. Default secure, allow opt-out for edge cases.

For security teams everywhere: audit your cloud services. Check what authentication methods are in use. Enable MFA where it isn’t. Rotate old credentials.

The next UNC5537-style campaign is probably already running.

References

• Mandiant Threat Intelligence Blog
• Snowflake Security Blog
• Hudson Rock Cybercrime Intelligence

---

The attackers didn’t hack Snowflake. They didn’t need to. They just logged in with valid credentials. Sometimes the simplest attacks are the most effective.