UNC5537 and Snowflake customers: the accounts had no second factor
Ticketmaster, Santander and other Snowflake customers lost data in 2024 because their own accounts were signed in with passwords stolen elsewhere. The campaign is UNC5537. The control is MFA plus a network policy.
In May and June 2024 a cluster Mandiant named UNC5537 used stolen customer credentials to log into Snowflake accounts that did not require multi-factor authentication and often had no network policy. Google's threat-intelligence write-up, published 10 June 2024, is the public record. Snowflake said its platform had not been breached by a vulnerability.
The data that left belonged to the customers: support tickets, account records, and in some cases large identity sets. The login was valid. That is why a scanner looking for a CVE on the warehouse found nothing, and why the incident still happened.
How the logins were valid
Mandiant described credentials stolen by infostealer malware on contractor and employee machines, then replayed against Snowflake accounts that accepted a password alone. A list of those accounts circulated. The attacker did not need a new bug in the warehouse. They needed a password that still worked and an account with no second factor.
Snowflake's own guidance that month told customers to enforce MFA, to place a network policy on the account, and to hunt for connections from the published indicators. Those three steps are the incident response and the prevention. They are the same list.
What left, in public
Ticketmaster's parent and Santander were among the organizations that confirmed data taken from Snowflake-hosted environments. AT&T later tied a large call-record disclosure to a cloud data warehouse in the same family of events. The exact table in your account is not in those headlines. The login history is.
A contractor laptop with a saved password is in scope. So is a service account created for a dashboard and never given MFA because the integration 'could not prompt'. Service accounts are how this campaign stayed quiet: no human to approve a push.
What Mandiant said it was not
Not a Snowflake zero-day. Not a broken authentication service inside the platform. Customers who had already enforced MFA were not the ones in the campaign's successful logins, according to the report. That sentence is the one to test against your account settings, not against a press release.
Blaming the warehouse and blaming the user are both incomplete. The warehouse allowed a password-only account. The customer left one. Either side could have made the login fail. Only the customer can see their user list tonight.
MFA, network policy, then the users
Turn on MFA for every human and reject password-only service accounts. Use key-pair or OAuth for jobs, scoped to the warehouse they need. Add a network policy so a login from an unexpected network fails even with a password. Rotate credentials that have appeared in an infostealer dump. The patching version is not a Snowflake release. Mandiant and Snowflake said on 10 June 2024 that no platform vulnerability was involved. The control in that advisory is MFA on the customer account.
Read the login history for May and June 2024, and for any later replay, looking for client names you do not run. If a session landed, treat the data that account could select as disclosed and notify the people in it. An agent or a notebook that connects with a shared password inherits the same hole. Give it a credential that cannot be typed into a browser.
Mandiant / Google Cloud threat intelligence on UNC5537, 10 June 2024.
https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion
Frequently asked questions
Was Snowflake's platform hacked?
Mandiant's June 2024 report and Snowflake's statements described stolen customer credentials against accounts without MFA, not a vulnerability in the Snowflake service. Check your account's MFA and network policy anyway.
Does MFA close this campaign's path?
For the password replay UNC5537 used, yes: an account that requires a second factor does not open on the stolen password alone. Pair it with a network policy and with credentials for jobs that are not a shared password.
Which customers were named?
Public confirmations included Ticketmaster and Santander. Your exposure is your login history and the grants on any account that accepted a password without MFA, not membership in that headline list.