In short: the Snowflake extortion campaign worked because a stolen password was enough. None of the affected accounts had MFA, so a stolen password alone opened the door, and the same gap can exist in small business accounts today.
Table of Contents
Connor Riley Moucka, a 26-year-old from Ontario, pleaded guilty on August 5, 2026, to computer fraud, wire fraud, aggravated identity theft, and conspiracy charges tied to one of the more consequential cloud data-theft campaigns in recent years, breaches across at least 165 organizations that used Snowflake for cloud data storage. He and co-conspirators accessed Snowflake customer accounts between February and October 2024 using credentials stolen through infostealer malware, not by breaking Snowflake’s own security, but by using real, valid login details that customers themselves had lost to separate malware infections. The campaign brought in more than $2.5 million in ransom payments across the conspirators.
He faces a mandatory minimum of two years in prison on the aggravated identity theft count and up to 30 years on the remaining counts, and is due to be sentenced on October 27, 2026.
The Detail That Actually Matters: This Wasn’t a Snowflake Vulnerability
It’s tempting to read “Snowflake breach” as a flaw in Snowflake’s own platform, but that’s not what happened here. The attackers used legitimate credentials, stolen via infostealer malware running on individual users’ machines, to log into accounts that Snowflake itself hadn’t compromised at all. The single, specific security gap that made this possible at scale: none of the affected accounts had multi-factor authentication enabled. A stolen password alone got the attackers in, because there was no second factor standing between “correct password” and “full account access.”
Why This Keeps Happening With Cloud Data Platforms Specifically
Cloud data platforms like Snowflake are built to be accessed programmatically, from many locations, by many different tools and integrations, which is exactly what makes them useful and exactly what makes password-only access so dangerous on them specifically. A traditional on-premises database sitting behind a corporate firewall has a real, if imperfect, network boundary protecting it. A cloud data platform accessible from anywhere on the internet with the right credentials has no equivalent boundary, MFA is doing the job network isolation used to do, and skipping it removes the actual barrier between a stolen password and complete account access.
What Actually Protects Against This
Multi-factor authentication on every account with access to customer data or business-critical systems is the single highest-leverage fix available, and it’s not a new or exotic recommendation, it’s the specific control whose absence is the entire reason this campaign succeeded at the scale it did. Beyond MFA specifically, monitoring for credential-stuffing patterns, unusual login locations, or access at times that don’t match normal usage, catches exactly this kind of attack even when a valid password has genuinely been compromised elsewhere. The uncomfortable but important framing: this breach didn’t require attackers to be sophisticated against Snowflake’s own defenses, it required them to find accounts where a basic, well-known best practice simply hadn’t been turned on.
How to Check Whether Your Own Accounts Have the Same Gap
The lesson from this case is easy to agree with and easy to forget to act on, so it helps to turn it into a short audit. Set aside an hour and work through every account that holds customer data or administrative control over your business:
- Your hosting control panel and any server or VPS login.
- Your domain registrar, since whoever controls the domain controls your email and website.
- Your email administration console, whether that is Google Workspace, Microsoft 365 or a hosting mailbox.
- Payment processors, accounting software and your CRM.
- Cloud storage, backup services and any analytics or data warehouse tools.
For each one, answer three questions. Is MFA switched on for every user, or only for you? Is it enforced, or can a team member quietly skip it? And are there API keys, app passwords or service accounts that can log in without a second factor at all? That last category is the one most often forgotten, and it is the same kind of gap that let a password alone open the door in the Snowflake accounts.
Why a Stolen Password Stays Dangerous
Infostealer malware runs quietly on an infected laptop or desktop and collects saved browser passwords, session data and other credentials, which are then passed on or sold. The person whose machine was infected may never notice. That matters because a stolen password doesn’t expire on its own. If it was never changed, it can still work long after the infection happened, and anyone who reuses the same password across several services hands an attacker all of them at once.
Three habits close most of that exposure. Use a unique password for every account, so one infection can’t unlock everything. Change the passwords for any account that was used on a machine you later find was infected. And turn on MFA, so a stolen password on its own isn’t enough.
Choosing the Second Factor
Not every second factor is equally strong. A code from an authenticator app is a solid default and far better than none. A hardware security key or a passkey is stronger still, because it can’t be typed into a fake login page. Text-message codes are better than nothing, but they are the weakest common option and worth replacing on administrator accounts whenever the service offers something better. If you can only improve one thing this week, turn MFA on for the accounts at the top of the list above, starting with email and the hosting panel, then work down.
What This Means for a Smaller Business
Most small businesses aren’t running enterprise cloud data warehouses, but the underlying lesson scales down cleanly: any account, a hosting control panel, an email platform, a payment processor dashboard, a CRM, that holds customer data or business-critical access is exactly the kind of target this same pattern applies to. Infostealer malware harvesting saved passwords from an infected employee laptop doesn’t care whether the stolen credentials unlock a Fortune 500 company’s data warehouse or a small business’s hosting account, it’s the same theft, applied to whatever target the stolen password happens to unlock. Turning on MFA everywhere it’s available, not just on the accounts that feel most sensitive, is the concrete, low-cost action this specific case actually argues for.
Related reading: NovaCookies Phishing Kit Abuses Real Docusign Emails to Steal M365 Sessions and Exchange’s CVE-2026-96940 Patch Confusion: What to Actually Check.