What is Cloud Data Exfiltration and Data Extortion?

Cloud Data Exfiltration is the act of unauthorized access to an organization’s cloud systems and the theft of sensitive data to external locations. Attackers often exploit security weaknesses (for example: leaked credentials, misconfigurations) to access cloud data repositories and exfiltrate large amounts of information. In recent incidents, cybercriminals have targeted cloud data platforms such as Snowflake– a popular cloud data warehouse service – to copy customer data from multiple companies.

Data Extortion is a tactic where attackers use stolen data as “hostages” to demand ransom. Instead of merely encrypting data like traditional ransomware attacks, this type of attack focuses on threatening to publicly disclose or sell sensitive information if the victim does not pay. Their goal is to pressure victims into paying to avoid the consequences of information leakage. Contemporary cybercriminal groups increasingly emphasize data – based extortion because they can directly profit from stolen data without needing to deploy complex encryption malware [1].

The two concepts are closely linked: attackers typically exfiltrate data first and then carry out extortion. Attack campaigns usually follow a sequence: infiltrating systems (especially cloud systems that store large amounts of data), quietly copying data out, and then using that data to threaten businesses or sell it on the black market. A notable example is the campaign targeting Snowflake customers in 2024: Mandiant reported that a criminal group they track, UNC5537, deliberately stole data and extorted victims from customers’ Snowflake databases [2]. he group infiltrated multiple Snowflake accounts belonging to organizations, stole billions of records, advertised the data for sale on cybercrime forums, and simultaneously demanded ransoms from victims in exchange for not publishing the data [2].

Thus, Cloud Data Exfiltration is the stage of data theft, while Data Extortion is the stage of demanding money based on the stolen data. The two often go hand in hand in modern data breach incidents, especially when the victim’s systems are hosted in the cloud—where vast amounts of information are stored and any exposure could cause severe damage.

Overview of the Snowflake Incident Involving Ticketmaster and Santander

Around May 2024, large-scale data breaches related to the Snowflake cloud data platform were exposed. Among the affected organizations, Ticketmaster (a subsidiary of Live Nation) and Santander Bank stood out as prominent victims, highlighting the severity of this attack method. Evidence shows that both Ticketmaster and Santander had their information stolen from their respective Snowflake accounts — as attackers gained direct access to the cloud data repositories using stolen login credentials (username and password). Below are the specific timelines and analyses for each case:

Ticketmaster Incident (2024)

In late May 2024, a hacker group caused a stir when they claimed on underground forums that they had successfully breached Ticketmaster and stolen data belonging to 560 million users of the service [3]. The hackers, who identified themselves as ShinyHunters—a notorious group known for large-scale data thefts—offered the massive data trove for sale on the dark web for $500,000 [3]. Just a few days later, Ticketmaster’s parent company, Live Nation Entertainment, filed a report with the U.S. Securities and Exchange Commission (SEC) confirming that its systems had been accessed without authorization. Specifically, Live Nation acknowledged an intrusion into “a third-party cloud database environment” containing Ticketmaster customer data [3]. Although Live Nation did not name the third-party provider, industry experts quickly identified it as Snowflake, the cloud data platform used by Ticketmaster for data storage and analytics [3].

Scale and Impact: According to statements from the ShinyHunters group, the Ticketmaster breach involved approximately 1.3 TB of data from 560 million customers [4].They claimed the stolen data included complete customer contact details (names, addresses, phone numbers), credit card information, ticket purchase history, and details of booked events [4]. However, in an official announcement on its website, Ticketmaster partially denied these claims. The company stated that the compromised database contained only limited personal information—mainly phone numbers, email addresses, and encrypted credit card details—and did not include sensitive data such as passwords or unencrypted information [4]. Ticketmaster also clarified that the incident affected only customers who purchased tickets in certain markets (the United States, Mexico, and Canada) during a specific time period, rather than all 560 million users worldwide as claimed by the hackers [4]. Nevertheless, given the sheer volume of potentially exposed user data (even if primarily contact and basic transaction information), the breach is still considered one of the largest data compromises in history in terms of the number of affected users [5].

