Snowflake & AT&T Mega-Breach 2024 — UNC5537’s 165-Org Credential-Stuffing Campaign: Technical Reconstruction

The Snowflake-related breaches of 2024 reset the industry conversation about cloud data warehouse security in a way that few prior incidents had. Snowflake itself was not breached; its customers were, en masse, through credentials that had been on the open market for years inside infostealer logs. This is the breach pattern that defines the 2020s cloud era: not zero-days, not nation-state APT campaigns, but commodity credential theft scaled by a threat actor patient enough to stuff millions of credentials against a single high-value SaaS surface and harvest the inevitable hits. This post reconstructs UNC5537’s campaign, the mechanics of how a credential leaked from a third-party laptop in 2021 ended up exposing 110 million AT&T subscriber records in 2024, and what every organisation using cloud SaaS must learn from this template.

What happened — the credential-stuffing playbook scaled to enterprise SaaS

The attack pattern was operationally simple and devastatingly effective. Step 1: collect a large corpus of Snowflake-domain credentials harvested from years of infostealer malware infections on individual laptops. Infostealers (Vidar, Raccoon Stealer, Redline, Lumma, Stealc, and dozens of variants) infect endpoints typically via cracked-software downloads, malicious browser extensions, phishing attachments, or compromised software updates. Once installed, they exfiltrate every credential stored in the browser (Chrome, Firefox, Edge), every cookie, every saved form data, every autofill entry. The harvested data is uploaded to attacker-controlled servers and aggregated into “stealer log” databases sold on Telegram channels and dark-web forums for as little as $10 per gigabyte. Step 2: filter the logs for Snowflake-related credentials. Snowflake URLs follow a predictable pattern (customername.snowflakecomputing.com) so credentials saved with that domain context are easily extracted. Step 3: attempt login to each Snowflake account. Where MFA is enforced, the credential fails (one of Snowflake’s key recommendations was always to enforce MFA, but it was not mandatory at the platform level until after these breaches). Where MFA is not enforced, the attacker logs in as a valid user. Step 4: enumerate the data warehouse, identify high-value tables, exfiltrate to attacker-controlled S3 or via direct download. Step 5: extort the victim, sell the data, or both.

The scale — 165 organisations, 100s of millions of records, terabytes of data

Mandiant’s investigation, published in June 2024 and updated through August, attributed the campaign to UNC5537 — Mandiant’s designation for an unaffiliated threat group operating from North America (specifically, members in the US and Canada per the FBI indictment of Connor Moucka and John Binns in late 2024). The financially-motivated group accessed at least 165 Snowflake customer environments. Of those, the most prominent confirmed victims include: AT&T: approximately 110 million customer records — phone numbers and call/text metadata for nearly every AT&T mobile customer for a six-month window in 2022, plus some metadata extending into 2023. Ticketmaster: approximately 560 million customer records — names, addresses, phone numbers, partial credit card data. Santander Bank: approximately 30 million customers — primarily Latin American operations, with credentials, account numbers, and transaction histories. Advance Auto Parts: 380GB of data including SSN-bearing records of approximately 2.3 million people. Neiman Marcus: 64,000 customer records. LendingTree: via subsidiary QuoteWizard, undisclosed number. Pure Storage: a workspace environment confirmed compromised, customer impact disputed. Plus 150+ unconfirmed others who either chose not to publicly disclose, settled the extortion privately, or are still investigating. Total data exfiltrated across the campaign exceeds estimates of 5-10 petabytes when measured by volume.

The shared responsibility breakdown — how Snowflake is and is not at fault

The fundamental question that consumed industry discourse for months after the breaches: was this Snowflake’s fault, or their customers’ fault? The Snowflake position: the platform was not breached; the credentials were valid; the customers had the option to enable MFA, IP allowlisting, network policies, and other controls that would have prevented the attack. Customer security configuration is the customer’s responsibility under standard cloud shared-responsibility models. The customer perspective: Snowflake offered MFA but did not enforce it, did not warn customers loudly enough about credential-stuffing risk, did not provide threat intelligence about active attacks against Snowflake-hosted data warehouses, and did not implement adaptive authentication that would have flagged unusual access patterns. The honest assessment: both. Snowflake’s authentication architecture as of 2024 supported insecure customer configurations more easily than secure ones — the path of least resistance was username + password without MFA. Snowflake’s competitors (Databricks, BigQuery, Redshift) had similar patterns. The post-incident response from Snowflake — mandating MFA, introducing better authentication policies, providing tooling to detect anomalous access — implicitly acknowledges that the platform’s default security posture was inadequate for the threat environment its customers operated in. The lesson generalises across all multi-tenant SaaS: when your customers can be hacked through your platform without any vulnerability in your code, you have a security problem regardless of contractual liability.

