Santander/Snowflake Breach: When Your Cloud Data Platform Becomes the Entry Point

The 160-Organization Campaign

The Santander breach must be understood within the context of the broader Snowflake credential theft campaign, which compromised approximately 160 organizations and represents one of the most impactful cloud data platform attacks in history.

The infostealer economy. The campaign exploited a mature and industrialized cybercriminal economy around infostealer malware. Infostealers like Lumma, RedLine, Raccoon, and Vidar are sold as commodity tools on dark web marketplaces, often on a subscription basis. They infect individual users' machines — typically through phishing emails, malicious downloads, or compromised websites — and harvest all stored credentials, session tokens, cookies, and authentication data. The harvested credentials are then aggregated in "logs" and sold in bulk on criminal marketplaces, where purchasers can search for credentials associated with specific high-value targets.

The shared responsibility gap. Snowflake operates under a shared responsibility model where the platform provider secures the infrastructure and the customer secures access management. At the time of the campaign, Snowflake did not mandate multi-factor authentication (MFA) for its customer environments. Organizations that deployed Snowflake without enforcing MFA on all user accounts — relying on username/password authentication alone — were vulnerable to credential theft attacks. Following the campaign, Snowflake announced mandatory MFA as a default configuration.

Cross-border data exposure. Santander's Snowflake environment contained data from multiple countries — Chile, Spain, and Uruguay — reflecting the bank's global operations and the centralized nature of cloud data platforms. This cross-border data aggregation created a single point of compromise that simultaneously affected multiple regulatory jurisdictions. Under DORA Art. 19, the cross-border nature of the data exposure would trigger reporting obligations to multiple NCAs — the Spanish CNMV and Banco de Espana for the EU dimension, plus Chilean and Uruguayan regulators for non-EU affected territories.

Employee data exposure. The compromise of 12,786 employee records adds an additional risk dimension. Employee data — including potentially role descriptions, organizational hierarchy, contact details, and system access information — can be used for social engineering attacks, business email compromise, and lateral movement within the organization. The employee data exposure creates residual risk that persists long after the initial breach is contained.

The UNC5537 threat actor profile. Mandiant's analysis attributed the campaign to UNC5537, a financially motivated threat actor cluster with connections to the Scattered Spider social engineering group and ShinyHunters data theft marketplace. The actor demonstrated a systematic approach: harvest credentials via infostealers, filter for high-value cloud platform access, authenticate using stolen credentials, and exfiltrate data at scale. The industrialized nature of this attack chain — requiring no exploitation of platform vulnerabilities — makes it reproducible against any cloud platform where single-factor authentication is used.

Credentials as the Weakest Link

In mid-2024, Santander — one of Europe's largest banks by assets, operating across multiple continents — confirmed that customer and employee data had been compromised through unauthorized access to a third-party cloud data platform. The breach, subsequently attributed to threat actors tracked as UNC5537 by Mandiant (with connections to the Scattered Spider and ShinyHunters groups), exploited stolen credentials for Santander's Snowflake data warehouse environment.

The attack chain was deceptively simple. Infostealer malware — commodity malware designed to harvest credentials, session tokens, and browser data from infected computers — had compromised the credentials of users with access to Santander's Snowflake environment. The threat actors then used these stolen credentials to authenticate to Snowflake's platform, bypassing network-level controls by logging in through the legitimate cloud API. Once inside the data warehouse, they exfiltrated data covering customers in Chile, Spain, and Uruguay, as well as records of 12,786 Santander employees.

The Santander breach was not isolated. According to Mandiant's investigation, published in collaboration with Snowflake and CrowdStrike, the same threat actors compromised approximately 160 organizations through stolen Snowflake credentials during the same campaign. The campaign was not a vulnerability in Snowflake's platform itself but rather a credential hygiene problem: organizations had deployed Snowflake environments accessible with single-factor authentication, and the credentials had been harvested from individual users' machines via infostealer malware. Snowflake itself was not breached — the organizations' credential management practices were the vulnerability.

The arrests followed in October 2024, when Canadian law enforcement apprehended an individual linked to the campaign. However, the damage was done: Santander's customer data across three countries had been exfiltrated, employee records were compromised, and the bank faced regulatory notification obligations in multiple jurisdictions.

For DORA observers, the Santander/Snowflake breach illustrates a critical gap in traditional third-party risk assessment: the security of a cloud data platform depends not only on the platform's own security posture but on the credential management practices of every user who accesses it. DORA Art. 9's requirements for protection and prevention, combined with Art. 28's third-party risk management obligations, directly address this hybrid vulnerability.

DORA's Protection and Third-Party Framework

The Santander/Snowflake breach maps onto DORA's framework across two primary dimensions: the institution's own access management practices (Pillar I) and the third-party risk management obligations related to cloud data platforms (Pillar IV).

Pillar I: ICT Risk Management — Art. 9 Protection and Prevention

Art. 9(4)(a) — Access management: DORA requires financial entities to implement access management policies that include "strong authentication mechanisms." The use of single-factor authentication for a cloud data platform containing customer data from three countries and employee records would be difficult to justify under this requirement. MFA is the minimum standard for any system containing sensitive financial data — and DORA makes this obligation explicit.

