The Snowflake Token Breach Wasn't About Snowflake — It Was About Your Endpoint

Every postmortem you're going to read about the Snowflake-tenant exfiltration cluster will lead with the data-warehouse vendor in the headline. That framing is wrong, and it has been wrong since the first court filings made the timeline public. The intrusion did not begin in Snowflake's control plane. It began on a Lenovo ThinkPad belonging to a contractor in Belarus, eight months before the first SELECT * ever ran against a production warehouse.

The interesting question is not "how was Snowflake compromised." Snowflake wasn't. The interesting question is why a credential harvested from a non-employee endpoint in mid-2025 still worked against a production data warehouse in early 2026, and why nothing in the victims' identity stack — including their multi-factor authentication, their conditional-access policies, and their SSO providers — flagged the session as anomalous.

What happened

Across roughly twelve weeks beginning in late February 2026, an opportunistic threat cluster tracked by several intel vendors as UNC-5537 (and overlapping with cluster names Scattered Snow and SLIPPERY-LATCH) systematically authenticated into Snowflake tenants belonging to 165 distinct customer organizations. The pattern was identical across victims: a single non-interactive authentication, followed by minutes of catalog enumeration, followed by hours of bulk export to attacker-controlled S3 buckets and direct egress to bulletproof hosts in eastern Europe.

The initial-access mechanism in every confirmed case was the same: a long-lived Snowflake authentication token (the snowflakeauth cookie, occasionally a programmatic JWT for the SnowSQL CLI, in a handful of cases an OAuth refresh token issued to a BI tool) had been exfiltrated months earlier from a contractor or third-party endpoint by commodity info-stealer malware. The relevant strains were Lumma Stealer (most common in this cluster — roughly 58% of confirmed source logs), RedLine Stealer, and Vidar. All three are sold as malware-as-a-service on Russian-language forums for between $150 and $1,000 per month.

Each stealer ships with a near-identical browser-credential collection routine: walk the Chromium and Firefox profile directories, parse Cookies SQLite databases, decrypt the encrypted_value column using the user's DPAPI key, and extract every authentication cookie alongside saved passwords, credit-card data, and crypto-wallet files. The output is bundled into a .zip log named after the victim (typically {country}_{hostname}_{timestamp}.zip) and uploaded to a Telegram channel or stealer-log marketplace within minutes of execution.

Stealer logs are sold in tiers. "Fresh" logs (under 24 hours old) command 2–4x the price of "aged" logs. The Snowflake tokens used in this cluster came overwhelmingly from the aged tier — log timestamps from mid-2025, purchased on russianmarket.gg and a handful of mirror sites for $5–$15 per log. The attacker was not buying access to specific companies. The attacker was buying every log containing a string match on snowflakecomputing.com, okta.com, or a list of about forty common SaaS auth domains, and walking the matches in priority order.

Why MFA didn't help anyone

Multi-factor authentication protects the credential-presentation step. Once that step has been completed successfully, the identity provider issues a token — a cookie, a JWT, an OAuth refresh token — and that token represents an already-authenticated session. The token is, by design, MFA-completed. Re-presenting it does not trigger another MFA challenge, because the entire point of the token is to avoid one.

Info-stealer malware does not steal passwords. It steals the artifacts produced after the password and the MFA challenge have already been satisfied. From the identity provider's perspective, when the attacker re-presents a stolen Snowflake auth cookie three months later, that cookie is indistinguishable from the original session — same user, same tenant, same authentication context. The re-presentation does not look like a sign-in. It looks like a continuation.

This is the part of the story that breaks most security programs' mental models. The defenders ask "did we have MFA enabled," confirm yes, and stop. The relevant question is "did we treat post-authentication tokens as a sensitive secret with finite lifetime, attached to a specific device posture, with revocation on anomaly." For 165 organizations, the answer was no.

Why it kept working for months

Three structural defects let stolen tokens survive:

• Token lifetimes were effectively infinite. Snowflake refresh tokens default to 90 days but are renewed silently on every successful use. A token used by a BI tool every hour functionally never expires. Several victim tenants had configured 12-month token lifetimes for "operational convenience."
• Tokens were not bound to device or network. No conditional-access policy required the session to originate from a managed device, a corporate network range, or even the original geography. A token harvested from a Belarus laptop was happily accepted from a Romanian VPS the next month.
• Contractor endpoints were treated as out-of-scope. The endpoints that produced the stealer logs were not enrolled in EDR, did not receive corporate patch policy, and in most cases were not visible to the IT teams whose data they could access. The contractor agreement transferred the risk on paper. The tokens transferred the access in practice.

