When hundreds of millions of sensitive records from massive telecom giants, ticketing monopolies, and international banks simultaneously hit the dark web, the security community collectively held its breath. The common denominator between over 165 breached organizations was a single cloud data warehouse provider: Snowflake.
However, as the dust settled and incident responders from Mandiant published their post-mortem on the threat actor dubbed UNC5537, a terrifying realization emerged. Snowflake itself was never breached. There was no zero-day vulnerability, no complex supply chain compromise, and no elite persistent threat bypassing layered defense-in-depth architecture.
Instead, attackers systematically walked through the front door using valid passwords stolen years prior, exploiting customer environments that wholly ignored basic identity guardrails. It is one of the most catastrophic failures of the cloud shared responsibility model in recent memory.
The Anatomy of the UNC5537 Campaign
The mechanics of this campaign are startlingly simple. UNC5537 is a financially motivated threat cluster that realized modern enterprises have a massive blind spot: stale cloud credentials.
For years, infostealer malware (like Redline, Raccoon, and Vidar) has been infecting employee endpoints, quietly siphoning passwords, session tokens, and browser autofill data. In many of the Snowflake compromises, the initial credential theft occurred as far back as 2020. An employee might have downloaded a pirated software package or malicious browser extension on their personal, unmanaged machine that they occasionally used to check work emails or run a quick SQL query.
UNC5537 aggregated these massive dumps of stolen credentials and began aggressively stuffing them against Snowflake customer login portals.
The attack path utilized by UNC5537, moving from infostealer compromise on an unmanaged endpoint directly to cloud data exfiltration.
Once authenticated, the attackers bypassed typical Cloud Reconnaissance hurdles. They did not need to escalate privileges or move laterally. They simply connected to the databases using native Snowflake clients or custom DBeaver setups, executed basic SQL SELECT * statements, and piped terabytes of highly sensitive customer data out to their own infrastructure. Following the exfiltration, they attempted to extort the victim organizations, demanding massive crypto payments to prevent the public release of the data.
Why This Matters (And Why It Is Infuriating)
The defining characteristic of every single successful compromise in this campaign was the total absence of Multi-Factor Authentication (MFA).
In 2024, deploying a massive, internet-facing data warehouse containing the crown jewels of an enterprise without enforcing MFA is cybersecurity negligence. The attackers did not steal MFA session tokens (a significantly harder tactic known as adversary-in-the-middle or AiTM). They simply typed in the username and password and hit enter.
Furthermore, many of these organizations failed to implement network allow-listing. Snowflake, by default, allows connections from any IP address on the internet unless explicitly restricted. By combining valid, single-factor credentials with a completely open network policy, organizations essentially left the vault door wide open and unguarded.
The fallout highlights a grim reality for defenders: you cannot assume that SaaS providers enforce security by default. In the cloud shared responsibility model, the provider is responsible for the security of the cloud, but the customer is solely responsible for security in the cloud. When configurations are left to default, the customer assumes all the risk.
Actionable Steps for Defenders
If your organization utilizes Snowflake or any similar massive cloud data warehousing solution, you must proactively hunt for these misconfigurations and enforce strict identity perimeter controls.
1. Mandate Multi-Factor Authentication (MFA) Everywhere
Relying on users to optionally enroll in MFA is a recipe for disaster. You must enforce it universally across all users, especially service accounts. In Snowflake, you can use the MINS_TO_BYPASS_MFA parameter or integrate deeply with an external Identity Provider (IdP) like Okta or Entra ID, ensuring that all authentication flows through a robust conditional access policy.
Here is a Python script using the Snowflake connector to quickly audit your environment and flag any users who have not enrolled in MFA. This script requires authorized ACCOUNTADMIN access.
import snowflake.connector import os # Connect to Snowflake (Authorized Admin Context) conn = snowflake.connector.connect( user=os.getenv("SF_USER"), password=os.getenv("SF_PASSWORD"), account=
2. Implement Strict Network Policies
If your data warehouse only needs to be accessed by internal corporate IP addresses, a specific AWS VPC, or your BI tool's static IP range, you must enforce a Network Policy. Do not leave the service open to the public internet.
Below is an example of how to implement a restrictive network policy using Terraform to ensure your Snowflake instance explicitly blocks unknown traffic.
# Terraform configuration to enforce Snowflake Network Policies resource "snowflake_network_policy" "strict_access" { name = "STRICT_CORP_ACCESS" comment = "Only allow traffic from corporate VPN and trusted VPCs" # Allowed IP ranges (Corporate NAT IP, AWS NAT Gateway) allowed_ip_list = ["198.51.100.14/32", "203.0.113.50/32"] # Block all other traffic implicitly } # Attach the policy globally to the entire account resource "snowflake_account" "main" { network_policy = snowflake_network_policy.strict_access.name }
3. Hunt for Stale Accounts and Infostealer Traces
The initial access vector for UNC5537 was stale credentials floating in infostealer logs. Defenders should actively monitor dark web intelligence feeds (like HaveIBeenPwned or commercial CTI vendors) for corporate email addresses appearing in stealer logs. Furthermore, actively audit and disable accounts that have not logged in for over 30 days. Service accounts that are no longer actively used by applications should be aggressively decommissioned. If you find anomalies in service account usage, it is often a precursor to Active Directory Exploitation.
Ethics and Scope Reminder
The scripts and methodologies discussed here are for defensive auditing and authorized cloud architecture reviews. Never attempt to authenticate to a third-party cloud instance or run user enumeration scripts against infrastructure you do not explicitly own or have written authorization to test.
A Wake-Up Call for SaaS
The UNC5537 campaign is not a story of sophisticated hackers breaking unbreakable cryptography. It is a story of opportunistic thieves finding an unlocked door in a wealthy neighborhood.
As enterprises continue to migrate highly sensitive, aggregated data lakes into the cloud, the foundational rules of identity access management cannot be treated as optional checkboxes. Stolen passwords are the most abundant commodity on the cybercriminal underground. If a single password is the only thing standing between an attacker and your entire customer database, it is not a matter of if you will be breached, but when.
Related Blogs
- Mastering Cloud Reconnaissance Methodology
- OAuth & OIDC Exploitation Methodology
- Active Directory Exploitation Methodology
- Modern API Hacking: BOLA Methodology
References / Further Reading
- UNC5537 Targets Snowflake Customer Environments. Mandiant. https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft/
- Snowflake Security and Trust Center. Snowflake. https://www.snowflake.com/en/company/trust-center/
- How to Prevent Credential Stuffing Attacks. OWASP. https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html
- The Role of Infostealers in Modern Breaches. CISA. https://www.cisa.gov/news-events/cybersecurity-advisories