Timeline — from credential harvest to mass extortion in months

2020-2023: Infostealer malware infects millions of personal and corporate laptops globally. Snowflake credentials saved in browsers are exfiltrated to attacker collections. April 2024: UNC5537 begins systematic logins to Snowflake customer accounts using harvested credentials. 14 May 2024: Snowflake notes “increased threat activity” against customer accounts in internal threat intelligence; first customer notifications begin. 20 May 2024: Ticketmaster discloses the breach via a US SEC 8-K filing. 22 May 2024: Santander discloses. 27 May 2024: Snowflake publishes its first detailed advisory; emphasises customer-side controls; faces immediate customer pushback. 2 June 2024: Mandiant publishes the UNC5537 attribution and detailed technical analysis. 10 July 2024: AT&T discloses; reportedly paid ~$370,000 ransom. August 2024: Snowflake announces mandatory MFA enforcement for all customer accounts (rollout phased through end of 2024). October-November 2024: US authorities indict Connor Moucka (Canadian) and John Binns (American, residing in Turkey) on multiple counts including computer fraud and aggravated identity theft. Moucka arrested in Canada. 2025: Indictments unsealed; ongoing extradition proceedings; class-action lawsuits proceed in multiple US districts; AT&T, Ticketmaster, Santander, and others negotiate settlements with affected customers.

Technical deep-dive — infostealer logs as the new credential database

Infostealer malware is the unappreciated foundation of modern credential-based attacks. The economics: infection-as-a-service costs $100-500/month for the malware kit; deployment via cracked-software pages, YouTube comment spam, or phishing yields thousands to tens of thousands of infections per month per operator. Each infected machine produces a “log” containing browser passwords, cookies, autofill, system info, screenshots, and cryptocurrency wallet files. Logs are uploaded to operator infrastructure and either used directly or sold/traded on aggregator platforms. Russian Market, Genesis Market (until US/EU takedown in April 2023), and various Telegram-hosted log shops are the primary aggregation venues. Why this matters for Snowflake-style attacks: a single Snowflake credential set (URL + username + password + cookies) sells for $10-200 depending on the perceived target value. An attacker building a Snowflake-targeting campaign can purchase or harvest tens of thousands of credentials, automate login attempts, and statistically expect 5-15% to succeed against accounts without MFA. The economics work even at low success rates because the per-victim payout is very high — a single Fortune 500 customer’s data warehouse is worth six to eight figures in extortion or sale. Defensive implication: assume your corporate credentials, especially those used by employees in browsers on personal devices, are or will be in stealer logs. Detection: services like Hudson Rock, IntSights, Recorded Future, and Have I Been Pwned’s “Stealer Logs” feature monitor for your domain in stealer log corpora. Response: mandatory MFA, hardware-token preferred, plus behavioural anomaly detection on logins from new geographies or unusual access patterns.

Indicators of compromise and detection — what your SOC should hunt for

Detection queries and indicators relevant to Snowflake-style credential-stuffing campaigns. (1) Unusual login geography: Snowflake authentication logs (accessible via the SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY view) show client IP, geolocation, success/failure. Alert on logins from countries where you have no users or operations. UNC5537 logged in from VPN endpoints (Mullvad, NordVPN, ProtonVPN) but also from residential proxy services that geolocate as legitimate user countries — pattern detection requires aggregating across multiple sessions per user. (2) ASN and ISP analysis: business users typically log in from corporate ASNs (your corporate ISP) and consumer ISPs (home internet). Logins from data-center ASNs (Hetzner, OVH, DigitalOcean, AWS, Azure) or commercial VPN ASNs are anomalies for most user accounts. (3) Failed-then-successful login pattern: credential stuffing typically generates a burst of failures across many accounts before a success. Aggregated failure counting per account and per source IP catches this. (4) Unusual query patterns: the attacker workflow is “log in → enumerate tables → download largest interesting tables.” This produces query patterns very different from normal users — heavy SELECT * with no WHERE clauses, large result-set downloads, sequential exploration of the data dictionary. Snowflake’s QUERY_HISTORY view enables detection. (5) Cookie/session abuse: stolen cookies allow session reuse without re-authentication. Implement session-binding (cookies tied to client IP and User-Agent) and short session timeouts (4-8 hours, not 30 days). (6) Honey credentials: create fake Snowflake users that no legitimate process should ever log in as; any login attempt is a high-fidelity attack signal.

Mitigations — the 10-item Snowflake security checklist

