In 2024, a threat actor tracked as UNC5537 used credentials stolen by infostealer malware to log into an estimated 165 Snowflake customer accounts that lacked multifactor authentication, according to Mandiant's Victim Notification Program, then exfiltrated bulk data and attempted extortion — hitting organisations including Ticketmaster and Santander among the reported victims. Snowflake itself was not breached; Mandiant and Google's investigation found no compromise of Snowflake's own platform. The root cause was simpler and far more common: customer accounts protected by a username and password alone, reachable from the internet, with credentials that had already leaked through malware on an employee's or contractor's device. For any Indian company running workloads on a shared SaaS or cloud data platform, this is the exact failure mode to check for today, not a distant enterprise story.
What Actually Happened in the Snowflake Customer Breach Wave
Snowflake is a cloud data warehousing platform used by thousands of enterprises to store and analyse large volumes of customer, transaction, and operational data. Starting around April 2024, Mandiant — the incident response arm engaged by Google Cloud, which also owns Snowflake's platform — began investigating a wave of intrusions affecting multiple Snowflake customer accounts. The pattern across victims was consistent: attackers used valid credentials, not a software exploit, to log in directly.
Mandiant attributed the campaign to a financially motivated actor it tracks as UNC5537, and found the credentials used had largely been harvested over time by infostealer malware — a category of malware designed to silently scrape saved passwords, session tokens, and browser autofill data from infected machines, then sell or trade that data on criminal marketplaces. Many of the compromised credentials were reportedly years old, taken from machines infected long before the attack campaign, which meant password rotation alone would not have closed the gap in accounts that never enforced MFA.
Why No MFA Turned Stolen Passwords Into Full Account Takeover
A stolen password is a serious problem, but on its own it is rarely sufficient for an attacker to walk straight into a production data warehouse. MFA is the control specifically designed to stop exactly this scenario — a second factor the attacker does not possess, even with a valid password in hand. In the Snowflake campaign, the accounts UNC5537 successfully accessed shared two things: valid leaked credentials, and no MFA requirement blocking login with just those credentials.
Once inside, the reported technique was not subtle: attackers ran large export queries against customer tables, pulling data out at volume, then used the fact of possession as leverage — contacting victims or their customers with extortion demands, and in some cases advertising stolen data for sale. Reporting on the campaign, including Mandiant's own published findings, described roughly 165 accounts as targeted through its Victim Notification Program, with a smaller subset confirmed to have data actually stolen and monetised. This report does not restate specific per-company record counts (such as figures reported for individual victims) as fact, because those numbers were reported by third parties and varied by tracker — the structural lesson holds regardless of the exact figure.
Root Cause Distribution: Why This Keeps Happening
The pattern in this campaign is not unique to Snowflake as a product — it is a recurring root cause across SaaS and cloud data breaches generally, and it maps closely to what incident responders report seeing year over year.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanSnowflake's Response and the Shared-Responsibility Model
Following disclosure, Snowflake announced it would begin requiring or strongly pushing customers toward multifactor authentication and network policy controls, and published guidance urging all customers to enable MFA, rotate credentials, and restrict network access immediately. That response itself is instructive: the fix was not a platform patch, because there was no platform vulnerability to patch. The fix was a configuration change available to every customer the entire time, that most affected customers simply had not turned on.
This is the shared-responsibility model that governs virtually every SaaS and IaaS platform, cloud data warehouse included. The vendor is responsible for the security of the platform itself — patching, infrastructure hardening, availability. The customer is responsible for how they configure access to their own instance: who can log in, under what conditions, with what verification. Snowflake provided MFA and network policy features before this campaign; it did not mandate them by default for every account. That gap between "available" and "enforced" is where UNC5537 operated.
| Responsibility | Who Owns It | What Failed in This Campaign |
|---|---|---|
| Platform infrastructure security | Vendor (Snowflake) | Not implicated — no platform-level compromise found |
| Enforcing MFA on user accounts | Customer | Not enforced on affected accounts |
| Network/IP allowlisting for login | Customer | Frequently absent, allowing global login attempts |
| Credential hygiene and rotation | Customer and its workforce | Old, infostealer-harvested credentials remained valid |
| Endpoint protection against infostealers | Customer | Infected endpoints were the original source of leaked credentials |
| Monitoring for anomalous bulk exports | Customer | Large export queries reportedly went undetected until after the fact |
Infostealer Malware Is the Upstream Problem
It is worth separating the two failures that compounded into this campaign, because they require different defences. The first is that infostealer malware — commodity malware sold cheaply on criminal forums — successfully infected devices belonging to employees or contractors with access to Snowflake credentials, in some cases long before the attack campaign began. The second is that when those credentials leaked, no second factor stood between the attacker and the account.
Defending against the upstream infostealer problem means endpoint detection on any device that touches production credentials, restricting personal devices and unmanaged browsers from storing corporate SaaS logins, and treating "credential exposed in an infostealer log" as an active incident requiring immediate rotation — not a low-priority alert. None of this is exotic; it is baseline credential hygiene that becomes urgent the moment any employee device could plausibly be compromised, which in practice is always.
Why This Matters for Indian SaaS and Cloud Data Users
India's SaaS, fintech, and IT services sectors run heavily on exactly this kind of shared cloud data infrastructure — data warehouses, CRM platforms, analytics tools — accessed by distributed teams, contractors, and sometimes offshore partners, often from personal or lightly managed devices. The Snowflake campaign's lesson transfers directly: the platform being reputable and well-engineered does not protect an account that has no MFA and no network restriction, regardless of which vendor's logo is on the login page.
Under India's Digital Personal Data Protection (DPDP) Act, 2023, a Data Fiduciary is required to implement reasonable security safeguards to prevent personal data breaches and must notify affected individuals and the Data Protection Board when one occurs — an obligation that does not shift to the SaaS vendor simply because the platform itself was not at fault. If an Indian firm's customer data sits in a cloud warehouse account without MFA and that account is compromised using leaked credentials, the accountability for the resulting breach sits with the firm, not with the platform provider.
A Practical MFA and Access Checklist
- Enforce MFA on every account with access to production data, with no exceptions for service or admin accounts
- Apply network policies or IP allowlisting so credentials alone are never sufficient to log in from an untrusted network
- Rotate credentials immediately for any account flagged in a known infostealer or credential-leak dataset
- Deploy endpoint protection capable of detecting infostealer behaviour on any device with access to sensitive SaaS platforms
- Monitor for anomalous bulk export or query volume as a detection signal, not just a login-failure alert
- Review contractor and third-party access separately, since these accounts are frequently the least monitored and most likely to run on unmanaged devices
An independent VAPT engagement can surface exactly this class of gap — accounts and integrations with weak or absent authentication controls — before an attacker using leaked credentials finds it first. Bachao.AI, built by Dhisattva AI Pvt Ltd, runs automated vulnerability assessment and penetration testing for Indian SMBs and mid-market firms to catch misconfigurations like missing MFA across cloud and SaaS environments. Start with a free VAPT scan, review breach-notification obligations under the DPDP compliance guide, and read more incident breakdowns on the blog.
Sources and Further Reading
- Mandiant (Google Cloud), UNC5537 Targets Snowflake Customer Instances For Data Theft and Extortion
- CISA, Advisory: Snowflake Customer Data Breaches