Cyber-attack Timeline: Snowflake

FAQs on the Snowflake Cyber Attack

• 1. What was the Snowflake cyber attack/data breach of 2024?

  In May and June 2024, a wave of high-profile data breaches was traced back to customer accounts on the cloud data platform Snowflake. Threat actors used login credentials — largely stolen earlier by infostealer malware — to access the Snowflake environments of organisations that had not enabled multi-factor authentication (MFA), then exfiltrated large volumes of data. Victims linked to the campaign included Ticketmaster, Santander, Advance Auto Parts, LendingTree's QuoteWizard and Pure Storage. Snowflake maintained that its own platform was not breached and that the incidents stemmed from compromised customer credentials rather than a vulnerability in its product. Google's Mandiant later attributed the activity to a financially motivated group it tracks as UNC5537.

• 2. When did the Snowflake data breach take place?

  The activity came to public attention in late May 2024. Snowflake's CISO said some customer accounts were compromised as early as 23 May 2024, and on 27 May a criminal actor offered alleged stolen data for sale on the dark web. The Ticketmaster and Santander breaches surfaced around 28-31 May, and further disclosures — Advance Auto Parts, LendingTree/QuoteWizard and Pure Storage — followed through early to mid-June 2024. Mandiant, which investigated the campaign, noted related threat intelligence dating to April 2024 and stolen credentials going back as far as 2020. Snowflake reportedly planned to close its own investigation around 13 June 2024.

• 3. Who was behind the Snowflake cyber attack?

  Google-owned threat intelligence firm Mandiant attributed the campaign to a financially motivated group it tracks as UNC5537. Individuals using handles such as 'ShinyHunters' and 'Sp1d3r' claimed responsibility for selling data from several victims on cybercrime forums. Some reporting, including from The Register, suggested possible links to the broader 'Scattered Spider' (UNC3944) cluster known for the 2023 Las Vegas casino breaches, though this connection was not firmly established. Reporting consistently framed the operation as financially motivated data theft and extortion rather than a state-sponsored attack.

• 4. How did the attackers gain access to Snowflake accounts?

  According to Mandiant, the attackers used valid usernames and passwords rather than exploiting a flaw in Snowflake itself. The majority of these credentials had been harvested by infostealer malware — in some cases years earlier, dating back to 2020 — often from contractor or personal systems also used for activities such as gaming or downloading pirated software. Three factors made the accounts vulnerable: they lacked multi-factor authentication, the stolen credentials had not been rotated and remained valid, and the affected instances had no network allow-lists restricting access to trusted locations.

• 5. Was Snowflake itself hacked?

  Snowflake consistently denied that its platform was breached. It stated that a bad actor had accessed a demo account belonging to a former employee that contained no sensitive data, and that it did not believe the activity was caused by any vulnerability, misconfiguration or malicious activity within the Snowflake product. Under its shared responsibility model, Snowflake said customers were responsible for enforcing MFA on their own accounts. Some security researchers, including Kevin Beaumont, argued that Snowflake bore some responsibility for not enforcing MFA on its demo environment and for failing to disable a former employee's access, so the allocation of blame remained contested.

• 6. Which companies were affected by the Snowflake breach?

  Organisations publicly linked to the campaign included Ticketmaster (and parent Live Nation), Santander, Advance Auto Parts, LendingTree's QuoteWizard subsidiary and Pure Storage. Threat actors and security firm Hudson Rock also named other high-profile companies — such as Anheuser-Busch, State Farm, Mitsubishi, Progressive, Neiman Marcus and Allstate — though not all of these claims were independently confirmed. Much of the naming came from threat-actor posts and third-party research rather than confirmed company statements, so unverified links should be treated with caution.

• 7. How many organisations were impacted by the Snowflake attack?

  Estimates varied by source. Threat actors claimed that roughly 400 organisations were affected. Mandiant said it had notified approximately 165 potentially exposed organisations after identifying a broader campaign on 22 May 2024. The Australian Cyber Security Centre said it was aware of successful compromises of several companies using Snowflake environments, and the US Cybersecurity and Infrastructure Security Agency (CISA) issued an alert about the incident. The differing figures reflect the gap between attacker claims and the number of victims investigators could actually confirm.

