Attackers Logged Into Snowflake Customer Environments With Working Credentials

From April 2024 a campaign tracked as UNC5537 reached more than 165 organisations’ Snowflake tenants. The method was to log in. The credentials were valid, they had been stolen from employee machines by infostealer malware, and the accounts they belonged to did not have multi-factor authentication enforced.

No flaw in Snowflake’s platform was exploited. The vendor said so, the responders who worked the cases said so, and no CVE was ever issued, because there was nothing to issue one against.

A managed data platform authenticates whoever presents a valid credential for a customer tenant. Whether that tenant requires a second factor was, at the time, the customer’s setting to make.

So the platform behaved correctly at every step and 165 organisations lost data anyway. This corpus files that under the concentration theme: the failure sat in a configuration nobody in the affected population could see, on a service most of them had never heard of.

Reporting on the campaign found that the majority came from historical infostealer infections, some dating back as far as 2020. They had been sitting in log dumps for years.

That is the part defenders should sit with. The exposure was not created in 2024; it was created whenever an employee’s personal machine was infected, and it stayed live because nothing had ever forced a rotation or a second factor on those accounts.

This desk recorded at 25-0421b that it over-covers exploitation because a named CVE generates advisories and documentation while a stolen password generates nothing. The Snowflake campaign is the counter-example that proves the point: enormous, entirely credential-driven, and with no vulnerability to index it under.

It is in this database because the victims were large and named. A campaign of the same shape against 165 small firms would have left almost no trace at all.