Credentials from 2020, and 165 tenants with nothing in the way
From April 2024, UNC5537 used credentials harvested by commodity infostealer malware to reach more than 100 Snowflake customer tenants, with around 165 organisations ultimately notified. Mandiant found no compromise of Snowflake's own infrastructure: every case was a customer tenant configured without MFA and without network allow-listing.
What worked
Attribution and notification. Mandiant and Snowflake identified the pattern across tenants, tied it to a single actor and got victim notifications out while the campaign was still running, which is what turned a slow drip of unexplained data theft into a campaign defenders could act on.
What failed
The shared responsibility line, in both directions. Customers left single-factor authentication on tenants holding their most sensitive data, and some of the credentials had been circulating in infostealer logs since 2020 without ever being rotated. Mandiant found that 79.7% of the accounts used in the campaign had prior credential exposure. The platform, for its part, did not require MFA by default, and a default that permits this outcome is a product decision as much as a customer one.
The number
79.7%
of the compromised accounts had credentials already exposed in infostealer logs, some dating to 2020.
What to do instead
Treat every corporate credential that has ever appeared in an infostealer dump as burned, and rotate on exposure rather than on schedule; ninety-day expiry does nothing about a password stolen on day two. For any SaaS tenant holding regulated or bulk data, require MFA and restrict access to known network ranges, then verify both from an unmanaged device. If you sell the platform, make MFA the default: this campaign is the argument that a permissive default eventually becomes your incident regardless of where the responsibility line is drawn.
- PrimaryMandiant, UNC5537 analysis