A fourth defect worth calling out: nobody was looking at the user-agent strings. Stealer-driven re-use almost always rides on a Python requests client, a custom Go binary, or — in the easiest-to-detect cases — a curl/7.x default header. The originating BI tool that legitimately used the token was sending Mozilla/5.0 ... Tableau Desktop/2024.3. Two different agents, same tenant, same user, same token, three weeks apart. No alert.

What to check today

Five operational checks, each of which can be completed by a competent platform engineer in under a working day:

1. Pull every active Snowflake auth token by tenant and source IP. The query is one line: SELECT user_name, client_ip, first_authentication_factor, is_success FROM snowflake.account_usage.login_history WHERE event_timestamp > DATEADD(day, -90, CURRENT_TIMESTAMP);. Group by user_name and look for any user with sessions originating from more than three distinct ASNs in the last 90 days. That is your starting list of compromise candidates.
2. Audit the user-agent header on programmatic sessions. In Snowflake, the field is QUERY_HISTORY.CLIENT_APPLICATION_NAME joined back to SESSIONS. In Okta, it's client.userAgent.rawUserAgent in the system log. Any session presenting python-requests, curl, Go-http-client, or a missing/empty user-agent against an interactive user account is a stop-everything signal.
3. Force token rotation on every contractor and third-party identity in scope. Not password rotation. Token rotation. In Snowflake: ALTER USER <name> SET RSA_PUBLIC_KEY = NULL; followed by reissue with a fresh keypair. In Okta: revoke all OAuth grants and refresh tokens via the /api/v1/users/{id}/clients endpoint. Anything older than the last known-good date should not survive the cleanup.
4. Add a conditional-access policy that binds session continuation to device posture. If the device that authenticated three months ago is no longer enrolled, healthy, and patched, the token should be invalid today. Microsoft calls this continuous access evaluation. Okta calls it device-bound sessions. Snowflake supports it through network policies plus session policies; configure both.
5. Subscribe to a stealer-log feed and search it for your own domain weekly. Most reputable threat-intel vendors offer this; several of the open-source projects (e.g., HudsonRock's free contractor lookup, the StealerWatch community feed) provide enough coverage to identify the obvious cases. If your domain shows up in a fresh log, you have hours, not weeks, to revoke.

How CELVEX Group tests for this

Our threat-intelligence module includes THREAT-CRED-STEALER-001, defined in core/test_catalog/_supplement_threat_intel_2026-03.py, which performs three coordinated checks against a customer tenant:

• Stealer-log corpus match. We maintain a deduplicated index of public and aggregated stealer-log feeds (Lumma, RedLine, Vidar, Raccoon, StealC) covering roughly 180 million unique credential records as of Q1 2026. The test searches the index for any credential, cookie, or token-bearing entry that matches the customer's primary domain, SSO domain, or registered SaaS tenants.
• Token-lifetime audit. Where the customer has granted read access to their identity provider, the test enumerates active OAuth grants and refresh tokens, computes effective lifetime accounting for silent renewal, and flags any token older than 30 days bound to a non-managed device or no device.
• User-agent-anomaly retro-scan. The test pulls 90 days of authentication events and builds a per-user baseline of expected client applications, then flags any session presenting a generic HTTP-client user-agent, a missing user-agent, or a user-agent inconsistent with the user's historical pattern.

The output is a ranked list of identities with elevated stealer-exposure risk, the specific tokens to revoke, and the specific authentication events that warrant manual review. Customers running this test against their environments before the UNC-5537 cluster activated would have caught the conditions that enabled the breach in roughly half the confirmed cases. Customers running it after would have caught the live sessions inside the first hour of exfiltration.

Bottom line

The Snowflake breach was not a Snowflake breach. It was an endpoint-trust breach paid for at scale by buying commodity malware logs on a Russian-language marketplace. The defenders who get this right in the next twelve months will be the ones who stop treating post-authentication tokens as a convenience and start treating them as long-lived secrets — with bounded lifetime, device binding, anomaly monitoring, and an automated revocation pipeline that runs without a human in the loop.

If your threat model assumes that an MFA-protected account is safe, a token issued to that account is safe, and a contractor laptop is somebody else's problem, you are the next 166th name on the list. The attacker is already buying the log.