UNC5537 (Snowflake customer data theft) threat actor profile: How stolen passwords emptied data warehouses, and defences

UNC5537 stole data from around 165 Snowflake customer environments in 2024 without exploiting a single vulnerability: it simply logged in with passwords that infostealer malware had harvested years earlier. Mandiant tracks the group as a financially motivated cluster that steals, sells and extorts with customer data. This profile sets out who the group is, what it targets, the ATT&CK techniques that describe its activity, how it abused human and service credentials, and the specific detection queries and hardening steps that would have stopped it. It is written for data platform owners, identity teams and threat intelligence analysts who run Snowflake or any other SaaS data platform reachable from the internet.

Key takeaways

• No exploit, just logins. Mandiant found no evidence that Snowflake's own enterprise environment was breached; every intrusion it investigated began with a valid username and password stolen by infostealer malware.
• Old credentials stayed live. At least 79.7% of the accounts used had prior credential exposure, the earliest infection dated to November 2020, and some credentials had gone unrotated for up to four years.
• Three missing controls did the damage. The affected accounts had no MFA, credentials that were never rotated, and no network allow lists restricting where logins could come from.
• The pattern in the logs is distinctive. Unusual client application IDs, VPN source addresses, and a run of SHOW TABLES, temporary stage creation, COPY INTO and GET commands are all visible in Snowflake's own account usage views.
• Service users are the lasting lesson. Password-only service and integration users are exactly what this actor needs; Snowflake is now phasing out password authentication for non-human users, and every SaaS data platform deserves the same treatment.

Who they are (names and aliases)

UNC5537 is Mandiant's (Google Threat Intelligence) designation for a financially motivated threat cluster it has tracked as a distinct group since May 2024. "UNC" marks an uncategorised cluster that has not been merged into a numbered group. Mandiant assesses with moderate confidence that members are based in North America and collaborate with at least one additional member in Turkey, and says the group operates under various aliases on Telegram channels and cybercrime forums and has links to other groups it tracks. Mandiant did not publish those aliases, so this page does not attempt to map UNC5537 to other vendors' names. As of ATT&CK v20, MITRE has no group or campaign entry for UNC5537.

United States prosecutors later charged individuals linked to the campaign; the legal outcomes are summarised on our Snowflake Breach 2024 analysis. For how vendor cluster names relate to each other, see the Threat Actor Naming Conventions Guide, and for the limits of attribution, the Cyber Threat Attribution Guide.

Targeting and motivation

The motive is money. Mandiant describes the group extorting victims directly and attempting to sell stolen data on cybercrime forums. It says UNC5537 has targeted hundreds of organisations worldwide, and that Mandiant and Snowflake notified around 165 potentially exposed organisations through Mandiant's victim notification programme.

Targeting was opportunistic rather than sector-led: the deciding factor was whether an infostealer log contained a working credential for a Snowflake account that lacked MFA. Mandiant highlighted contractors as a multiplier. In several investigations the original infection was on a contractor's system that was also used for gaming and pirated software, and because contractors often hold IT or administrative access to several customers, one infected laptop could open many organisations' data platforms.

Tactics and techniques (MITRE ATT&CK)

Mandiant's report lists no ATT&CK IDs. The mapping below is ours, made from the behaviour Mandiant documented and checked against ATT&CK v20. It covers the campaign end to end.

How they abuse identities and credentials

Every stage of this campaign depended on identity hygiene failures, not software flaws.

• Infostealer logs as an access broker: credentials taken from browsers on personal and contractor devices sat in criminal datasets for years. Mandiant notes that stolen credentials were already the fourth most common initial intrusion vector in its 2023 investigations. See the Infostealer Logs Monitoring and Response Guide.
• Password-only accounts: the impacted accounts needed only a username and password. Human accounts without MFA and service users authenticating with static passwords were treated the same by the attacker.
• No rotation: credentials remained valid long after the device that leaked them was infected. Rotation on exposure, not on a calendar, would have closed most of the doors.
• No network boundary: instances accepted logins from any address, so a VPN exit node in another country looked no different from an office.
• Shared and third-party access: contractor accounts carried administrative reach into multiple customers. See the Contractor Identity Lifecycle Guide.

