Toutes les vulnérabilités
CRITICALOpSeccurated

OPSEC-SNOWFLAKE-2024

Cloud · Snowflake (customer tenants)

Résumé

In mid-2024, a single gap, accounts without multi-factor authentication, turned into one of the largest waves of data theft ever, hitting Ticketmaster, AT&T, Santander, and around 165 other companies at once. The attackers never broke Snowflake, the cloud data platform all of them used. They simply logged in with valid usernames and passwords, harvested months or years earlier by infostealer malware from employees' personal computers and bought on criminal markets. Where MFA was not turned on, a stolen password was a full key. It is the defining lesson of the infostealer era: your breach can start on an employee's home laptop, and MFA is the difference between a leaked password and a catastrophe.

How it happened

The threat group UNC5537 ran mass data theft against about 165 Snowflake customer tenants between roughly April and June 2024, and it is important to be precise about what they did not do: they did not exploit any flaw in Snowflake. The chain started elsewhere. Infostealer malware (families like Vidar, RedLine, and Lumma) on employee and contractor machines, often personal devices, and some infections years old, had quietly harvested saved Snowflake credentials, which were then sold and circulated on criminal markets. Mandiant found that at least 79.7% of the abused accounts had a prior infostealer exposure, with the earliest credential dating back to 2020.

The attackers just logged in. The targeted accounts had no MFA enabled and no network allow-listing, so a stolen single-factor credential granted direct access to the data warehouse. From there, using a custom reconnaissance tool Mandiant named FROSTBITE to enumerate each instance, they ran bulk exports of customer data and extorted the victims. Every step was a normal login; the only thing missing was a second factor.

The damage

The victim list was staggering: Ticketmaster and Live Nation (data on about 560 million customers), Santander (whose data the attackers advertised as 30 million customer records, though Santander itself confirmed only that a database including about 12,786 of its employees was affected), and AT&T (call and text metadata for roughly 110 million customers, with AT&T reportedly paying about $370,000), across around 165 tenants in total. The Ticketmaster access reportedly traced to infostealer credentials for a former Snowflake employee's demo account that had no MFA. Independent investigations by both Mandiant and CrowdStrike concluded the campaign stemmed entirely from stolen customer credentials, not any flaw in Snowflake. By late 2024 two suspects had been charged: Connor Moucka, arrested in Canada in October 2024, and John Binns, arrested in Turkey. It was one of the largest data-theft campaigns in history, and almost entirely preventable; the common thread across every victim was not a clever exploit but a missing checkbox.

Why Snowflake still matters

Snowflake is the infostealer-plus-missing-MFA lesson at scale. The corporate perimeter is irrelevant when the credential leaks from an employee's home PC, and the only thing standing between a stolen password and your entire data warehouse is MFA, which these accounts did not have. In the aftermath Snowflake moved hard on the gap: it made MFA the default for new accounts and announced it would block password-only sign-in entirely, where the second factor had previously been optional. The other defences are unglamorous: enforce MFA on every cloud account (especially admin and service accounts), restrict access with network allow-lists or private connectivity, replace static passwords with SSO and key-pair authentication, monitor for infostealer-harvested credentials and anomalous logins, and alert on large or unusual data exports. It is the same single-credential, no-MFA failure as the Colonial Pipeline attack.

Comment le corriger

  • Enforce MFA on every account immediately, reset all credentials, and revoke active sessions, since the access was valid stolen logins.
  • Add network allow-listing so the data platform is only reachable from known locations, and hunt for and quantify what data was exported.
  • Identify infostealer-infected employee and contractor machines and rebuild them; the leaked credentials originate there.

Comment l’éviter

  • Enforce MFA on every cloud data-platform account, especially admin and service accounts; never leave it optional.
  • Restrict warehouse access with network policies/allowlists or private connectivity to known sources.
  • Replace static user passwords with SSO and key-pair auth; rotate credentials immediately on exposure.
  • Detect infostealer-harvested credentials and alert on logins from new locations, clients, or IPs.
  • Apply least privilege to warehouse roles and alert on large or unusual data exports.

Références

Vulnérabilités liées

Tout OpSec →