In 2024, attackers stole data from customers' Snowflake accounts using credentials taken by infostealer malware. Mandiant reported the affected accounts had no multi-factor authentication, and found no evidence of a breach of Snowflake's own enterprise environment. The fixes are on the customer side: MFA, rotation and allow lists.
What happened, in order?
This timeline comes from Mandiant's report on the cluster it tracks as UNC5537.
- November 2020: the earliest infostealer infection Mandiant observed for a credential later used.
- April 2024: Mandiant received threat intelligence about database records that came from a victim's Snowflake instance. Its investigation found the account was accessed with credentials stolen by infostealer malware, and the account had no MFA.
- May 2024: Mandiant began tracking the activity as its own cluster.
- 22 May 2024: Mandiant identified a broader campaign, contacted Snowflake and began notifying potential victims.
- 30 May 2024: Snowflake published detection and hardening guidance.
- 10 June 2024: Mandiant published its report.
- 17 June 2024: Mandiant released a Snowflake threat hunting guide.
Snowflake's own community statement could not be retrieved for this review, so everything above rests on Mandiant's account.
How did the attackers get in?
Mandiant lists several conditions:
- Credentials exposed by infostealer malware.
- No MFA: accounts needed only a valid username and password.
- Credentials that were not rotated, some valid for years, up to four years in some cases.
- No network allow lists restricting access to trusted locations.
- Infections often on contractor systems used for personal activity, where one compromised laptop could expose several organizations' environments.
Mandiant reports that at least 79.7 percent of the accounts the actor used had prior credential exposure, that about 165 potentially exposed organizations were notified, and that the actor targeted hundreds of organizations worldwide.
What did the attackers do once inside?
Per Mandiant, they used Snowflake's web interface, command line client and drivers, ran reconnaissance queries, listed stages, created temporary stages, copied table data out in compressed form and downloaded it. Victims were extorted, and some stolen data was offered for sale on cybercrime forums.
The detail worth noting is how ordinary the activity looked: valid logins and normal database features, from commercial VPN addresses.
What should defenders learn?
The recommendations Mandiant gives are plain and mostly about identity.
- Enforce MFA everywhere, including service and contractor accounts.
- Rotate credentials and retire old ones, especially any that appear in infostealer logs.
- Monitor for credential exposure in infostealer logs and underground markets.
- Use network allow lists so a stolen password alone is not enough.
- Alert on unusual access, and review logs for odd queries and bulk exports.
- Control contractor devices that reach your data.
Notice what is absent: nothing here depends on a software vulnerability. A flaw-free platform still loses data if a password is the sole gate.
How do you check your own exposure?
Ask of every data platform you run: which accounts can log in with only a password? Which service accounts have credentials older than a year? Which logins come from outside expected networks? How would we see a large export at 3 a.m.? If any answer is "we don't know", start there.
Do not assume a vendor setting protects you by default. Read the vendor's hardening guidance and compare it with your configuration.
What to do
- List accounts on data platforms that lack MFA, and close the list within a set time.
- Rotate any credential older than your policy allows.
- Set network allow lists for administrative and service access.
- Subscribe to credential exposure monitoring for your domains.
- Alert on large exports and on logins from new networks.
- Require managed devices for contractors with data access.
- Test your detection by running a harmless bulk read in staging and seeing who is told.
Quick check
Was Snowflake itself breached?
Mandiant reported no evidence that the access came from a breach of Snowflake's enterprise environment. The activity used customer credentials stolen by infostealers.
What single control would have mattered most?
MFA on the affected accounts. Mandiant noted the accounts required only a username and password, though network allow lists and credential rotation would also have helped.
Sources
Last reviewed: 18 October 2026.