The NHI angle matters most for the long term. Integration users for ETL, BI and reverse ETL tools are often created once with a password and forgotten. Snowflake's published rollout now blocks password authentication for non-human users: in the phase it schedules for August to October 2026, existing TYPE=LEGACY_SERVICE users are migrated to TYPE=SERVICE and non-human users can no longer sign in with a password (Snowflake describes the dates as estimates that roll out per account). See the Service Accounts in Snowflake Guide and How to find Snowflake service users without key-pair auth.

Notable incidents

• Snowflake customer campaign, April to June 2024: around 165 organisations notified; publicly disclosed victims include AT&T, Ticketmaster (Live Nation), Santander and Advance Auto Parts. Our full analysis is the Snowflake Breach 2024 page.
• AT&T call records: AT&T disclosed on 12 July 2024 that records were taken from its Snowflake workspace between 14 and 25 April 2024.
• Extortion and sale: Mandiant observed direct extortion and attempts to sell data on forums, with staging on international VPS providers and MEGA.

Detection and defence

Hunt in Snowflake's own telemetry

Snowflake's ACCOUNT_USAGE views keep 365 days of history, which is long enough to hunt back across the whole 2024 window. LOGIN_HISTORY can lag by up to two hours, so it suits hunting and scheduled alerting rather than real-time blocking.

Client version strings and IP addresses are weak indicators on their own because they are trivial to change and some are used legitimately. Treat them as hunting leads and rely on the authentication and behaviour signals for alerting. See the Snowflake Security Guide for wider logging.

Harden authentication and access

• MFA for every human user: enforce it at the identity provider through SSO, and prefer phishing-resistant factors. See the Phishing-Resistant MFA Guide.
• No passwords for non-human users: move service users to key-pair authentication or OAuth and set TYPE=SERVICE ahead of Snowflake's enforcement.
• Network policies: build network rules for corporate egress, private connectivity and known integration ranges, then activate a policy at account level, with tighter user-level or integration-level policies for service users. Snowflake applies the most specific level, so check that no user-level policy is looser than the account policy.
• Rotate on exposure: subscribe to infostealer log monitoring for your domains and rotate any credential that appears, then review that account's LOGIN_HISTORY for prior use.
• Contractor devices: require managed or virtualised access for contractors with data platform privileges, and give each contractor named accounts per customer, never shared ones.

Respond

1. Disable or reset the suspect user and revoke its active sessions, then rotate keys for any service users the same person administered.
2. Export LOGIN_HISTORY and QUERY_HISTORY for the user across the full 365-day window before anything ages out.
3. Identify every stage created and every GET issued, and list the tables copied to scope notification duties.
4. Check the source device: if an infostealer is suspected, treat every credential and session cookie on that device as stolen, not only the Snowflake one.
5. Prepare for extortion contact. See the Data Extortion Without Encryption Guide.

Metrics

• Percentage of Snowflake human users with MFA enforced (target 100%).
• Number of users of any type able to authenticate with a password alone (target zero).
• Percentage of accounts and service users covered by an active network policy.
• Median time from a credential appearing in infostealer monitoring to rotation.
• Number of logins from never-seen client applications or VPN ranges, each triaged within one business day.

Framework mapping

Practitioner checklist

• Query LOGIN_HISTORY for any successful password-only login in the last 365 days and list the users involved.
• Enforce MFA through SSO for every human Snowflake user and remove local passwords where SSO is in place.
• Move every service user to key-pair or OAuth authentication and set TYPE=SERVICE before Snowflake's enforcement reaches your account.
• Activate an account-level network policy and stricter policies for service users and integrations.
• Hunt QUERY_HISTORY for the SHOW TABLES, CREATE TEMPORARY STAGE, COPY INTO and GET sequence.
• Subscribe to infostealer log monitoring for your domains and rotate exposed credentials within 24 hours.
• Require named, managed-device access for contractors with data platform privileges.
• Repeat the same review for every other SaaS data platform that accepts password logins from the internet.

Standards and references

• Google Cloud (Mandiant): UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
• Snowflake: Planning for the deprecation of single-factor password sign-ins
• Snowflake: LOGIN_HISTORY view
• Snowflake: Controlling network traffic with network policies
• MITRE ATT&CK: Valid Accounts: Cloud Accounts
• MITRE ATT&CK: Data from Information Repositories: Databases
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Snowflake Breach 2024 · Service Accounts in Snowflake Guide · Infostealer Threat Guide · ShinyHunters Threat Actor Profile · Threat Actor Groups Guide