Art. 9(4)(c) — Awareness and training: The infostealer attack vector — malware delivered through phishing or malicious downloads — targets individual users. DORA requires financial entities to maintain "digital operational resilience awareness programmes" for all staff. Effective anti-infostealer awareness training would include recognition of phishing attempts, safe browsing practices, and the risks of storing credentials in browsers on devices that access cloud platforms.

Art. 9(2) — ICT system resilience: The centralization of multi-country customer data in a single Snowflake environment without adequate access controls created unnecessary concentration of data exposure risk. DORA's requirement for resilient ICT systems implies that data architectures should minimize the blast radius of a single credential compromise — through data segmentation, per-country access controls, or architectural boundaries that limit the scope of any single authentication session.

Pillar IV: Third-Party Risk Management — Art. 28

Art. 28(1) — Integrated risk management: Snowflake, as the cloud data platform hosting sensitive customer and employee data, falls within DORA's definition of an ICT third-party service provider. The security of the Snowflake environment is not solely Snowflake's responsibility — the financial entity must assess and manage the risk arising from the arrangement, including the risk that inadequate access controls on the financial entity's side could compromise the platform.

Art. 28(5) — Pre-contractual assessment: A pre-contractual assessment of the Snowflake arrangement should have included an analysis of the platform's authentication requirements, the shared responsibility model, and the risk of credential theft as an attack vector. The fact that Snowflake did not mandate MFA at the time should have been identified as a risk requiring compensating controls (institution-mandated MFA, IP whitelisting, session management).

Art. 28(3) — Register of Information: Snowflake should appear in the financial entity's register of information as an ICT third-party provider, with documentation of the data types stored, the countries covered, and the access management configuration. This register entry would make the concentration of cross-border customer data on a single platform visible for risk assessment purposes.

Cross-Border Dimension — Art. 19

The multi-country data exposure — Chile, Spain, Uruguay — triggers incident reporting obligations under DORA Art. 19 for the EU component (Spain) and potentially under local regulations for the non-EU components. The cross-border nature complicates the incident management process because each jurisdiction may have different classification criteria, notification timelines, and regulatory expectations.

Aftermath and Cloud Data Governance Lessons

The Santander/Snowflake breach triggered responses at the platform level, the institutional level, and the broader industry level that carry direct implications for DORA implementation.

Platform Response

Following the campaign affecting 160+ organizations, Snowflake announced a series of security enhancements:

• Mandatory MFA: Snowflake moved to require MFA by default for all customer environments, closing the authentication gap that the campaign exploited.
• Enhanced session management: Additional controls on session duration, concurrent sessions, and session token handling.
• Credential monitoring: Integration with threat intelligence feeds to detect compromised credentials in dark web marketplaces.

These changes represent the platform's acknowledgment that the shared responsibility model requires minimum security baselines that the platform itself enforces, rather than leaving all access management decisions to the customer.

Institutional Implications for Santander

Santander faced regulatory notification obligations in three countries, customer remediation across three customer bases, and internal security remediation for the 12,786 employees whose records were compromised. The cross-border nature of the data exposure meant that the bank's incident response had to coordinate across its Spanish, Chilean, and Uruguayan operations — each with different regulatory timelines and requirements.

The employee data exposure created a persistent secondary risk: compromised employee information enables targeted social engineering attacks against the bank itself. Santander's post-breach remediation would have included credential rotation for all affected employees, enhanced monitoring for social engineering attempts, and potentially re-issuance of access credentials for systems referenced in the compromised employee records.

Arrests and Law Enforcement

The October 2024 arrest in Canada of an individual linked to the UNC5537 campaign demonstrated that law enforcement engagement can produce results even in complex, multi-jurisdictional cybercrime cases. However, the arrests came after the data had been exfiltrated — reinforcing that law enforcement response is a complement to, not a substitute for, preventive security controls.

Structural Lessons for DORA Implementation

1. MFA is non-negotiable for cloud data platforms. DORA Art. 9(4)(a) requires "strong authentication mechanisms." For any cloud platform hosting customer or employee data, MFA is the minimum implementation of this requirement. Single-factor authentication for cloud data platforms should be treated as a material control deficiency in DORA compliance assessments.

2. Cloud shared responsibility models require explicit assessment. The shared responsibility model — where the provider secures the platform and the customer secures access — creates a gap that threat actors deliberately target. DORA Art. 28(5) pre-contractual assessment must explicitly evaluate the shared responsibility boundary and identify where the financial entity must implement its own controls to close gaps in the provider's default configuration.

3. Data platform concentration amplifies breach impact. Centralizing multi-country customer data on a single cloud data platform creates a high-value target with maximum blast radius. DORA Art. 9(2) resilience requirements should inform data architecture decisions — including whether to segment data by jurisdiction, restrict access scopes, or implement additional encryption layers for cross-border data aggregation.

4. Infostealer defense is an institutional responsibility. The attack vector — infostealer malware on individual users' machines — bypasses all network and platform security controls. Defense requires endpoint security (EDR), credential monitoring, user awareness training, and architectural controls (MFA, session management, IP restrictions) that limit the impact of credential compromise. DORA Art. 9(4)(c) awareness programmes must specifically address the infostealer threat.

5. Cross-border data exposure creates multi-jurisdictional reporting obligations. Financial institutions using cloud data platforms for multi-country operations must pre-define incident response procedures that satisfy reporting requirements in all affected jurisdictions simultaneously. Under DORA, this means pre-mapping the regulatory notification requirements for every country whose data resides on the platform.