In mid-2024 a financially motivated group that Mandiant tracks as UNC5537 stole data from customer accounts of the Snowflake cloud data platform and tried to extort the victims. Mandiant and Snowflake notified about 165 potentially exposed organisations. Some of the best-known data breaches of that year came from this one campaign.
The striking part is how ordinary the method was. Mandiant found no breach of Snowflake's own platform. Every incident it responded to traced back to customer credentials that had been stolen earlier and never changed.
Where the passwords came from
Infostealers are commodity malware that grab saved browser passwords, cookies and autofill data and ship them to the operator as "logs". Mandiant identified VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA and METASTEALER in this campaign.
At least 79.7% of the accounts UNC5537 used had prior credential exposure, and the earliest infection Mandiant found dated to November 2020. Several infections were on contractor laptops that were also used for personal things like gaming and pirated software. One contractor laptop with admin access to several clients' environments becomes a single point of failure for all of them.
Stolen credentials don't expire on their own. A password harvested in 2020 is still a working key in 2024 if nobody rotated it and no second factor stands behind it.
How the logins were tested
This is credential stuffing at small scale: take a list of known username/password pairs and try each one against the target service. UNC5537 used a custom tool Mandiant named FROSTBITE (.NET and Java versions, talking to Snowflake through its official drivers) for login checks and reconnaissance. It also used the publicly available DBeaver Ultimate client to connect and query. Traffic came through VPN services such as Mullvad and PIA, and data went to VPS hosts and MEGA storage.
How the data left, using normal SQL
Once logged in, the actor used ordinary Snowflake commands, the same ones a data engineer runs every day:
1. Recon: SHOW TABLES to list tables, and listing existing stages.
2. Stage: CREATE TEMPORARY STAGE in a database the account could write to.
3. Package: COPY INTO @stage FROM (SELECT * FROM db.schema.table) with GZIP-compressed CSV output and large file sizes, which turns a whole table into a few downloadable files.
4. Download: GET @stage file:///local/path to pull the files to the attacker's machine.
Nothing here is a vulnerability, so signature-based tools don't flag it. What stands out is behaviour: a login from a new location, followed within minutes by SHOW TABLES across many databases, a temporary stage, and multi-gigabyte COPY INTO and GET operations by a user who normally runs dashboards.
The three gaps Mandiant named
1. No MFA. A valid username and password were enough.
2. Stale credentials. Passwords stayed valid for years with no rotation.
3. No network allow lists. Accounts could be used from anywhere on the internet, not only from the company's networks or a known set of IPs.
Close any one of the three and most of these intrusions stop at step one.
What to do with your own data platforms
• Enforce MFA or key-pair / SSO-only authentication for every human user on warehouses, BI tools and admin consoles. Since this campaign, Snowflake has moved toward requiring MFA by default; check what your other platforms allow.
• Network policies: allow sign-in only from your VPN, office ranges or your integration hosts.
• Rotate and expire credentials, and remove accounts of contractors who have left.
• Watch infostealer exposure: commercial and free breach-monitoring feeds can tell you when your domain's credentials show up in stealer logs. Treat a hit as a compromise, not a warning.
• Alert on exfiltration patterns: new stages, large COPY INTO to stages, and GET from unfamiliar clients.
• Contractor device policy: if a contractor's own laptop can reach your production data, its hygiene is now your problem. Require managed devices or a hardened VDI for privileged access.
The broader point
Infostealer logs have made credential stuffing cheap and precise. Attackers no longer guess; they buy a list of passwords that worked on that exact service. Any login that is only a password is now a login with a known price. Removing the reusable password, through one-time codes, passkeys or SSO with MFA, is what takes you off that list.
osec.one gives your app or website one-time-code and Apple/Google logins without storing a password for anyone to steal.
Add passwordless login