Intrusion Method: Subsequent investigations revealed that the attackers did not exploit any vulnerability within the Snowflake platform itself. Instead, they leveraged compromised login credentials to access Ticketmaster’s Snowflake account. According to a report by Wired, the hackers (identified as ShinyHunters) infiltrated the systems of EPAM Systems—a technology service provider for Ticketmaster and several other Snowflake customers [6].computer belonging to an EPAM employee in Ukraine was reportedly infected with an infostealer malware delivered through a spear-phishing attack, allowing the hackers to install a remote access trojan (RAT) and gain full control of the machine [6]. While exploring the compromised device, the attackers discovered files containing usernames and passwords stored in plaintext, which the employee had used to administer Snowflake accounts for multiple clients—including Ticketmaster [6]. Some of these credentials were even stored directly within Jira, a project management tool, making it even easier for the hackers to collect them [6]. rmed with valid credentials, the attackers logged directly into Ticketmaster’s Snowflake environment, which was not protected by multi-factor authentication (MFA) [6] vrom there, they exfiltrated the entirety of the data stored on Snowflake. Snowflake later confirmed that the attack campaign specifically targeted accounts using single-factor authentication (password-only access) and that the intruders exploited credentials purchased or harvested from infostealer malware [3]. This indicates that the root cause of the breach was the lack of MFA and the prior exposure of login credentials, rather than a flaw in Snowflake’s platform.

Extortion Activity: After stealing the data, the ShinyHunters group proceeded with the extortion phase. On May 27, 2024, the hackers posted an advertisement on a darknet forum, offering Ticketmaster user data for sale and demanding $500,000 in exchange for the 1.3 TB dataset [3]. They implicitly threatened that if no one (including Ticketmaster) purchased the data, it could be publicly released. Within the cybercrime community, ShinyHunters is known as a “data broker”, specializing in collecting, selling, and sharing stolen data. The group has also been known to directly demand ransoms from companies. According to a Wired report, one of the group’s members revealed that they had requested ransoms ranging from hundreds of thousands to over one million dollars from some victims in exchange for deleting the stolen data, rather than selling it to others [6]. It remains unclear whether Ticketmaster received a direct ransom demand, but the company chose to cooperate with law enforcement agencies instead of engaging in private negotiations. The incident also had legal repercussions: numerous customers filed class-action lawsuits against Live Nation/Ticketmaster, accusing the company of negligence in protecting user data and seeking compensation for damages [4].

Santander Incident (2024)

Santander Bank – one of the world’s largest financial institutions—faced a similar situation during the same Snowflake-related attack campaign. On May 14, 2024, Santander issued an official statement acknowledging that it had “recently detected unauthorized access to a Santander database hosted by a third-party provider” [7]. The bank reported that it had promptly blocked access to the compromised database and implemented fraud prevention measures to protect customers [7]. Investigations confirmed that certain customer data from Chile, Spain, and Uruguay had been accessed, along with information about all current employees and some former employees of the bank [7]. Fortunately, Santander emphasized that the affected database did not contain any transactional or banking authentication data (such as online banking passwords or OTP codes), meaning the hackers could not directly perform financial transactions [7]. The bank further clarified that its core operational systems remained unaffected and that no data exposure occurred in markets outside the three mentioned countries [7]. Santander proactively notified impacted customers and employees, reported the breach to regulatory authorities, and cooperated with law enforcement agencies in the ongoing investigation [7].

Scale of stolen data: Although Santander did not disclose exact figures, attackers claimed on underground forums that they obtained information on about 30 million Santander customers [8]. According to an advertisement posted by the ShinyHunters group on June 3, 2024, the data they possessed included bank account details for ~30 million customers, balances for 6 million accounts, roughly 28 million credit card numbers, as well as personnel information about bank employees [8]. The entire data package was offered for $2 million on the forum (approximately £1.6 million). [8]. Notably, the post taunted Santander by saying, “Santander is also very welcome if they want to buy this data back” [8]– an explicit suggestion that the hackers would entertain ransom payments from the bank in addition to selling the data to others. This strongly indicates an extortion motive: pressuring the victim to pay to repurchase their own data

Attack Method and Connection to Snowflake: Similar to the Ticketmaster case, Santander confirmed that the compromised database was hosted by a third-party provider. Although the bank did not disclose the name, security analysts have linked the incident to the Snowflake breach that occurred around the same time. In fact, activity observed on hacker forums indicated that the Santander data being sold was directly connected to the Snowflake incident: Evidence from hacker forums indicated a direct connection the initial post offering Santander’s stolen data appeared on the Exploit forum on May 23, 2024, by a user named “whitewarlock”—coinciding with Snowflake’s public disclosure of its ongoing incident investigation. A week later, on May 30, the ShinyHunters group reposted (mirrored) the same data leak announcement on BreachForums to attract wider attention [9]. The hackers claimed they had accessed a Snowflake account belonging to a third-party partner storing Santander’s data—using the same infiltration method employed in the Ticketmaster breach. According to Wired, independent verification confirmed that Santander’s data had indeed been stolen from its own Snowflake account, although the bank declined to officially confirm this detail [6]. This strongly suggests that the attackers obtained valid login credentials to Santander’s Snowflake environment—possibly through the same EPAM Systems compromise or via other infostealer logs—and subsequently exfiltrated the customer data. The attackers exploited accounts that lacked multi-factor authentication (MFA) and used previously exposed passwords, consistent with the broader UNC5537 campaign [2].

