SURIQ
The most consequential hacking campaign of 2024 has ended in a guilty plea, and the court record confirms what defenders long suspected. There was no zero-day, no custom malware, no clever pivot. Connor Riley Moucka logged into other companies' cloud accounts using passwords that were already stolen and still worked. On August 5 he admitted in a Seattle federal court to breaking into at least 165 organizations that stored data in the cloud platform Snowflake, then using what he took to extort them. The crime is not the interesting part. How ordinary the method was, is.
Moucka, 26, from Kitchener, Ontario, admitted to four federal counts: computer and wire fraud, aggravated identity theft, and a hacking conspiracy. Named victims, per reporting from Krebs on Security and the plea record, span Ticketmaster, LendingTree, Advance Auto Parts, Neiman Marcus, and AT&T. What walked out the door reached billions of records: the call and text logs of over 100 million AT&T subscribers, payroll data, passports, Social Security numbers, even DEA registration entries. He pocketed roughly $495,000 himself through ransoms and resale of the data, part of more than $2.5 million the crew pulled in. His sentencing lands on October 27, and the charges carry up to 30 years.
How a password from 2020 opened 165 companies
The attackers never broke Snowflake. They logged in. As The Hacker News detailed from the case record, the passwords had been lifted long before by infostealer malware, and nobody ever changed them. A few dated back to November 2020 and were still live in 2024. On the accounts that got hit, multi-factor authentication (MFA), the second login check beyond a password, was turned off, with no network allow-list to limit where a session could originate.
The numbers make the pattern plain. Nearly four in five of the abused accounts had already surfaced in earlier credential leaks. Mandiant, which tracked the operators as UNC5537, said the intrusions leaned on nothing novel or sophisticated. That is the uncomfortable finding: a low-skill actor with a shopping list of leaked passwords caused one of the decade's largest data thefts, because the passwords were valid, single-factor, and reachable from anywhere.
This was a configuration failure, not a Snowflake bug
Here is the reframe the courtroom coverage skips. Every gap the attackers walked through was a setting the customer controlled, not a defect in the vendor's software. That changes what you do about it. You are not waiting for a patch. You are running an audit, and you can run it today on every SaaS platform that holds your data.
| Account control | State during the campaign | What closes it |
|---|---|---|
| Multi-factor authentication | Switched off | Enforce MFA on every account, no exceptions |
| Network access policy | No allow-lists | Restrict logins to known corporate networks |
| Credential lifetime | Passwords valid since 2020 | Rotate on a schedule; watch for exposed creds |
Credential lifetime is the variable most teams underrate. Infostealer logs are a commodity, sold in bulk on Telegram markets for the price of a coffee, so treating credential theft as preventable is the wrong model. Assume every password your staff uses is already for sale. The control that matters is not stopping the theft. It is making the stolen password useless: a second factor it cannot satisfy, a short-lived token that expires, a network policy that rejects the login from an unknown address. We made the same argument when Fortinet devices were drained through credentials no one had rotated, in our note that FortiBleed was not a bug so much as every password you never changed.
The one thing multi-factor authentication cannot catch
MFA, allow-lists, and rotation close the front door. They do not cover the case where an attacker holds a credential that is still valid and satisfies every check. A legitimately authenticated session using a stolen-but-good token looks exactly like the real user at the login event. You will not catch it there. You catch it by what it does next.
The Snowflake exfiltration was billions of records. That is not a quiet action. It is a query pattern: an account suddenly pulling table dumps it never touched before, from a source network it never used, at a volume no analyst would run by hand. Those signals live in the platform's own audit log, not in the authentication event. Collecting and retaining that log so the anomaly is visible, and alerting on bulk export rather than on a successful login, is exactly the job of centralized log management and detection. It is also why we keep telling teams to watch the session, not the password. Session-stealing malware like ACR Stealer rides a live session a reset will not kill, and the detection principle is identical: the login is clean, the behavior is not.
The pattern is bigger than one cloud platform
Snowflake is not an outlier. It is the clearest example of a failure mode that keeps recurring across every identity surface. The through-line is stored, unrotated, single-factor credentials, and a legacy or misconfigured path that lets them work. We watched the same shape in a password spray against Azure that MFA did not stop because a retired login flow accepted single-factor auth, and in the device-code phishing wave that takes over Microsoft 365 accounts with no password or MFA prompt at all. Different vendors, same root cause: a valid credential plus a way in that the second factor never guards.
The strategic read for security leaders is to stop treating SaaS identity as the provider's problem. When you put your crown-jewel data in someone else's cloud, the login page is your perimeter, and the configuration of that login is your responsibility. The vendor ships the locks. Whether they are turned on is on you.
Enforce MFA and allow-lists on your data platforms first
If your organization stores data in Snowflake, a cloud data warehouse, or any SaaS platform that holds records you cannot afford to lose, this is a same-day audit, not a project. In order:
-
Enforce MFA on every account, including service and admin accounts. Optional MFA is off MFA for the accounts that matter. Make it a policy the platform enforces, not a per-user choice.
-
Turn on network policies or allow-lists so logins only succeed from your known ranges. This alone would have blocked most of these intrusions, which came from arbitrary networks.
-
Rotate credentials and kill long-lived static passwords. Move to short-lived tokens or key-pair auth where the platform supports it, and rotate what remains on a schedule.
-
Check your own exposure. Assume staff credentials are in infostealer dumps and monitor for them, so a leaked password is a rotation task, not a breach.
-
Alert on bulk export, not just on login. Feed the platform's audit log into detection and flag abnormal query volume and new source networks.
The guilty plea closes a case. It does not close the pattern. The next actor with a list of leaked passwords is already testing them against the same optional-MFA accounts. The only thing that has to change is the settings, and those have always been yours to change.