Snowflake customer accounts, 2024: old passwords, no MFA

The attack path, step by step

What the published record says happened at each stage, then our reading of it: what would have stopped the step, what would have caught it in progress, and what a test would have shown first.

1. 1

   Step 1. Before first access

   Step 1: Passwords harvested long before they were used

   Mandiant said the credentials were primarily obtained from multiple infostealer malware campaigns that infected systems Snowflake did not own.[1]

   The earliest infostealer infection it associated with a credential the actor used dated back to November 2020.[1]

   In several investigations, the initial infection was on contractor systems that were also used for personal activities, including gaming and downloading pirated software.[1]

   According to Mandiant and Snowflake's analysis, at least 79.7% of the accounts the actor used had prior credential exposure.[1]

   Would have stopped it

   • Rotation of data platform credentials on a schedule and immediately on any leak, so a password stolen years ago no longer works
   • Managed devices for contractors with access to production data, or at least no personal use on the machines that hold those credentials

   Would have caught it

   • Credential-leak monitoring for your own domains, contractors and service accounts

   What a test would have shown

   An assumed-breach test that begins with "here is a password that leaked" is testing something real: what that one credential still opens today.

2. 2

   Step 2. First access

   Step 2: A valid password was enough

   Mandiant named three primary factors. First, the affected accounts did not have multi-factor authentication enabled, so a valid username and password was all a login required.[1]

   Second, credentials found in infostealer output were still valid, in some cases years after they were stolen, because they had not been rotated or updated.[1]

   Third, the affected customer instances had no network allow lists restricting access to trusted locations.[1]

   Mandiant said it found no evidence that the unauthorised access stemmed from a breach of Snowflake's enterprise environment.[1]

   Would have stopped it

   • MFA on every human account on a data platform, ideally through single sign-on from your identity provider rather than local passwords
   • Network policies that accept connections only from your own known addresses

   Would have caught it

   • Alerts on sign-ins from unfamiliar addresses, consumer VPN services and client tools the account has never used

   What a test would have shown

   Configuration review of software-as-a-service data platforms belongs in scope. Whether MFA, allow lists and rotation are actually enforced is quick to check, and it is precisely what this campaign relied on being absent.

3. 3

   Step 3. Moving inside

   Step 3: Reconnaissance with ordinary tools

   Mandiant observed a tool it calls FROSTBITE performing SQL reconnaissance, including listing users, current roles, current IP addresses, session IDs and organisation names.[1]

   It also observed the actor using a publicly available database utility, DBeaver Ultimate, to connect to and run queries across Snowflake instances.[1]

   The actor primarily used Mullvad or Private Internet Access VPN addresses to reach victim instances.[1]

   Would have stopped it

   • Least-privilege roles, so a single login cannot enumerate every user and read every database

   Would have caught it

   • Alerts on queries against account metadata, such as users, roles and sessions, from accounts that do not normally run them
   • Regular review of query history for new client applications

   What a test would have shown

   From a supplied analyst login, a test enumerates what the role can see and read. The gap between what that role needs and what it can reach is the finding.

4. 4

   Step 4. Acting on objectives

   Step 4: Stage, download, then extort

   Mandiant describes the actor staging data in temporary stages and then using the GET command to exfiltrate it to local directories.[1]

   It says the actor advertised victim data for sale on cybercrime forums and attempted to extort many of the victims.[1]

   Would have stopped it

   • Restrictions on who can create stages and download data to local files

   Would have caught it

   • Alerts on temporary stage creation and on large downloads, above all from new addresses

   What a test would have shown

   A test with an agreed data objective shows whether a bulk download from the platform is noticed while it is happening, rather than when the data turns up for sale.