Extortion Activity: Shortly after Santander publicly disclosed the incident in mid-May, the hacker group quickly moved to the extortion phase. As mentioned earlier, on June 3, 2024, they advertised the data of 30 million customers for sale at a price of $2 million, even tauntingly inviting the bank to “buy it back” themselves [8]. Around that time, both the Financial Times and The Guardian reported that ShinyHunters were auctioning Santander’s stolen data on underground forums [8]. Around that time, both the Financial Times and The Guardian reported that ShinyHunters were auctioning Santander’s stolen data on underground forums [8]. Santander told the media that it would not comment on what was being described as “one of the largest banking breaches in history,” and reaffirmed its cooperation with authorities instead of negotiating with criminals [8]. ĐBy June 6, 2024, cybersecurity observers noticed that ShinyHunters suddenly removed their post advertising the Santander data, with no clear explanation—raising speculation about whether an undisclosed settlement had been reached or if other factors were involved [9]. There has been no public confirmation that Santander paid any ransom. Some sources suggested the hackers might have sold the data to a third party or that Santander’s countermeasures (such as a honeypot operation or law enforcement intervention) prompted the removal. In any case, the incident served as a critical warning to the financial sector about the risks of storing sensitive customer data on external cloud infrastructure—where even a single lapse in security can expose tens of millions of customer records.

Impact: For Santander, the immediate consequences involved significant damage to its reputation and customer trust in the affected markets. Although the bank emphasized that the exposed data could not be used to steal money directly, the leaked personal and account details could still facilitate fraud and phishing attacks targeting customers. Santander publicly reassured users that it would never ask for passwords or OTP codes, and urged them to remain vigilant against any suspicious communications impersonating the bank [7]. Financially, no official loss figures have been disclosed. However, if the stolen data were indeed sold or leaked, Santander could face regulatory fines and lawsuits in jurisdictions where customer data was compromised, due to potential violations of data protection laws. Alongside the Ticketmaster breach, this incident contributed to making 2024 a landmark year for massive cloud-based data breaches, with hundreds of millions of user records compromised worldwide[5].

Analysis of Defense Measures: MFA, Anomaly Monitoring, and Cloud Access Control

The attacks on Ticketmaster, Santander, and several other organizations through Snowflake revealed that the main vulnerabilities lay in identity and access security. Below is an analysis of the role of key defense measures in preventing similar attacks:

Multi-Factor Authentication (MFA)

Enforcing Multi-Factor Authentication (MFA) for cloud service accounts can prevent most attacks that rely on stolen login credentials. In the 2024 Snowflake campaign, Mandiant concluded that the majority of compromised accounts did not have MFA enabled. As a result, attackers could successfully log in using only a valid username and password[2]. This was the primary factor behind the success of the attack.If Ticketmaster, Santander, and other victims had implemented MFA for their Snowflake accounts, hackers would not have been able to gain access simply by using credentials obtained online or from employees’ devices. For example, in the EPAM case, even though the attackers had the Snowflake username and password belonging to Ticketmaster, they would have been blocked if the account had required a one-time password (OTP) or confirmation through a secondary device that the hackers did not possess. Snowflake confirmed that the compromised accounts were “password-only accounts, not using Okta or MFA” — unlike Snowflake’s internal systems, which require SSO/MFA for all access[3]. The key takeaway is that organizations must enable MFA for all cloud accounts, especially administrative and data warehouse access accounts. MFA adds an additional layer of defense, significantly reducing the likelihood that an attacker can log in even if they have obtained the password.

Anomaly Detection and Intrusion Monitoring

Monitoring user behavior and access patterns in cloud systems plays a crucial role in the early detection of suspicious activities—often the first indicators of unauthorized access. In recent incidents, the time between initial compromise and detection was relatively long (in some cases, over a month) due to the absence of early warnings [4]. With an effective anomaly detection solution in place, Ticketmaster could have identified irregular signs such as: an employee or partner account suddenly logging in from an unusual IP address or outside normal working hours, followed by executing massive download queries — actions inconsistent with typical behavior. Establishing anomaly indicators (e.g., query rate, volume of data exported, login location, or device fingerprint) and integrating real-time alerts enable security teams to respond promptly and minimize potential damage. In fact, after the breach, Snowflake worked with Mandiant to develop forensic and anomaly detection guidance for Snowflake customers. This guidance included specific query templates to detect unusual or malicious activity within Snowflake logs over the past year [2]. This demonstrates that monitoring logs and applying anomaly detection algorithms are both feasible and essential. Moreover, organizations should implement SIEM systems or UEBA (User and Entity Behavior Analytics) tools to automatically analyze behavioral patterns and trigger alerts for suspicious anomalies. For example, a typical customer account would not download hundreds of millions of records at once; if such an event occurs, automated alerting systems can help stop data exfiltration before it completes.

