Observations

What went wrong, and what to do about it

Real breaches, each put through the same four questions: one control that worked, one that did not, one number worth watching, and what should have been done instead. Every entry cites a primary source, because the point of this section is that you can take it to a meeting.

NO. 04/SaaS / Data platform/4 September 2026

Credentials from 2020, and 165 tenants with nothing in the way

Mandiant / Google Cloud Threat Intelligence, UNC5537

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.

Named for the doctrine distinction between a lesson observed and a lesson learned: a lesson is not learned until behaviour has changed and somebody has checked. Pretending otherwise is how the same finding turns up in three consecutive post-incident reports.