Santander and the Snowflake Breach: When Your Data Platform Becomes the Attack Vector
The Credential That Unlocked Everything
In the spring of 2024, a cluster of threat actors operating under overlapping identities — tracked by Mandiant as UNC5537, with links to the Scattered Spider and ShinyHunters groups — executed one of the most consequential data breach — adding to the ENISA threat landscapees in recent financial sector history. They did not exploit a zero-day vulnerability. They did not develop novel malware. They did not compromise a hyperscaler's core infrastructure. They used stolen credentials.
The attack vector was deceptively simple. Infostealer malware — commodity malware families like Vidar, Raccoon, and RedLine that harvest browser-stored credentials, cookies, and session tokens — had been distributed widely through phishing campaigns and malicious downloads in the months prior. Among the credentials harvested were login details for Snowflake, the cloud data warehousing platform used by hundreds of large enterprises including Santander, Ticketmaster (Live Nation), Advance Auto Parts, and AT&T.
With valid Snowflake credentials in hand, the attackers logged into target organizations' Snowflake environments, queried data warehouses, and exfiltrated customer and employee data. For Santander, the breach exposed customer information across three markets — Chile, Spain, and Uruguay — along with records of 12,786 employees. The attackers then attempted to sell the stolen data on criminal marketplaces.
The arrests came in October 2024, when Canadian law enforcement apprehended Alexander "Connor" Moucka, a key member of the operation. But by that point, the data had been exfiltrated, offered for sale, and the reputational and regulatory consequences were already in motion.
Why Snowflake Matters
Snowflake is not a niche product. It is one of the dominant cloud data warehousing platforms globally, with over 9,000 customers including a significant concentration of financial services institutions. Snowflake's value proposition — centralizing organizational data for analytics, business intelligence, and machine learning — means that a Snowflake environment often contains the most comprehensive and sensitive data an organization possesses. Customer records, transaction histories, employee data, financial performance metrics, and operational analytics all flow into the data warehouse.
This makes Snowflake environments extraordinarily high-value targets. Compromising a single Snowflake credential can provide access to terabytes of structured, queryable data — data that would take months to locate and exfiltrate if scattered across dozens of operational systems, but that sits neatly organized in a data warehouse designed for fast, efficient querying.
The Santander breach illustrates a structural risk that DORA's drafters anticipated: the centralization of data for analytical purposes creates concentration risk that differs in character from operational system risk. A core banking system contains transaction data. A data warehouse contains everything — transactions, customer profiles, employee records, business analytics, and often data from multiple business units and geographies aggregated into a single queryable repository.
The Attack Chain in Detail
| Phase | Technique | Duration | DORA relevance |
|---|---|---|---|
| 1. Credential harvest | Infostealer malware (Vidar, Raccoon, RedLine) via phishing/drive-by | Months prior to breach | Art. 9(1): Protection and prevention measures for ICT systems |
| 2. Credential validation | Automated testing of stolen credentials against Snowflake login endpoints | Days to weeks | Art. 9(3): Authentication mechanisms, access controls |
| 3. Initial access | Login with valid credentials (no MFA required) | Minutes | Art. 9(3)(b): Strong authentication for critical data access |
| 4. Data reconnaissance | Querying Snowflake metadata to identify valuable tables | Hours | Art. 10: Detection, anomalous activity monitoring |
| 5. Data exfiltration | Bulk export of customer/employee data | Hours to days | Art. 10(1): Mechanisms to detect anomalous activities |
| 6. Extortion/sale | Data offered on criminal marketplaces | Post-exfiltration | Art. 17: Incident management, Art. 19: Reporting |
The critical observation: every phase of this attack was detectable and preventable with controls that DORA explicitly requires.
The MFA Gap
The most discussed aspect of the Snowflake breach was the absence of mandatory multi-factor authentication. At the time of the attacks, Snowflake did not enforce MFA by default — it was available as an option but not required. Many customers, including those in the financial sector, had not enabled MFA for all Snowflake users.
DORA Art. 9(3) requires financial entities to implement "strong authentication mechanisms, based on relevant standards and dedicated control systems, and protection measures of cryptographic keys." For access to a data warehouse containing customer PII, financial data, and employee records across multiple geographies, single-factor authentication (username and password) does not meet this standard — regardless of what the third-party platform's default configuration allows.
This is a critical distinction: DORA places the obligation on the financial entity, not on the third-party service provider. Snowflake offering MFA as an option does not satisfy the requirement. The financial entity must ensure that MFA is enabled and enforced for access to data classified as sensitive — which, for a data warehouse containing customer records and financial data, is unambiguous.
The Detection Gap
The attackers accessed Snowflake environments, ran queries against data warehouses, and exported large volumes of data. For an organization with proper anomaly detection on its data platform (Art. 10), several indicators should have triggered alerts:
- Login from unusual IP addresses or geographies
- Access outside normal business hours
- Queries against tables not typically accessed by the compromised account
- Bulk data export operations exceeding normal patterns
- Sequential access to high-value tables (customer records, employee records, financial data)
DORA Art. 10(1) requires financial entities to have "mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents." A data warehouse where terabytes of customer data can be queried and exported without triggering any alert has a detection gap that Art. 10 explicitly addresses.
The Third-Party Risk Dimension
The Snowflake breach is simultaneously an Art. 9 (protection and prevention) failure and an Art. 28 (third-party risk) challenge. Snowflake is an ICT third-party service provider. The financial entity's data resides on Snowflake's infrastructure, is processed by Snowflake's compute engine, and is accessed through Snowflake's authentication system.
Under Art. 28(1)(a), financial entities must "identify and assess all risks in relation to contractual arrangements on the use of ICT services." For a Snowflake deployment, this assessment must include:
Data classification risk. What data is stored in Snowflake? If customer PII and financial data are present, the data classification is high — and the security requirements must match. A data warehouse configured with the same access controls as a development sandbox creates a classification mismatch that Art. 9(4) addresses.
Authentication and access control risk. Does the platform enforce the authentication standards required by the entity's security policy? If MFA is optional and not all users have it enabled, this is a known risk that must be assessed and remediated — not accepted by default.
Detection and monitoring risk. Can the entity detect anomalous access to its data on the third-party platform? If Snowflake's native monitoring is insufficient, can the entity integrate Snowflake audit logs with its own SIEM for anomaly detection?
Data residency and sovereignty risk. Where is the data physically stored? For Santander, customer data from Chile, Spain, and Uruguay was accessible through a single platform. Art. 30(2)(c) requires contractual specification of "the locations where data is to be processed."
| Risk dimension | Assessment question | Santander-Snowflake gap | DORA requirement |
|---|---|---|---|
| Authentication | Is MFA enforced for all data warehouse users? | MFA not mandatory at time of breach | Art. 9(3) |
| Data classification | Is data warehouse access tiered by sensitivity? | Broad access to customer + employee data | Art. 9(4) |
| Anomaly detection | Can unusual query patterns be detected and alerted? | No alert on bulk exfiltration | Art. 10(1) |
| Access governance | Are credentials regularly rotated and monitored? | Stolen credentials worked for extended period | Art. 9(3) |
| Data residency | Are multi-geography data stores separately governed? | Chile/Spain/Uruguay data in single environment | Art. 30(2)(c) |
The Supply Chain Dimension
The Snowflake breach was not an isolated incident — it was a campaign. Over 165 organizations were targeted using stolen Snowflake credentials. This transforms the incident from a bilateral third-party risk issue into a systemic supply chain event.
From DORA's perspective, this triggers Art. 29's concentration risk provisions. When hundreds of financial and non-financial entities store their most sensitive data on a single platform, a vulnerability in that platform (even a configuration vulnerability like absent MFA enforcement) creates correlated risk across the entire customer base. The Snowflake campaign demonstrates that concentration risk applies not only to infrastructure providers (AWS, Azure) but to specialized data platform providers that aggregate sensitive data from multiple sectors.
Art. 45-49 (Pillar V, Information Sharing) is also relevant. The Snowflake campaign was identified through collaborative threat intelligence sharing — Mandiant's investigation connected the dots across multiple victims. Financial entities that participate in threat intelligence sharing arrangements (ISACs, CERT-EU, sector-specific CTI groups) would have received early warning of the Snowflake credential campaign, enabling proactive defensive measures (credential resets, MFA enforcement, enhanced monitoring) before their own environments were compromised.
Lessons for Financial Entities
Lesson 1: Treat Data Platforms as Critical ICT Infrastructure
A data warehouse is not a reporting tool. It is a repository of the organization's most valuable and sensitive data. Security governance must match this classification: mandatory MFA, role-based access control, anomaly detection, regular access reviews, and integration with the entity's SIEM.
Lesson 2: Enforce Your Standards on Third-Party Platforms
DORA Art. 9 places the obligation on the financial entity. If your security policy requires MFA for access to customer data, that policy must be enforced on every platform where customer data resides — including third-party SaaS platforms. The platform's default configuration is irrelevant; the entity's security requirements are the standard.
Lesson 3: Monitor the Data Layer, Not Just the Network Layer
Traditional security monitoring focuses on network perimeter, endpoint, and application layers. The Snowflake breach exploited none of these — the attackers logged in with valid credentials through the legitimate front door. Detection required monitoring at the data layer: who is accessing what data, when, from where, and how much.
Lesson 4: Credential Hygiene Is a Third-Party Risk Issue
The credentials stolen by infostealers were not Snowflake's fault. They were harvested from employee devices through separate malware campaigns. But the consequence — unauthorized access to a critical data platform — makes credential hygiene a third-party risk management issue. Art. 9(1) requires protection measures that address the realistic threat landscape, which includes commodity credential theft.
Lesson 5: Data Warehouses Need Exit Strategies Too
Art. 28(8) requires exit strategies for critical ICT services. If your data warehouse is classified as supporting a critical or important function — and any data warehouse containing customer PII and financial data should be — a credible exit strategy must address: data export in a usable format, alternative platform identification and pre-qualification, migration timeline, and testing of the migration procedure.
The Santander-Snowflake breach is a lesson in the risk of centralization. The same properties that make data warehouses valuable — comprehensive data, fast querying, centralized access — make them extraordinarily high-value targets. DORA's framework of protection (Art. 9), detection (Art. 10), third-party risk management (Art. 28), and concentration assessment (Art. 29) provides the governance structure to manage this risk. The question is whether financial entities will apply these requirements to their data platforms with the same rigor they apply to their core banking systems.
This analysis references the Snowflake credential-based breach campaign of 2024, affecting Santander and over 165 other organizations, mapped to DORA Regulation (EU) 2022/2554 requirements. Threat actor attribution is based on Mandiant's published investigation.