Cloud Provider Access Control

In the cloud service model, security responsibility is shared between the customer and the provider. Cloud providers (such as Snowflake) typically offer robust access control tools — but it is up to customers to configure and use them correctly. A key lesson from the 2024 campaign is that many organizations failed to fully leverage the access controls Snowflake provided, leaving exploitable gaps for attackers. Specifically, Mandiant noted that the compromised Snowflake accounts had not enabled network policies restricting access by IP address [2]. Snowflake allows customers to configure an IP allow list so that only connections from the organization’s trusted networks are accepted. In this case, if Ticketmaster or Santander had restricted their Snowflake accounts to allow logins only from corporate or VPN IP addresses, hackers would have been unable to log in from public internet locations even with valid credentials. The absence of network allow lists (which effectively permitted access from anywhere) was the third major factor contributing to the account compromises [2]. Therefore, enterprises must work closely with their cloud providers to enable available access control mechanisms: from IP and device restrictions to more advanced conditional access policies.

Additionally, organizations should integrate their own identity management systems with cloud services. Snowflake supports SSO integration through SAML/OAuth (e.g., with Okta or ADFS), allowing corporate authentication policies (including MFA and device verification) to apply to Snowflake accounts. Within Snowflake’s internal systems, the company confirmed that all production accounts are protected by Okta + MFA, ensuring that leaked employee demo accounts (without MFA) did not affect production environments [3]. The key takeaway is to segment environments and tightly control administrative accounts. Accounts used for demo or testing purposes should have restricted access to sensitive data and always include additional protection layers. Cloud providers should assist customers in enabling these security features and where possible, set them as defaults (for example, requiring MFA when creating new accounts or providing alerts if an account lacks a network policy,…).

Furthermore, the provider’s own internal access control must not be overlooked. Some reports indicated that attackers claimed to have accessed Snowflake’s internal systems (a former employee’s demo account) [8]. Although Snowflake denied any compromise at the system level, the incident underscores the importance of providers enforcing strict management of employee accounts (particularly those with customer support privileges). Under the Zero Trust model, both customers and cloud providers must continuously monitor and limit privileged access to reduce overall risk.

Lessons and Recommendations for Organizations Using Cloud Services

The incidents involving Ticketmaster and Santander serve as a wake-up call for all organizations using cloud services — especially large-scale data platforms like Snowflake. Below are key lessons learned and specific recommendations to strengthen security:

