Threat landscape

The 2024 UNC5537 campaign and post-incident hardening.

UNC5537 — The defining incident (May–June 2024)

UNC5537 is a financially motivated cluster tracked by Mandiant that systematically compromised Snowflake customer tenants using credentials harvested from infostealer logs, in some cases dating back to 2020. Mandiant and Snowflake notified a large cohort of affected customer organizations. Confirmed victims include AT&T, Ticketmaster/Live Nation, Santander, LendingTree, Advance Auto Parts, Neiman Marcus, and Bausch Health.

The campaign used a custom reconnaissance utility named FROSTBITE to enumerate users, roles, current IP, session IDs, and organization names via SQL, then bulk-exfiltrated with COPY INTO @<external_stage> to attacker-controlled S3.

Control gap	Why it mattered	Current Snowflake default (2026)
No MFA	The harvested credential alone was sufficient to authenticate. Snowflake did not require MFA by default at the time.	MFA enforced for all human users on new accounts (Oct 2024); mandatory for all human logins since April 2025.
Credentials not rotated	Infostealer logs from 2020 still worked in 2024 — credentials had never been rotated.	No automatic rotation enforcement; still a customer responsibility.
No network policy	Logins were accepted from any IP, including attacker infrastructure.	Trust Center flags accounts without a network policy; enforcement is still opt-in.

The three-gap pattern (no MFA, stale credentials, no network policy) has not been eliminated by the platform changes — it has been made harder to fall into. Older accounts that predate the October 2024 defaults, service users exempt from the human-user MFA rollout, and key-pair users without network policies remain at risk unless administrators actively configure them.

Post-2024 platform hardening — what changed

Date	Change	Assessment implication
July 2024	Account admins can now enforce mandatory MFA account-wide.	Assess whether customers have actually toggled this on, not just whether the control exists.
Oct 2024	MFA on by default for human users in new accounts.	Pre-Oct-2024 accounts retain the old default unless remediated.
Apr 2025	Single-factor password sign-ins blocked for all human users.	Service users (key-pair, OAuth) are still exempt — and those are now the softer targets.
2025	Trust Center GA — Security Essentials scanner flags MFA gaps and missing network policies.	Trust Center findings should feed the SOC, not just admin dashboards.
2025–2026	Cortex AI Guardrails in Horizon Catalog (prompt injection / jailbreak filter).	CVE-2026-6442 post-dates the guardrails announcement; CLI-level command validation and guardrails are separate controls.

Threat actor profile — 2026 Snowflake assessment

The realistic 2026 attacker against an enterprise Snowflake deployment is one or more of:

Credential-access operator: purchases infostealer logs; validates credentials at scale against Snowflake login endpoints; operates opportunistically against any tenant missing MFA or network controls. UNC5537 is the prototype.
Supply-chain attacker: targets the Native Apps Marketplace provider ecosystem. A compromised provider with a popular app can push a malicious update to consumer tenants without re-consent.
AI-aware attacker: plants indirect prompt injection in public content to steer Cortex Code or Cortex Agents into exfiltrating data or modifying credentials. CVE-2026-6442 is the first public example.
Cloud-identity pivoting actor: uses a compromised Entra/Okta tenant to forge SAML assertions or OIDC tokens for high-privileged Snowflake users, bypassing Snowflake-side MFA if the federation trust is not scoped to MFA-verified sessions.
Insider / misconfigured developer: exfiltrates through over-privileged Storage Integrations or External Functions that were correctly authorized for a narrow use case but bound to an over-broad IAM role.

Authentication surface

Post-April-2025, single-factor password sign-ins are blocked for human users — which moves the practical attack surface onto non-human credentials and federated sessions. The table below summarizes the live authentication channels and the red-team-relevant gaps for each.

Mechanism	Status (2026)	Attack surface
Password (single-factor)	Blocked for humans (April 2025)	Legacy service users may still allow it; reconnaissance should test before assuming closed.
Password + MFA	Default for human users	MFA fatigue, push bombing, Duo cache replay — same surface as any MFA-protected SaaS.
Key-pair (RSA)	Standard for service users	Private keys land in `~/.snowsql/`, CI runners, dbt profiles, Airflow connections — these are the soft credential exfil targets in a hardened tenant. Network policies on key-pair users are still opt-in.
OAuth (Snowflake-native)	For tool integrations	OAuth client-secret exfil; refresh-token replay; consent phishing against the OAuth flow.
External OAuth (Entra/Okta/Ping)	Federation for end users	Token audience confusion; Golden SAML on the IdP side; federated-path network policies often less restrictive than direct-login policies.
SAML SSO	For end users	Standard SAML-assertion forgery applies; classic Golden SAML is the prototype.
SCIM provisioning	Okta/Entra → Snowflake user/role sync	SCIM bearer-token theft from the IdP side grants user-creation and group-grant manipulation. Race conditions during group sync can briefly grant elevated grants. The SCIM token is typically stored in IdP admin metadata — assessable as part of the IdP review, not the Snowflake review.
Programmatic Access Tokens (PATs)	GA 2024/2025	Long-lived bearer tokens scoped to a specific role and (optionally) a specific network policy. Discovery and rotation gaps are the principal risk: a leaked PAT is a refresh-token-equivalent without an interactive auth event in `LOGIN_HISTORY`. Monitor `ACCOUNT_USAGE.PROGRAMMATIC_ACCESS_TOKENS` for issuance, last-use, and expiration; alert on PATs older than the rotation policy or with no recent use.

Cortex inference egress

Cortex Analyst and Cortex Agents pass prompts and grounding context to large language models for final-response generation. For most Cortex surfaces this means inference reaches out-of-Snowflake-boundary providers (Anthropic, Azure-OpenAI). Customers who treat Snowflake as an in-boundary data store should treat this as a boundary crossing.

What leaves the boundary: the user prompt, the system prompt assembled by Cortex, and the grounding context the agent fetched (query results, Cortex Search hits, document excerpts). For an Agent invocation, any column data that satisfied the agent's retrieval also leaves the boundary as part of the LLM context. Column-level masking does apply, but masking policies are enforced at SELECT time — masked data does not leave the boundary, unmasked data the agent's role can read does.

Governance levers a customer has:

ALLOWED_INTERFACES restricts which roles can reach ai.snowflake.com — narrow the population that can invoke Cortex at all.
Two-tier model allowlist: account-level model allowlist plus role-level CORTEX_USER / CORTEX_EMBED_USER grants. A role with broad data access but no AI use case should not hold CORTEX_USER.
Region pinning on the provider side (Azure-OpenAI deployment in a customer-chosen region) constrains where inference physically runs.
Cortex AI Guardrails (Horizon Catalog) screens for prompt-injection and jailbreak content on inputs.

What this assessment cannot conclude: the exact payload shape sent to the LLM provider, the retention or training-use policy at the provider, and whether grounding context is ever cached across invocations. These are vendor-side disclosures that the customer should obtain through a DPA review, not a red-team activity. Data classification policies should explicitly state whether each protected data class is permitted to be passed through Cortex inference.