(1) Enforce MFA at the account level, not just optionally. Snowflake now mandates this; if you have any custom configurations carving out exceptions, audit and remove them. (2) Require hardware-token MFA for privileged accounts (admins, anyone with cross-schema access). FIDO2/WebAuthn keys are phishing-resistant in ways that TOTP and push notifications are not. (3) Implement Network Policies that restrict Snowflake access to specific IP ranges (your corporate VPN, your office IPs, your AWS workloads). The platform supports CIDR-based allowlists; use them. (4) Use SCIM provisioning from your identity provider (Okta, Azure AD, Google Workspace) so that user lifecycle is managed centrally — when an employee leaves, their Snowflake access is revoked automatically. (5) Disable password-only auth. Modern Snowflake supports SSO via SAML/OIDC; mandate it for all users so passwords aren’t a viable authentication path at all. (6) Monitor login history via Snowsight or external SIEM ingestion of LOGIN_HISTORY. (7) Implement query-pattern monitoring for anomalous data access. (8) Encrypt sensitive columns at the application layer using Snowflake’s built-in encryption functions or external KMS — even an attacker with valid credentials should see ciphertext for the most sensitive fields. (9) Mask data dynamically using Snowflake’s Dynamic Data Masking and Row Access Policies — analysts see masked values unless their role explicitly entitles them to see plaintext. (10) Run regular access reviews — quarterly verify every user, every role, every grant. Stale permissions are the single most common avenue for blast-radius expansion when an account is compromised.

India context — what Indian SaaS users should learn from this

India has rapidly adopted cloud data warehouses across enterprises (Reliance Jio, ICICI, HDFC Bank, Flipkart, and dozens of others use Snowflake; Tata Steel uses Databricks; many use BigQuery). The Snowflake breaches are directly applicable to Indian organisations because: (1) the same authentication patterns and configuration defaults apply globally; an Indian enterprise running Snowflake without MFA is structurally as vulnerable as AT&T was. (2) Indian customer PII (Aadhaar, PAN, bank account numbers) is high-value to attackers and will increasingly be targeted as Indian organisations migrate analytical data to cloud platforms. (3) Under DPDP Act 2023, an Indian company suffering a breach via cloud SaaS misconfiguration would be the Data Fiduciary responsible — the cloud platform vendor’s contractual position would not absolve the customer of regulatory liability under DPDP. CERT-In notification within 6 hours and DPB notification within prescribed timelines would apply. (4) RBI in 2024 issued specific guidance on cloud security for regulated financial entities; SEBI followed for capital markets; expect IRDAI and PFRDA to follow for insurance and pensions. The regulatory expectation in India 2025-2026 is that cloud SaaS configurations meet strict baseline requirements; Snowflake-style misconfigurations would attract supervisory action. For Indian CISOs: commission a cloud SaaS security assessment specifically focused on identity and access — every external SaaS your organisation uses, who has access, whether MFA is enforced, whether SSO is wired, whether session timeouts are sane. The Snowflake breach pattern is generalisable to any cloud SaaS holding regulated data; the next major Indian incident may not be Snowflake but the architecture of failure will be the same.

Lessons learned — the new identity-first security paradigm

The Snowflake-AT&T-Ticketmaster cluster of breaches crystallised a shift in security thinking that had been building for years. (1) Identity is the new perimeter, and credentials are the new exploit. Network-perimeter defence and software-vulnerability patching remain necessary but are no longer sufficient. The dominant 2024-2025 attack vector is “log in with valid credentials” — there is no firewall between an authenticated user and your data. (2) Shared responsibility means shared accountability. Cloud vendors and customers cannot point fingers at each other when 100M users’ data is exposed. The cloud vendor must enforce secure defaults; the customer must verify and implement them. Both must communicate risks proactively. (3) MFA is table stakes — the absence of it is malpractice. Any organisation in 2025 that allows password-only authentication to systems holding regulated personal data is operating below the standard of care that regulators, customers, and partners expect. (4) Infostealer malware is a structural threat. Personal devices, contractor laptops, and BYOD scenarios expose credentials in ways your corporate device-management policies cannot reach. The only durable defences are MFA (so credentials alone are insufficient) and credential rotation triggered by stealer-log monitoring. (5) Ransom payment is morally fraught and operationally limited. AT&T paid; the data was supposedly deleted; the same data has appeared in subsequent dark-web sales. Payment provides no guarantee. Organisations must plan for the worst case (data is exposed permanently regardless of payment) when designing incident response.

What to do this week — concrete actions for cloud SaaS administrators