• Enable Multi-Factor Authentication (MFA) Everywhere: All user and service accounts on the cloud should be protected by MFA or secure SSO. This is the most effective defense against unauthorized access using stolen passwords [2]. Administrative accounts and those containing sensitive data must have MFA enabled without exception.
• Strictly Manage and Rotate Credentials: Organizations should enforce password rotation policies and immediately revoke any exposed credentials. In the Snowflake campaign, many stolen passwords from as far back as 2020 were still valid in 2024 because they had never been changed [2]. Password reuse across services must be avoided. Companies should use password managers and implement centralized authentication (SSO) to simplify access provisioning and revocation.
• Apply the Principle of Least Privilege: Grant only the minimum level of access necessary within cloud systems. Regularly review service and partner accounts to determine whether they truly need full access to all data. For example, Ticketmaster could have segmented its data warehouse by region or restricted EPAM’s access to a limited subset of data. This way, even if one account were compromised, the potential damage would be contained.
• Enable Network and Conditional Access Controls: Leverage features such as Network Policies on Snowflake (or equivalent controls on other platforms) to restrict access by IP range, time, and location. Only allow cloud service access from corporate networks, VPNs, or secure proxies. Configure conditional access policies — for instance, requiring VPN connections when logging in from outside the office or blocking logins from unfamiliar countries — to minimize the risk of external compromise [2].
• Continuous Monitoring and Early Anomaly Detection: Deploy security monitoring solutions for cloud services (e.g., Cloud SIEM or log analytics). Enable full logging on Snowflake and set threshold-based alerts for unusual events such as multiple failed logins, large data export queries, new user creation, or security configuration changes. Use machine learning to identify abnormal user behaviors. Mandiant has published sample queries for detecting suspicious activities in Snowflake – organizations should review and adapt these for their own systems [2].
• Risk Assessment and Third-Party Management: Many breaches occur through third parties (as seen in the EPAM case). Therefore, organizations must assess the security posture of vendors and partners with access to their systems or data. Ensure that they also follow strict security standards (e.g., MFA enforcement, malware-free devices, no plaintext password storage). Partner accounts should have limited privileges, and their activities should be continuously monitored. When possible, implement Privileged Access Management (PAM) for third parties — granting temporary access and automatically revoking it after tasks are completed, instead of maintaining long-term static accounts.
• Segregate Environments and Sensitive Data: Following Snowflake’s example — which isolates its demo environment from production and enforces stricter controls in production [3]. Organizations should classify their data (sensitive vs. non-sensitive) and store it in separate accounts or systems. This ensures that if one environment is compromised, the damage does not spread across the entire infrastructure. Sensitive data should also be encrypted at the field level when stored in the cloud, so that even if attackers obtain the data, they cannot use it without the decryption keys.
• Prepare an Incident Response and Extortion Plan: Organizations must have a well-defined plan for handling data breaches and extortion scenarios. This plan should include procedures for notifying customers and authorities, isolating compromised systems, conducting forensic investigations to identify vulnerabilities, and outlining negotiation (or non-negotiation) strategies with attackers. Teams should regularly conduct tabletop exercises simulating ransomware or extortion incidents to ensure management can respond effectively under pressure. For instance, in the Snowflake case, attackers allegedly demanded $20 million from Snowflake itself in exchange for not leaking the data of roughly 400 organizations[3]. Such situations are complex to manage; therefore, predefining a ransom policy and coordinating with legal counsel and law enforcement is essential.
• Do Not Be Complacent About Cloud Security: Ultimately, the overarching lesson is that cloud computing does not guarantee security by default — responsibility still lies with the customer. Organizations should regularly assess their cloud security configurations (following frameworks such as CIS Benchmarks), apply timely patches to servers connected to cloud environments, and monitor security advisories from their providers. As experts have emphasized, the 2024 Snowflake incident demonstrates that “identity is the new perimeter” [5]in the cloud era: instead of relying on physical firewalls, identity and credential management now form the core defense layer. Therefore, investing in strong identity governance, educating employees to avoid credential-stealing malware, and adopting the Zero Trust principle will help organizations remain resilient against the growing wave of data exfiltration and extortion attacks.

References: The information in this report is compiled from reputable sources, including Mandiant/Google Cloud security blogs [2], reports from the Cloud Security Alliance [10],in-depth articles from Wired [6], SecurityWeek [3], Banking Dive [8], as well as official press releases from Santander [7] and statements from Ticketmaster. These real-world incidents offer valuable lessons on the threats of Cloud Data Exfiltration & Data Extortion and how organizations can better prevent them in the future.

References

[1] ]The Shift from Ransomware to Data Theft Extortion|  https://www.blackfog.com/shift-from-ransomware-to-data-theft-extortion/

[2] UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion | Google Cloud Blog, https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion

[3] Snowflake Data Breach Impacts Ticketmaster, Other Organizations – SecurityWeek, https://www.securityweek.com/snowflake-hack-impacts-ticketmaster-other-organizations/

[4] Ticketmaster Data Breach: What Happened and How to Prevent It, https://www.strongdm.com/what-is/ticketmaster-data-breach

[5] Snowflake: Looking back on 2024’s landmark security event, https://pushsecurity.com/blog/snowflake-retro/

[6] Hackers Detail How They Allegedly Stole Ticketmaster Data From Snowflake | WIRED, https://www.wired.com/story/epam-snowflake-ticketmaster-breach-shinyhunters/

[7] Santander Statement, https://www.santander.com/en/stories/statement

[8] Hackers threaten to sell Santander customer details for $2M: report | Banking Dive, https://www.bankingdive.com/news/hackers-breach-santander-customer-data-threaten-sell-2-million-ticketmaster-snowflake-shinyhunters/717807/

[9] Overview of the Snowflake Breach: Threat Actor Offers Data of Cloud Company’s Customers – SOCRadar® Cyber Intelligence Inc, https://socradar.io/overview-of-the-snowflake-breach/

[10] Unpacking the 2024 Snowflake Data Breach | CSA, https://cloudsecurityalliance.org/blog/2025/05/07/unpacking-the-2024-snowflake-data-breach