Most orgs don’t lose data because of some exotic zero-day. They lose it because one basic control wasn’t mandatory. In the Snowflake customer account break-ins, attackers used infostealer-stolen usernames and passwords to get into Snowflake accounts that didn’t have MFA turned on . From there, it scaled to at least 165 organizations, terabytes of stolen data, and real-world extortion . If your MFA policy has “exceptions,” or you rely on “we told people to enable it,” this is your wake-up call.
How the Snowflake pattern worked (and why it’s so repeatable)
The Snowflake customer account break-ins didn’t start with some fancy exploit. They started with infostealer-stolen credentials and one missing checkbox: MFA not enforced. Court docs described a straight line from “valid username + password” to “logged into a Snowflake tenant,” because without multi-factor authentication, the attacker only needed the correct login.
Here’s the repeatable chain that made this scale across org after org:
- Infostealer malware harvests logins
- Credentials get lifted from infected endpoints (personal laptops, contractor machines, unmanaged devices) and end up for sale or traded.
- The attacker doesn’t have to guess anything. They just try known working pairs against Snowflake accounts that don’t require MFA.
- No MFA → “normal” interactive login
- Once the password works, the access looks like any other user sign-in unless you’re watching closely.
- That’s why this gets missed: teams think “cloud data warehouse breach” and look for platform flaws, when it’s really an access hygiene failure.
- Tenant reconnaissance (the quiet part)
- After login, the attackers used the access to identify valuable information inside the environment—things like organization name, user roles, and IP addresses.
- That’s not trivia. Roles tell them what they can read. Org details help with targeting and extortion. IP info helps them blend in or spot weak network controls.
- Automation to pull data at speed
- Court filings described the use of custom software to do the identifying and extraction work, which is how “one compromised account” turns into repeatable Snowflake data exfiltration across many tenants.
What makes this pattern scary isn’t creativity—it’s how ordinary it is. One forgotten service account, one contractor who never enrolled in MFA, one shared login that “we’ll fix later.” That’s all it takes for a Snowflake tenant to become searchable, scriptable, and drainable.
What was taken, who got hit, and what attackers did with it
Once attackers had a foothold, they didn’t just grab a random table and bounce. They went after datasets that are painful to explain to regulators, customers, and your own leadership team.
What attackers stole from Snowflake customer environments
Reports tied to the Snowflake data-theft campaign list stolen data types that hit both consumers and employees :
- Call and text history records (non-content)
Not the message body, but the metadata: who contacted who, when, and how often. That’s enough to map relationships.
- Banking and financial information
The kind that triggers fraud monitoring, customer churn, and legal work.
- Payroll records
Employee data is a second breach inside the first one.
- DEA registration numbers
High-risk identifiers with real downstream abuse potential.
- Driver’s license numbers, passport numbers, Social Security numbers (SSNs)
The identity stack—often everything needed for account takeovers and synthetic identity attempts.
- Other personally identifiable information (PII)
The “misc” category that usually turns into the worst surprises later.
Who got hit (examples) and how big this got
This wasn’t a small set of niche targets. A published list of impacted orgs included AT&T, Ticketmaster, Santander, Pure Storage, Advance Auto Parts, Los Angeles Unified, QuoteWizard/LendingTree, and Neiman Marcus .
The U.S. Department of Justice also put numbers on the fallout: more than 100 million individuals affected and more than $9.5 million in losses tied to the Snowflake attacks .
What attackers did with the stolen data
They treated the data like inventory.
- Extortion payouts: at least $2.5 million in bitcoin from at least three victims
- Data sales: advertised on hacker forums and brought in about $495,000
That combination—cash from victims plus cash from resale—is why this pattern keeps showing up. It’s profitable, repeatable, and it punishes anyone who treats MFA as “optional.”
The part teams miss: re-extortion, multi-tenant blast radius, and the co-defendant angle
Selling data and getting a payout isn’t always the end of it. The Snowflake case shows a messier reality: once your data is out, attackers can keep coming back with new angles and new pressure.
Re-extortion: “Pay again, or we make it worse”
The DOJ described at least one re-extortion attempt where the attacker threatened further disclosure after the initial theft .
The detail that should make any team pause: the attacker reportedly used stolen data tied to a government officer and the officer’s immediate family to pressure the victim again .
That’s the re-extortion playbook in plain terms:
- Round 1: “We stole it. Pay us.”
- Round 2: “We’ll leak more, name names, and make it personal.”
If your incident response plan assumes a one-and-done negotiation, you’re planning for the clean version of a dirty event.
Multi-tenant blast radius: one campaign, many targets
Teams often scope a cloud breach like it’s a single contained fire. This campaign wasn’t. It was a repeatable workflow that hit at least 165 organizations .
That matters because in a multi-tenant SaaS world, attackers don’t need to “go deep” in one place to win. They can go wide:
- compromise, extract, extort
- repeat across the next account that’s exposed
The co-defendant angle: this wasn’t random
It’s tempting to write this off as one reckless actor. The reporting ties the activity to Connor Riley Moucka and John Erin Binns—with Binns indicted, arrested in Turkey, and an extradition request that was contested .
That’s not a kid guessing passwords at 2 a.m. That’s coordination, persistence, and a process.
Practical checklist: reduce your odds this week (not next quarter)
Re-extortion and “go-wide” campaigns thrive on one thing: your access paths staying valid. Cut those paths fast, and you change the attacker’s math.
1) Lock down authentication (today)
- Enforce MFA everywhere, with zero exceptions.
Not “recommended.” Not “for humans only.” Required.
- Set a real password floor. Snowflake moved to require 14+ character passwords after these incidents . Treat that as the minimum, not the goal.
- Kill shared logins. If two people can use it, an attacker can use it without raising eyebrows.
- Service accounts need love too. Use dedicated auth methods and tightly scoped permissions; don’t park long-lived passwords in scripts.
2) Rotate and reduce what can be reused
- Rotate credentials and tokens on a schedule (and immediately after any suspicious login).
- Shorten token lifetime where you can. Long-lived secrets are a gift to infostealers.
- Remove stale users and integrations (old contractors, abandoned tooling, “temporary” access that became permanent).
3) Assume infostealer exposure is already in your org
Infostealer-stolen logins were a key access method in the Snowflake campaign . Operationally, that means:
- Hunt for corporate creds on unmanaged devices (BYOD, home machines, contractor laptops).
- Force password resets for accounts that signed in from new devices/locations and never re-verified.
- Re-check browser password managers and local vault exports in environments with weak endpoint controls.
4) Make “weird” access loud
- Alert on unusual login patterns (new geos, impossible travel, first-time IPs).
- Watch for abnormal query/export behavior: sudden spikes in reads, large results, off-hours pulls.
- Log and review role changes and permission grants. Attackers look for the fastest path to broad read access.
5) Shrink the blast radius inside Snowflake
- Tighten roles to least privilege. Most users don’t need broad warehouse access.
- Restrict network access using IP allowlists where possible. If logins can only come from known ranges, stolen creds have fewer places to work.
- Separate environments (prod vs. dev) so one mistake doesn’t expose everything.
6) Tune incident response for multi-tenant reality
- Write a “credential theft” playbook, not just a “cloud breach” playbook.
- Pre-stage revocation steps: disable accounts, revoke tokens, rotate keys, freeze suspicious roles.
- Plan for repeat pressure: re-extortion is a thing. Treat comms, legal, and monitoring as ongoing work, not a one-week sprint.
7) One small move that blocks easy resets (Cloaked tie-in)
A lot of breaches get worse through account recovery: password resets that route through a reused phone number or a vendor portal tied to a compromised inbox.
For vendor sign-ups, support portals, and other external accounts that don’t need your real contact info, consider using Cloaked identities (masked email/phone). It lowers the value of exposed contact points and makes “reset the password via SMS/email” less of a straight shot when your primary inbox or number gets dragged into the blast radius.
.png)
