Snowflake Mega-Breach Anatomy — How UNC5537 Hit 165 Customers Without a Single Vulnerability

The Snowflake breach pattern is the cleanest demonstration of identity-as-the-perimeter we have. There was no Snowflake-platform vulnerability. Every successful intrusion started with a stolen username/password, often years old, replayed against a tenant that had not enforced MFA. The lessons translate directly to every Indian SaaS-using business that thinks “the vendor is responsible.”

The infostealer supply chain — where the credentials came from

The credentials UNC5537 used were not stolen from Snowflake. They were collected over months and years by commodity infostealer malware — Lumma Stealer, RedLine, Vidar, Raccoon — running on contractor and developer laptops. The usual delivery: a “cracked Photoshop” download, a malicious VS Code extension, a fake CAPTCHA / “verify you are human” popup that tricks users into pasting a PowerShell command into Win+R. Each installation harvests browser-saved passwords, session cookies, crypto wallets, and Discord tokens.

The harvested credentials end up in Russian Market, Genesis Marketplace successor sites, and Telegram-based credential-sale channels. Specialized buyers like UNC5537 purchase credentials filtered by target — “any login matching *.snowflakecomputing.com” — and try them against the corresponding tenant. Anyone without MFA gets popped.

Why Snowflake-as-victim is the wrong frame

Snowflake’s public response framed this as a customer-side identity failure. Technically correct: every compromised tenant had MFA available and chose not to enforce it. Strategically incomplete: a platform that processes hundreds of millions of customer records should make MFA enforcement non-optional by default, not opt-in. The post-incident change Snowflake announced — admin ability to enforce MFA across all users — should have shipped in 2018, not 2024.

The same critique applies to most Indian SaaS vendors. Zoho, Freshworks, Razorpay’s merchant dashboards, Tata 1mg’s pharmacy admin panels — most ship with MFA available but customer-toggleable. The default is wrong.

Attack-chain walkthrough — UNC5537 against a real tenant

Reconstructed from the Mandiant write-up plus victim post-mortems:

1. T-3 to T-12 months — A contractor at a target customer downloads cracked software at home; Lumma Stealer is dropped; harvests their browser-saved Snowflake credentials and Okta cookies.
2. T-1 to T-5 days — Credentials sold on Russian Market for $10-$200/login.
3. T0 — UNC5537 logs in to {tenant}.snowflakecomputing.com via the contractor’s stolen credentials. No MFA enforcement → success on first try.
4. T0 + 1 hour — Attacker enumerates databases, identifies high-value tables (PII, payments, call records), runs SELECT * at scale, exfiltrates via Snowflake’s own data-share / external-stage feature to an attacker-controlled S3 bucket.
5. T+1 to T+30 days — Extortion email to victim CISO with sample data; if no payment, dump on BreachForums.

The whole intrusion lifecycle on the customer side fit in a single shift. There was no lateral movement, no privilege escalation, no malware. Just a login.

Detection — what the Snowflake audit log would have shown

Every compromised tenant had the data to detect this in their SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY view. Indicators that should have triggered an alert:

• Login from a new ASN — UNC5537 used Mullvad VPN exit nodes and ALTSVC-VPN; legitimate users rarely originate from those.
• Login at an unusual hour for the user — most contractor accounts have a predictable working window.
• First-ever query of information_schema.tables followed by large SELECT * — high-fidelity sign of enumeration.
• External-stage creation followed by COPY INTO on a tenant that has never used external stages — exfil pattern.

SQL hunt query — paste into Snowflake worksheet, run weekly:

SELECT user_name, client_ip, reported_client_type, COUNT(*) AS logins
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE event_timestamp > DATEADD(day, -30, CURRENT_TIMESTAMP())
  AND is_success = 'YES'
GROUP BY 1,2,3
HAVING COUNT(DISTINCT client_ip) > 3
ORDER BY logins DESC;

Any user logging in from more than 3 distinct IPs in 30 days is investigation-worthy in a contractor-heavy environment.

The Indian angle — infostealer epidemic

Specops 2025 telemetry: India ranks #2 globally for infostealer infections behind Brazil, with an estimated 12 million distinct credentials stolen in 12 months. Drivers: massive pirated-software market, weak endpoint protection on small-business laptops, contractor-heavy IT services industry where laptops cross customer boundaries weekly.