• 8. What data was stolen in the Ticketmaster breach?

  According to reports cited in a proposed class-action lawsuit, the private information of around 560 million Ticketmaster customers was compromised and offered for sale on dark-web forums by a group using the 'ShinyHunters' name. The allegedly stolen databases were said to total roughly 1.3 TB and to include customers' full names, home and email addresses, phone numbers, and ticket sales, order and event information. ShinyHunters reportedly attempted to sell the data for around US$500,000. Live Nation's Ticketmaster disclosed unauthorised activity in a third-party cloud database in an SEC filing.

• 9. What data was stolen from Santander in the breach?

  Santander confirmed that information relating to customers in Chile, Spain and Uruguay, as well as all current and some former Santander employees, had been accessed, while stating that customers in its other markets were not affected. A group using the 'ShinyHunters' name posted an advert claiming to hold Santander data including around 30 million people's bank account details, 6 million account numbers and balances, 28 million credit card numbers, and HR information for staff. Santander apologised for the concern caused and said it was contacting affected customers and employees directly. The larger figures came from threat-actor claims and should be treated as unverified.

• 10. What data was stolen from Advance Auto Parts?

  Threat actors using the 'Sp1d3r' handle claimed to be selling around 3 TB of data stolen from Advance Auto Parts' Snowflake environment, reportedly listed for about US$1.5 million. The claimed archive included approximately 380 million customer profiles, 140 million customer orders, 44 million loyalty and gas card numbers, sales history, transaction details, auto parts numbers, and employment candidate information containing Social Security numbers and driver's licence numbers. The actors claimed data on 358,000 employees, though the company was reported to have around 68,000 — the difference possibly reflecting former staff. BleepingComputer said it was able to confirm that a number of the records appeared legitimate.

• 11. Was a ransom demanded in the Snowflake attack?

  Reporting described extortion attempts rather than a single confirmed ransom. According to Hudson Rock, the threat actor claimed to have tried to blackmail Snowflake into buying back stolen data for around US$20 million, but said the company did not respond. Separately, stolen datasets were listed for sale on cybercrime forums — for example around US$500,000 for the Ticketmaster data and about US$1.5 million for the Advance Auto Parts data. The threat actor also claimed that some Snowflake customers had already paid to recover their data, though BleepingComputer could not independently verify this.

• 12. What tools and techniques did the attackers use?

  Mandiant reported that initial access often occurred through Snowflake's native web interface (SnowSight) and command-line tool (SnowSQL), typically run from Windows Server 2022 systems. The attackers used an attacker-named data-exfiltration utility that Mandiant tracks as FROSTBITE, and were also observed using the DBeaver database management tool, with logs showing a distinctive user agent. Hudson Rock reported that at least one relevant employee's device had been infected by a Lumma-type infostealer, illustrating how stolen credentials — rather than any exploit — underpinned the campaign.

• 13. Why didn't multi-factor authentication stop the attack?

  The central lesson of the incident was that the compromised accounts largely did not have MFA enabled, so a valid username and password alone were enough to log in. Mandiant found that stolen credentials remained usable because they had not been rotated, and that affected Snowflake instances had no network allow-lists limiting access to trusted locations. Mandiant's Charles Carmakal warned that any SaaS platform configured without MFA is susceptible to mass exploitation and urged organisations to enforce MFA and IP-based restrictions — advice that became the defining takeaway of the campaign.

• 14. How did Snowflake respond to the attack?

  Snowflake published a security bulletin with indicators of compromise, investigative queries and hardening advice, and said it was suspending certain user accounts that showed strong indicators of malicious activity. It worked with external investigators including Mandiant and, alongside Mandiant, notified around 165 potentially affected organisations through a victim notification programme. Throughout, Snowflake maintained that the breaches resulted from compromised customer credentials rather than a flaw in its platform, and pointed to its shared responsibility model under which customers enforce MFA. It reportedly aimed to conclude its own investigation in mid-June 2024.

• 15. What can organisations learn from the Snowflake cyber attack?

  The Snowflake campaign shows how a single missing control — multi-factor authentication — can expose vast amounts of data across many organisations at once. The key lessons are that MFA should be mandatory on every account holding sensitive data; that credentials stolen by infostealer malware stay dangerous for years unless rotated; that network allow-lists and least-privilege access sharply reduce risk; that third-party and contractor devices are part of your attack surface; and that shared-responsibility models require customers to actively own their side of security. Cyber Management Alliance helps organisations build these capabilities through training,cyber crisis tabletop exercises and incident response planning.