Snowflake’s stolen logins put the contractor’s laptop inside the bank’s perimeter

The week

In mid-May 2024, Santander disclosed unauthorized access to a database hosted by a third-party provider that held information on customers in several countries and on staff. On May 31, Live Nation disclosed in an SEC filing that a third-party cloud database containing Ticketmaster data had been accessed. In the first days of June, Snowflake and incident response firms CrowdStrike and Mandiant said a campaign was targeting customer accounts that used single-factor authentication. They said they had found no vulnerability in or breach of Snowflake’s own platform. On June 10, Mandiant published its findings. A financially motivated actor it tracked as UNC5537 had used credentials stolen by infostealer malware, some dating back to 2020, to access customer instances. Mandiant notified about 165 potentially exposed organizations. The affected accounts lacked multi-factor authentication, and many had no network allow-lists.

Discussion of the campaign quickly settled on shared responsibility: the provider secures the platform, the customer secures its accounts. That framing is correct but too tidy. The weak point sat on devices that belonged to neither the bank nor the provider. Mandiant reported that many of the stolen credentials came from infostealer infections, including on contractor machines also used for personal activity. The attack had three stages, and each was a place where the customer, not Snowflake, held the control: theft of the credential, its use to log in, and extraction of the data.

Theft: where credentials live

An infostealer harvests saved passwords, browser cookies and session tokens from an infected machine and sells them in bulk. It does not need to target a bank. It only needs to land on any device where someone has signed in to the bank’s data platform. A data engineer at a consulting firm may hold access to several clients’ warehouses from one laptop. If that laptop is also used for games or pirated software, one infection exposes every client at once.

Banks govern their own endpoints closely. Contractor and vendor devices usually sit outside that regime, covered at best by contract language and a security questionnaire. The campaign showed that a contractor’s device is effectively part of the bank’s perimeter for whatever that contractor can reach.

Three responses follow. First, require contractors to reach sensitive data platforms only through bank-managed devices or a controlled virtual desktop, so credentials never sit on unmanaged machines. Second, write credential-theft notification into contracts, with a short deadline and an obligation to reset. Third, monitor infostealer log markets for the bank’s domains and platform account names. Commercial services do this, and alerts can shorten a gap between theft and use that in this campaign sometimes ran to years.

Use: what a stolen password can open

A stolen password is only useful if the login accepts it alone. The affected accounts did. Many data platforms were adopted by analytics, marketing or finance teams and set up with local accounts before anyone connected them to the corporate identity provider. Service integrations, early users and contractor accounts kept passwords.

The control is to route every human login through the bank’s identity provider with phishing-resistant MFA, and to remove local password accounts. Where a service account cannot use single sign-on, key-pair or token authentication with narrow permissions and scheduled rotation replaces the password. The difficulty is coverage. The useful test is to ask the platform, not the identity team, which accounts can authenticate without single sign-on. That list is usually longer than the identity team expects.

Network policy adds a second gate. Snowflake and most comparable platforms can restrict logins to known address ranges. Mandiant found many affected accounts had none. An allow-list limited to the bank’s egress addresses and approved vendor ranges would have rejected logins from attacker infrastructure even with a valid password. The trade-off is operational: remote analysts and vendors need stable routes, which pushes access toward the same managed environments recommended above.

Extraction: noticing the data leave

Once inside, the attackers ran queries to find valuable tables and exported data in bulk. That pattern differs sharply from normal analytical work, which reads aggregates and writes results back. Yet several victims appear to have learned of their exposure from outside parties.

Detection on a SaaS data platform depends on the customer collecting the platform’s own logs. Login history, query history and data export or unload events need to reach the bank’s security monitoring. Alerts should cover new locations, unfamiliar client tools, discovery queries against system catalogs, and exports above a set volume. Each alert needs an owner who knows what normal looks like for that platform, often a data engineering lead rather than a security analyst. The bank should then test the alerts by running a controlled bulk export and checking that someone responds.

Regulatory framing reinforces this. The interagency third-party risk guidance of 2023, the Gramm-Leach-Bliley Act safeguards obligations and, for SEC-registered firms, amended Regulation S-P all expect customer information to be protected wherever it is processed. A warehouse full of customer records is a critical system whoever hosts it.

Retention is part of the same question. Platform query logs are kept for a limited period by default, and an investigation that starts months after the theft may find the trail gone. Exporting logs to the bank’s own storage, on the bank’s retention schedule, is what lets it later answer which customers were affected and whether notice is required.

A practical exercise for a bank or broker-dealer takes a few days per platform. List every account that can log in, how it authenticates, from where, and on whose device the credential likely sits. Then check whether a bulk export from each would raise an alert someone would see. The exercise usually surfaces a forgotten integration account, a former contractor or a network policy that was never applied.

With hindsight

The campaign reached well beyond the first disclosures. In July 2024 AT&T disclosed that call and text records of nearly all of its wireless customers had been taken from its Snowflake workspace. Other companies confirmed exposure through 2024, and arrests of people alleged to be involved followed later that year.

The provider side moved too. Snowflake let administrators require MFA for all users in an account, made MFA the default for password sign-ins on new accounts from October 2024, and announced a phased end to single-factor password sign-ins. In October 2025 it revised that schedule, extending final enforcement for human and service users to around October 2026.

Those defaults close the login gap the campaign used. They do nothing for credentials, tokens and sessions harvested from contractor machines, or for exports that nobody monitors. The theft and extraction stages remain the customer’s to control.