A seven-day plan for organisations using Snowflake or comparable cloud SaaS holding sensitive data. Day 1: Inventory. List every cloud SaaS your organisation uses that holds regulated PII or sensitive business data. Snowflake, Databricks, BigQuery, Salesforce, Workday, ServiceNow, GitHub, GitLab, Slack, etc. Day 2: Authentication audit. For each, document: (a) is MFA mandatory for all users? (b) is SSO wired to your IdP? (c) are there any standalone local accounts that bypass SSO? (d) what session timeout is enforced? (e) what IP/network restrictions exist? Day 3: Privileged access review. Who has admin/elevated permissions in each SaaS? Are they still employed? Do they still need it? Revoke aggressively. Day 4: Stealer log monitoring. Subscribe to a credential-leak monitoring service for your corporate domains. Test by checking your own domain in Have I Been Pwned’s Stealer Logs feature. Day 5: Logging and detection. Verify that authentication logs from all critical SaaS are being ingested into your SIEM. Build alerts for: failed-then-successful login bursts, logins from new geographies, logins from data-center ASNs, anomalous data access patterns. Day 6: Incident response runbook. Update IR procedures specifically for “credentials compromised, valid login from attacker.” Steps: revoke session, rotate password, enforce MFA re-enrollment, query data-access logs for the affected user, assess data exfiltration. Day 7: Executive briefing. The Snowflake-AT&T story is excellent material for board and exec-team awareness. Use it to secure budget for any of the above that requires investment.

Wider implications — how this reshapes cloud SaaS security in 2025-2026

The structural changes triggered by the Snowflake-cluster breaches are still playing out and will define cloud security operating models for years. (1) Mandatory MFA at the platform level. Snowflake led; Salesforce followed in mandating MFA for all customer accounts; expect Microsoft 365, Google Workspace (already largely there), Slack, and others to make MFA non-optional. The “MFA is a customer choice” era is over. (2) Default-deny network policies. Cloud SaaS platforms are increasingly adopting “zero trust by default” where access requires explicit allowlist of source IPs or device certificates rather than the historical “anywhere with valid credentials.” (3) Phishing-resistant authentication standards. FIDO2/WebAuthn (hardware security keys, platform authenticators like Apple Touch ID and Windows Hello) is rapidly becoming the standard for high-privilege accounts. TOTP and SMS are being deprecated where possible. (4) Dark-web and stealer-log integration. Major identity providers (Okta, Microsoft Entra, Google Identity) now integrate real-time stealer-log feeds; if a credential appears in a stealer log, the account is automatically forced into MFA re-enrollment and password rotation. Expect this to be standard across enterprise IdP. (5) Customer security maturity becomes a vendor risk metric. Cloud platforms will increasingly evaluate customer security posture (MFA adoption, network policies, log monitoring) as part of onboarding and ongoing service decisions; insurance and regulatory pressure pushes vendors to require minimum standards. (6) Incident notification standards harden. The slow disclosure of the AT&T and Ticketmaster breaches drew SEC attention; expect more aggressive enforcement of disclosure timelines for material cyber incidents. The Snowflake-related breaches will be cited in security awareness training, regulatory enforcement actions, and academic security curriculum for the rest of the decade — they are the canonical example of how identity compromise scales in the cloud SaaS era.

FAQ

Was my data in the AT&T breach?

If you were an AT&T mobile customer between approximately May and October 2022, plus a smaller window of January 2023, your phone number and call/text metadata (who you called, when, for how long — not call content) was likely included. AT&T provided a partial notification mechanism; check your account messaging.

Was Snowflake actually hacked?

No. The Snowflake platform itself was not compromised. The attackers used valid customer credentials to log in to customer-controlled accounts. The fault, in the strict legal/contractual sense, lay with customers who had not configured MFA and other security controls on their Snowflake instances.

Should I avoid using Snowflake now?

No, with caveats. Snowflake remains a competitive cloud data warehouse and has materially hardened its default security posture post-incident. The lessons here apply to any cloud SaaS, not specifically Snowflake — Databricks, BigQuery, Redshift have comparable structural exposure if customers misconfigure them.

How do I know if my Snowflake instance was hit?

Query the LOGIN_HISTORY view for the past 12 months. Look for: (1) successful logins from IPs you don’t recognise; (2) authentication patterns inconsistent with your normal users; (3) data-export activity from accounts that don’t typically export. If you see anomalies, engage Snowflake support and a forensics firm immediately.

Did paying the ransom protect AT&T customer data?

No. Despite the reported $370,000 payment, similar data has appeared in subsequent dark-web sales. Ransom payment in data-exfiltration cases provides no enforceable guarantee. Payment may delay public release but does not prevent it permanently.

Are credential stuffing attacks like this common?

Extremely. The vast majority of cloud SaaS breaches in 2024-2025 follow this pattern: stolen credentials + missing MFA = data exfiltration. The technique is so commoditised that attackers can buy infrastructure-as-a-service for credential stuffing for under $1,000/month. Every cloud SaaS holding sensitive data is targeted; the question is whether your defences will hold.

📰 Note: This analysis is compiled from public reporting (Reuters, Bloomberg, court filings, threat-intel firm publications) and is intended for security education. Some technical details remain disputed in ongoing legal proceedings; we have attributed claims where the source is established and noted where matters remain contested.