Search for “Snowflake breach” and you will find 2024 headlines about large companies and data for sale. But the most important detail of the case is the one that rarely makes the headlines: Snowflake was not hacked. Attackers did not exploit any platform vulnerability: they got in using customer credentials that had been stolen elsewhere.
What happened
Between April and May 2024, Mandiant’s (Google Cloud) research team identified a campaign —tracked as UNC5537— targeting Snowflake customer instances, the cloud data platform. Attackers used customer credentials obtained through infostealers (malware that steals passwords saved in browsers) and, with them, accessed accounts as if they were legitimate users: they exported data and then tried to extort victims or sell it on forums.
Mandiant and Snowflake notified around 165 potentially exposed organisations. In every investigation, the origin was the same: compromised customer credentials, not a flaw in the platform.
Why it worked so well
Mandiant’s analysis pointed to three factors that repeated over and over:
- The accounts had no MFA: with a valid username and password, access was direct.
- Credentials were still valid years later: some dated back to 2020 infections and had never been rotated.
- There were no allow-lists: the instance accepted connections from anywhere in the world.
And where did the passwords come from? From machines infected by infostealers —in many cases contractors’ personal laptops, also used for gaming or downloading pirated software— that accessed several organisations’ systems at once. A single compromised laptop can open the door to many companies.
Why it matters even if you do not use Snowflake
The pattern repeats across any cloud service: email, CRM, ERP, backups, password managers. The weakest link is usually not the platform, but the accounts and devices that access it. For an SME, the typical consequences are the same: stolen customer data, business disruption and, when personal data is involved, 72-hour notification duties (as we explain in the GDPR guide for small businesses).
How to protect yourself
- Turn on MFA everywhere: email, cloud, CRM, banking, password manager. Even better if it is phishing-resistant (security keys or code apps, not SMS). It is the single measure that would have stopped the Snowflake case on its own.
- Rotate credentials and remove dead accounts: passwords of former employees, contractors and test accounts are the most forgotten. Change passwords after any suspicion and review who has access every quarter.
- Zero reuse: a team password manager stops one service’s leak from opening the rest.
- Limit where access comes from: if your provider allows it, use IP allow-lists or a VPN to reach admin panels.
- Watch your logins: set alerts for sign-ins from new countries, bulk data downloads or out-of-hours access.
- Train your team: infostealers usually get in through pirated software, cracks or dodgy downloads. It is the same link attackers target with phishing emails.
If your credentials are stolen today
- Change the affected password —and the password of any service where you reused it.
- Revoke active sessions and tokens (changing the password is not enough).
- Review access logs from recent weeks: IPs, times and downloads.
- If personal data is compromised, assess notifying the AEPD within 72 hours.
- Document what happened and review which control (MFA, rotation, access limits) was missing.
If you want to check what part of your information is already out there —known breaches, exposed credentials, public company data— our free OSINT audit summarises it in a report within 72 hours, without accessing your systems.
Sources: Mandiant (Google Cloud) — UNC5537 Targets Snowflake Customer Instances and the hardening guidance Snowflake published for its customers.