In April 2024, Mandiant discovered that someone had logged into the Snowflake instances of over 165 companies, not through an exploit or a zero-day vulnerability but simply with usernames and passwords. The credentials originated from infostealers that had been running on contractor devices in some cases since 2020, and the result was one of the largest cloud data losses in recent history.
The infostealer pipeline
The group that Mandiant tracks as UNC5537 pursued a remarkably straightforward strategy: rather than hacking into systems themselves, they purchased ready-made credentials on the black market. At the time, millions of credentials were circulating there, harvested over years by malware families such as VIDAR, REDLINE, LUMMA, RISEPRO, RACOON STEALER and METASTEALER from browser password stores.
The underlying problem was not primarily the corporate devices themselves but rather personal laptops and contractor machines on which employees had logged into Snowflake through their browsers. A contractor laptop infected with Vidar malware that had been siphoning credentials since November 2020, and three years later someone used those exact credentials to access AT&T, Ticketmaster or Santander Bank.
79.7 percent of the compromised accounts had prior credential exposure, meaning the credentials had been in circulation for years, were never changed, and had no MFA enabled.
How UNC5537 operated
The attackers used a custom reconnaissance tool called FROSTBITE (a .NET and Java application) to map Snowflake instances, followed by DBeaver Ultimate for the actual SQL queries. The methodology was systematic and consistent across targets:
First SHOW TABLES to understand the database structure. Then SELECT * to survey the data. Then CREATE TEMPORARY STAGE to set up a temporary storage area within Snowflake. COPY INTO with GZIP compression to package the data into that stage. And finally GET to download everything to local systems, from where it was uploaded to MEGA cloud storage.
The entire infrastructure was designed for anonymity, with Mullvad and PIA as VPN services, VPS servers at ALEXHOST SRL in Moldova, and MEGA for storage. The attackers operated no infrastructure of their own and relied entirely on rented and anonymous services.
The scale
The dimensions of this incident were extraordinary even by the standards of major data breaches: 560 million customer records at Ticketmaster, 110 million at AT&T, 30 million at Santander Bank. In total, at least 165 organizations were notified that their Snowflake data had been compromised.
The timeline adds further context: the earliest infostealer infections date back to November 2020, which means the credentials were openly accessible for over three years, were never rotated, and nobody had activated MFA. In April 2024 the first compromises were discovered, on May 22 Mandiant contacted Snowflake, and on June 10 the public disclosure was issued.
In October 2024, Alexander “Connor” Moucka was arrested in Canada. John Binns had already been detained in Turkey in May 2024.
Attack path and controls
What makes this case particularly notable from a security perspective is that Snowflake as a platform was never hacked, and there was no vulnerability in the product. The attackers logged in with valid usernames and passwords because customers had not enabled MFA, had never rotated passwords, and had not configured IP allow lists, despite these three baseline measures being part of the standard repertoire of any cloud security configuration.
Step 1: Infostealer infection
Malware such as Vidar, Redline or LummaC2 reaches contractor or personal devices and steals credentials from browsers. EDR and application control on all devices, including those of contractors, would have prevented the infection or at least detected it.
Step 2: Credential harvesting
Stolen Snowflake logins end up on the black market. Password managers instead of browser-based storage reduce the attack surface considerably, because infostealers typically read browser databases rather than the vault of a dedicated password manager.
Step 3: Snowflake login without MFA
The attackers logged in with the stolen credentials, with 79.7 percent of affected accounts having no MFA enabled. Mandatory MFA and IP allow lists would have blocked access even with valid credentials.
Step 4: Reconnaissance with FROSTBITE
Databases and tables are enumerated, SQL queries executed via DBeaver. Anomaly detection and session monitoring would have identified the unusual access patterns: a new device, a new IP address, atypical query patterns.
Step 5: Data staging
The data is copied into temporary stages using COPY INTO with GZIP compression. DLP policies and query auditing can detect when someone copies entire tables into a stage, as this does not represent normal usage behavior.
Step 6: Exfiltration
The GET command downloads the data to local systems, after which it is uploaded to MEGA. Egress filtering and data classification set limits on the volume of data that may leave a Snowflake instance.
Conclusion
This case illustrates how seemingly minor oversights can cascade into large-scale incidents. None of the 165 affected customers had all three baseline measures (MFA, password rotation, IP restrictions) active, and while Snowflake has since made MFA mandatory for all new accounts, this came too late for the existing customer base.
The fundamental problem that this incident exposes concerns infostealer malware on the devices of third-party vendors and contractors, a blind spot that most organizations do not have on their radar. With credentials that had been in circulation since 2020 and were never rotated, the attackers did not need a sophisticated exploit but merely a simple login attempt with credentials that had been freely available for years..
Want to know whether your cloud access is securely configured? Get in touch for a no-obligation assessment.
Sources
Mandiant: UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
Wired: The Snowflake Breach Keeps Getting Worse
Krebs on Security: Snowflake Hacking Suspect Arrested in Canada