Case study · 2024
Snowflake customer data thefts, 2024
Stolen passwords, no MFA and no network allow lists opened about 165 organisations’ cloud data.
Credential theft · cloud
What happened
- From at least April 2024, a financially motivated group tracked by Mandiant as UNC5537 logged into Snowflake customer accounts with stolen usernames and passwords, exported large volumes of data and then tried to extort the victims or sell the data.
- Mandiant and Snowflake notified about 165 potentially exposed organisations. Mandiant said it found no evidence that Snowflake’s own enterprise environment was breached.
- Most of the credentials came from infostealer malware on non-Snowflake systems, some infected as far back as 2020, including contractor computers also used for personal activities.
Root cause
Customer accounts could be accessed with only a username and password. Mandiant identified three common factors: no multi-factor authentication, credentials that had not been rotated for years after being stolen, and no network allow lists limiting where logins could come from.
Control failures
- MFA was optional and not enforced on accounts holding large volumes of sensitive data.
- Old credentials were never rotated, so years-old stolen passwords still worked.
- No network allow lists or conditional access for data platform logins.
- Weak visibility of which teams and contractors had created cloud data accounts outside SSO.
Lessons for GRC
- Shared responsibility: the cloud provider secures the platform, but identity and access configuration is the customer’s job. Put it in your control framework explicitly.
- Enforce SSO with MFA on every SaaS and data platform, and find accounts that bypass SSO.
- Rotate service and user credentials, and monitor infostealer exposure of staff and contractor accounts.
- Include contractor device hygiene in third-party requirements when they access your data.