Snowflake Customer Breaches (May–June 2024): Stolen Credentials, No MFA, 165 Companies

Retrospective: this article looks back at events from June 2024, written in 2026 with the benefit of hindsight.

Between April and June 2024, a financially motivated threat actor that Mandiant tracks as UNC5537 stole data from the Snowflake accounts of roughly 165 organizations. Victims included Ticketmaster and Live Nation, AT&T, Santander, Advance Auto Parts, Neiman Marcus and others. Stolen data was advertised on cybercrime forums, and victims were extorted.

1. Infostealer infectionsCredentials for Snowflake accounts are harvested by infostealer malware on non-Snowflake systems, in some cases as far back as 2020.
2. No MFA, no network policyAffected accounts lack multi-factor authentication and network allow lists; many passwords hadn't been rotated in years.
3. Login and queryUNC5537 logs in with valid credentials, runs reconnaissance queries and exports large datasets.
4. ExtortionStolen data is advertised on cybercrime forums and victims are pressured to pay.
5. Notification waveAbout 165 organizations are notified of potential exposure, including Ticketmaster, AT&T and Santander.

Mandiant and Snowflake were clear on one point: there was no evidence that Snowflake's own enterprise environment was breached. The attackers logged in to customer accounts with valid usernames and passwords. The accounts simply didn't require anything more.

What happened

According to Mandiant's investigation:

• The credentials came primarily from infostealer malware campaigns that infected systems not owned by Snowflake — often contractors' or employees' personal or unmanaged devices. Some infections dated back to 2020.
• The affected Snowflake customer accounts did not require multi-factor authentication.
• In many cases, the credentials hadn't been rotated in as long as four years.
• Network allow lists were not used to limit access to trusted locations.

With valid credentials, UNC5537 signed in, ran reconnaissance queries to understand what data existed, then exported large datasets. The actor then attempted extortion, and some victims reportedly paid to have stolen data deleted.

Why it mattered

Shared responsibility, in practice. Snowflake offered MFA and network policies. Customers that didn't use them carried the consequences — legally, financially and reputationally. The same split applies to every SaaS platform you use, from data warehouses to CRM to HR systems.

Infostealers are a credential supply chain. Malware on a single unmanaged laptop can leak credentials for every service the user ever saved in a browser. Those credentials are sold and resold for years.

Data platforms concentrate risk. A data warehouse may hold an organization's entire customer history in one place. Password-only access to that is a single point of failure.

Old credentials don't expire on their own. Passwords leaked in 2020 still worked in 2024 because nobody changed them.

What Snowflake changed

After the campaign, Snowflake added stronger controls, including the ability for administrators to require MFA for all users in an account, and moved toward MFA by default and blocking password-only sign-in for human users. Those changes help — but only for customers who adopt them, and only on that one platform.

What to do now

1. Inventory SaaS platforms that hold sensitive data. Data warehouses and analytics tools (Snowflake, Databricks, BigQuery), CRM, HR, finance and file-sharing platforms. Use Defender for Cloud Apps discovery and expense reports to find shadow SaaS.
2. Put every human sign-in behind your identity provider. Configure SSO with Entra ID (SAML or OIDC) and apply Conditional Access requiring MFA — phishing-resistant for administrators — and compliant devices for the most sensitive platforms.
3. Disable local passwords for people. Once SSO works, turn off password-based sign-in for human users on the SaaS platform itself. Keep one break-glass local admin with strong MFA, stored securely.
4. Handle service accounts deliberately. Integration and service accounts often can't use SSO. Use key-pair or OAuth authentication instead of passwords, restrict them to known IP ranges, store credentials in a vault and rotate them.
5. Use network policies. Restrict access to corporate IP ranges or private connectivity where the platform supports it.
6. Provision and deprovision automatically. SCIM provisioning from Entra ID removes access when people leave.
7. Require managed devices for access to sensitive SaaS. Infostealers thrive on personal and contractor devices.
8. Monitor for credential exposure. Subscribe to threat intelligence that reports your domains in infostealer logs, and force resets when they appear.

How to detect SaaS account takeover

• Password sign-ins where SSO should be used. In Snowflake, the LOGIN_HISTORY view shows the first and second authentication factors for each login; password logins with no second factor are an immediate red flag.
• New client IP addresses, especially VPS providers and anonymizing services.
• Dormant accounts suddenly active.
• Large exports. Review query history for unusually large SELECT or COPY INTO operations, particularly shortly after a new login.
• New users, roles or keys created outside your normal change process.
• Centralize the logs. Stream SaaS audit logs into Microsoft Sentinel or your SIEM so you can correlate them with identity and endpoint data.

Common mistakes

• "The vendor handles security." The vendor secures its platform; who can log in is your responsibility.
• SSO for some users. Attackers look for the one account that still signs in with a password.
• Never rotating service credentials. Integration passwords set up years ago are often still valid.
• Ignoring contractors. Contractor devices were a significant source of stolen credentials in this campaign.

Beyond Snowflake

The same pattern — valid credentials, no MFA, no network restrictions — applies to every SaaS platform. In 2025, attackers used stolen OAuth tokens from a sales chatbot integration to export data from hundreds of Salesforce instances, bypassing user sign-in controls entirely. Both campaigns show that SaaS security depends on how customers configure access, not just on the provider's platform security.

Questions for leadership

• Which SaaS platforms hold our customer data, and does every one require sign-in through our identity provider with MFA?
• How many service accounts have passwords that never change?
• Would we notice if someone exported our entire customer database tonight?

Key takeaways

• About 165 organizations' Snowflake accounts were accessed with stolen credentials; Snowflake itself wasn't breached.
• Missing MFA, missing network allow lists and years-old passwords made the attack possible.
• Infostealer malware on unmanaged devices is a major source of SaaS credentials.
• Enforce SSO and MFA, disable local passwords for people, and monitor for bulk exports on every SaaS platform.