Canadian man pleads guilty to hacking and extorting 165 Snowflake customers
A guilty plea in the 2024 Snowflake campaign shows how stolen passwords and unenforced MFA turned one cloud platform into 165 separate breaches.
Connor Riley Moucka, a 26-year-old from Kitchener, Ontario, has pleaded guilty to four counts of computer fraud, wire fraud, aggravated identity theft and conspiracy over a 2024 campaign that hit at least 165 organisations using Snowflake's cloud data platform, Krebs on Security reported on 6 August 2026. Moucka operated online under the handles "Judische" and "Waifu".
The intrusions ran from February to October 2024. According to the report, the conspirators used stolen login credentials to get into Snowflake customer accounts that did not enforce multi-factor authentication. Victims named include Ticketmaster, LendingTree, Advance Auto Parts and Neiman Marcus. Moucka also admitted taking call and text history records for more than 100 million AT&T customers.
The haul ran to billions of records: non-content call and text logs, banking and payroll information, Drug Enforcement Administration registration numbers, driver's licence and passport numbers, and Social Security numbers. The group collected more than US$2.5 million in ransom payments, and Moucka re-extorted at least one victim after it had already paid.
Two alleged co-conspirators are named. Cameron Wagenius, a US Army soldier known as "Kiberphant0m", pleaded guilty in July 2025 and is due for sentencing on 3 September 2026, facing up to 20 years. John Erin Binns, who used the aliases "IRDev" and "IntelSecrets", remains at large; the report says he was released from a Turkish prison and has obtained Turkish citizenship. Moucka faces a mandatory minimum of two years on the identity theft count and up to 30 years on the remaining counts. His sentencing is scheduled for 27 October 2026.
Why it matters
The Snowflake campaign shows a cloud provider's platform staying intact while its customers were breached at scale through weak account hygiene. The mechanism, credentials stolen elsewhere and replayed against accounts with no second factor, remains the most common route into software-as-a-service tools. Vendors are responding by enforcing multi-factor authentication and retiring password-only access.
The Snowflake campaign shows a cloud provider's platform staying intact while its customers were breached at scale through weak account hygiene.
Credentials stolen elsewhere
Usernames and passwords obtained outside Snowflake were collected by the conspirators.
Replayed against accounts without MFA
Logins succeeded on customer accounts that did not enforce multi-factor authentication.
Customer data queried and exported
Billions of records, including call logs and identity numbers, were copied from at least 165 organisations.
Victims extorted
More than US$2.5 million in ransom was paid; at least one victim was extorted twice.
Guilty plea and sentencing
Moucka pleaded guilty to four counts; sentencing is set for 27 October 2026.
What you can learn from this
- Credential replay is the attack, not the platform. A login system checks whether the password matches; it has no way of knowing whether the person typing it is the account owner. Passwords leak constantly through malware on employee laptops, reused logins from unrelated breaches and phishing, and attackers simply try them against high-value services. That is why a password is called a single factor: it proves possession of a secret, and secrets get copied. Automated tooling makes trying thousands of leaked credentials against a login page cheap, so any account with a reused password is effectively already exposed.
- Multi-factor authentication breaks replay because the second factor cannot be copied with the password. A one-time code, push approval or hardware key is bound to a device the attacker does not hold, so a valid password alone fails at the login step. Phishing-resistant forms such as FIDO2 keys and passkeys go further by cryptographically tying the login to the real site's domain. The Snowflake cases involved accounts where MFA was available but not enforced, which from the attacker's point of view is the same as MFA not existing.
- The shared responsibility model puts identity on the customer. Cloud providers secure the hardware, hypervisors and the service itself; customers configure who can log in, from where, and with what privileges. Most cloud data breaches land in that customer-owned gap rather than in the provider's code. Understanding where the line sits for each service you use is a prerequisite for deciding which controls you must switch on yourself. Providers publish this boundary in their documentation, and the defaults chosen for new accounts are often the most permissive ones.
- Service accounts and network policies deserve the same scrutiny as human logins. Data platforms are often queried by dashboards, pipelines and scripts using long-lived credentials that nobody rotates. A network allow-list that only accepts connections from known addresses stops a stolen credential being used from an unfamiliar machine, even without MFA. Scoping each credential to the minimum data it needs limits what one leak can expose. Rotating those credentials on a schedule bounds how long a leaked key stays useful.
- Paying an extortion demand does not delete the data. Once records have been exfiltrated, every copy the attacker holds remains under their control, and the report notes that at least one victim was extorted a second time. Incident response plans should therefore assume the data is gone and focus on containment, notification and reducing the value of what was taken. This is why encryption of sensitive fields at rest, with keys held separately, matters even when the database itself is compromised.
We teach this
How to use this in practice
- Audit MFA enforcement on one platform you administer. Open the admin console of a SaaS or data tool you control, export the user list, and identify every account that can still sign in with only a password, including service and API users. Done looks like zero password-only accounts, or a written exception list with an owner and an expiry date for each entry. If the platform offers a policy switch that requires MFA for every user, turn it on in a test tenant first and note which integrations break. Record the date you ran the export so the next audit can measure drift.
- Check whether your own credentials are already circulating. Run your email addresses through a reputable breach-notification service and review your password manager's reuse report. Rotate any password that appears in a breach or is shared across services, starting with cloud consoles and email. While you are there, generate a unique passphrase for any account that shares one with another service, and turn on the manager's breach alerts so future leaks reach you without another manual check. Done looks like no reused passwords on any account that can reach production data.
- Draw the attack path and mark the control points. Sketch five boxes: credential stolen, login accepted, data queried, data exported, victim extorted. Under each, write the single control that would have stopped it, such as MFA at login, a network allow-list at connection, query anomaly alerts at export. Then mark which of those controls you can confirm are switched on for a system you use today. Done looks like a one-page diagram you could hand to a colleague who has never heard of this incident.
- Read your sign-in logs for the last 30 days. Most cloud platforms expose a login history with source IP, location and client. Pull it for one account you own and account for every entry; enable new-location or new-device alerts if the platform offers them. Done looks like a list where every sign-in is explained and unexplained ones have been reported or forced to re-authenticate. Repeat the exercise for one API key or service account, which usually has no such alerting and needs a manual check of its usage log. Note the retention window on that log too, since it bounds how far back an investigation could look.
Sources
- Canadian Man Pleads Guilty in Snowflake Extortions — Krebs on Security
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report