For an Indian product company outsourcing development to a TCS/Infosys/Wipro contractor, the risk math is: that contractor’s personal laptop, used for after-hours work, is statistically likely to have an infostealer at some point in a 24-month engagement. If they’ve ever logged in to your Snowflake/Okta/AWS console from that laptop, your tenant is in the risk pool.

The hardening playbook — run this by Monday

1. Enforce MFA at the tenant level, not user level. Snowflake’s NETWORK POLICY + AUTHENTICATION POLICY at the account level make this auditable. ALTER ACCOUNT SET MFA_REQUIRED_FOR_ALL_USERS = TRUE; if your edition supports it.
2. Network policy IP allow-list — only allow logins from corporate VPN egress IPs and known integration IPs. Blocks credential-replay from anywhere else.
3. Service accounts use key-pair auth, not passwords — password-based service accounts cannot get MFA, so they remain in the credential-stuffing risk pool. Migrate everything to RSA key-pair authentication.
4. Audit query patterns — automated alert on any session that queries information_schema followed by SELECT * from a PII table.
5. Disable external-stage creation for non-data-engineering roles. Only the people who legitimately need to export should have CREATE STAGE privilege.
6. Rotate credentials for every contractor laptop that ever touched the tenant in the last 18 months. Yes, that’s a lot. Do it anyway.
7. Subscribe to a credential-leak monitoring service (Hudson Rock, Constella Intelligence, SpyCloud) and feed their feed into your IAM offboarding pipeline. When a contractor’s email shows up in a stealer log, force-rotate before the credential-buyer does.

Strategic — the lesson for SaaS-using leaders

The shared-responsibility model from cloud providers is real but dangerously self-serving. The vendor’s responsibility ends at “feature available.” The customer’s responsibility starts at “feature configured correctly.” If MFA is the most-effective security control we have (it is), and only 35% of tenants enforce it (Snowflake’s pre-incident telemetry), then the vendor’s default is the lever that decides population-level outcomes. Push your SaaS vendors to make MFA mandatory by default, and be the customer they cite when the next vendor pushes back on their own change. The strategic security posture is “default secure, opt-out friction-heavy” — not “default open, security as upgrade SKU.”

FAQ

Can I tell if my Snowflake tenant was hit by UNC5537?

Run the SQL hunt query above for the date range Apr 2024 – Aug 2024. Look for logins from Mullvad-style ASNs (M247, FlokiNET, IPXO). Cross-reference with documented IOCs: 104.223.91.0/24 and 193.32.162.0/23 were repeatedly seen.

What if our developers genuinely need to log in from coffee shops?

Use a corporate VPN egress as the network-policy anchor. Coffee-shop user → corporate VPN → Snowflake. The IP allow-list should have only your VPN exit IPs, never “0.0.0.0/0 with MFA.” MFA reduces but doesn’t eliminate stuffing risk; network policy is the strong control.

Are SSO + Okta enough to prevent this?

Only if your Okta tenant itself has FIDO2 / WebAuthn enforced and sessions are short-lived. Several Snowflake victims were Okta-federated; the attacker stole Okta session cookies, not Snowflake passwords. Cookies are the new credentials. Enforce strict session lifetimes (8h max) and bind sessions to client device with WebAuthn.

What about non-Snowflake SaaS — Salesforce, HubSpot?

Same threat model. Same mitigations. UNC5537 publicly named Snowflake; the technique works on any SaaS with password auth. Run the same network-policy + key-pair + MFA-enforced + query-audit posture across every tenant holding production data.

Is this attribution real or speculative?

Mandiant and CrowdStrike independently track UNC5537 / ShinyHunters. The named individuals (Connor Moucka — arrested in Canada, Oct 2024) are charged in Western District of Washington. Attribution is solid; ongoing prosecution will surface more detail.

⚖️ Legal: Threat-intelligence content for defensive use. Do not replicate adversary techniques against systems you do not own. Credential-replay testing on customer SaaS tenants is unauthorised access under IT Act §66. Use Snowflake’s account-trial environment for hands-on practice if needed.