Snowflake Hacker Connor Riley Moucka Pleads Guilty and Faces 32 Years

Connor Riley Moucka, a 26-year-old from Kitchener, Ontario, has pleaded guilty in federal court in Washington state to computer fraud, wire fraud, aggravated identity theft, and conspiracy. Known online as "Waifu" and "Judische," he is scheduled for sentencing on October 27 and faces up to 32 years in prison. (Source: Helpnetsecurity)

The charges stem from a campaign that ran between April and September 2024. Moucka and his co-conspirators used stolen credentials to log into customer accounts at cloud data platform Snowflake, then pulled data from more than 165 organizations and demanded ransom payments to keep it unpublished.

No exploit chain was involved in the account access itself. Valid credentials belonging to Snowflake customers were enough, which is the detail worth carrying into any conversation about your own cloud data warehouse: the platform held up, and the accounts sitting on top of it did not.

What the group downloaded was measured in terabytes. That included non-content call and text records, banking and financial information, payroll records, Drug Enforcement Administration registration numbers, driver's license and passport numbers, and Social Security numbers.

Organizations publicly linked to the campaign include AT&T, Ticketmaster, Santander, Advance Auto Parts, LendingTree, Neiman Marcus, Pure Storage, and Bausch Health. Stolen data was advertised for sale on BreachForums, Exploit.in, XSS.is, and Telegram.

Victim companies suffered over $9.5 million in actual losses — a figure the Justice Department notes excludes losses to those companies' own customers, totaling at least 100 million individuals.

The conspirators collected more than $2.5 million in ransom payments, with Moucka personally receiving at least $495,000. In one instance he returned to a victim for a second extortion attempt, threatening to release additional data that included personal information on a government official and the immediate family of a former government official.

For security teams, the case is a data point on attribution: FBI Cyber Division Assistant Director Brett Leatherman noted Moucka was arrested within months of beginning to target U.S. companies.

How Stolen Credentials Enabled Access to Snowflake Customer Data

The plea documents describe access gained with stolen credentials used against customer accounts, not the exploitation of a flaw in the platform itself. That distinction matters: the sessions arrived as authenticated logins belonging to legitimate analytics users, so the activity carried the permissions of the accounts it borrowed.

Snowflake is a cloud data warehouse, which means it exists to consolidate data that would otherwise sit in separate systems — billing records, CRM exports, payroll files, call detail records. One valid account in that environment can query across all of it. For your business, the practical consequence is that a single set of working credentials in a warehouse tenant reaches far more records than the same credentials would reach on an individual application server.

The volumes reflect that. Court records describe terabytes of data downloaded from victim environments, including non-content call and text records, banking and financial information, payroll records, Drug Enforcement Administration registration numbers, driver's license numbers, passport numbers, Social Security numbers, and other personally identifiable information. Those categories are not incidental — DEA registration numbers and passport numbers support identity fraud and prescription fraud downstream, which is why the harm extends past the breached company to its customers.

Mapped to MITRE ATT&CK, the chain is short and made almost entirely of authorized-looking actions:

• T1078.004 (Valid Accounts: Cloud Accounts) — logins to customer tenants using credentials the conspirators already held rather than any code execution against the platform.
• T1530 (Data from Cloud Storage) — bulk retrieval of warehouse tables through the account's own query and export capability.
• T1567 (Exfiltration Over Web Service) — data pulled out over the same web-facing service the account normally uses.
• T1657 (Financial Theft) — ransom demands in exchange for not publishing or selling the stolen datasets.

There is no privilege escalation step and no malware implant in this chain. The conspirators did not need to move laterally through an internal network because the warehouse had already aggregated the data for them, and the account they used was permitted to read it. In monitoring terms, the difference between an analyst running a large export and an intruder running the same export is intent, not technique.

Monetization ran on two tracks. The group demanded ransom payments directly from victim organizations and, in parallel, advertised stolen data for sale on BreachForums, Exploit.in, XSS.is, and Telegram — so a company that declined to pay still faced its records circulating in criminal markets. Payment did not close the matter either: in one instance Moucka went back to a victim a second time, threatening to disclose additional stolen data, including personal information belonging to a government official and members of a former government official's immediate family.

Two structural facts define this case for anyone running data in a cloud warehouse. First, the initial access vector was credentials, which means the control that would have interrupted the chain sat with the customer's identity configuration rather than with the platform vendor. Second, the campaign ran from April to September 2024 across many separate victim tenants, indicating the same credential-driven approach worked repeatedly against organizations that each believed their warehouse access was restricted to their own staff.

Business and Compliance Impact for Snowflake Customers

The Justice Department put the victim companies' direct losses at more than $9.5 million, and that figure covers only the breached organizations themselves.

The conspirators collected more than $2.5 million in ransom payments across the campaign. If your organization is weighing extortion payment against remediation cost, note that the attackers' take was a fraction of what the companies absorbed in actual losses.

The data categories pulled from these accounts determine which regulators you answer to, and the mix here spans nearly every notification regime:

• Social Security numbers, driver's license numbers, and passport numbers — trigger state breach notification statutes in essentially every U.S. jurisdiction, each with its own deadline and attorney general filing requirement.
• Banking and financial information — brings financial regulators and card-brand contractual obligations into your response.
• DEA registration numbers — prescriber identifiers, which pull healthcare-adjacent organizations into HIPAA breach assessment and Office for Civil Rights reporting.
• Payroll records — employee data, which creates a separate notification population and separate employment-law exposure from your customer notifications.
• Non-content call and text records — telecom metadata subject to sector-specific rules.

Victims named publicly include AT&T, Ticketmaster, Santander, Advance Auto Parts, LendingTree, Neiman Marcus, Pure Storage, and Bausch Health. That list crosses telecom, ticketing, banking, retail, lending, and pharmaceuticals, so your industry offers no structural protection here — the common factor is the analytics platform, not the sector.

Multinational footprints multiply the work. A single incident touching EU or UK residents starts GDPR's 72-hour supervisory authority notification clock while your U.S. state notifications run on entirely different timelines, and your legal team is drafting to both standards from the same forensic findings.

For your SOC 2 posture, the relevant point is where auditors assign the failure. Unauthorized access to a cloud analytics tenant using valid account credentials lands squarely in logical access controls, which means an exception in your next Type 2 report and a wave of customer security questionnaires asking how you govern third-party platform authentication. Enterprise customers reading that report may hold renewals until you answer.

The stolen data was also advertised for sale on BreachForums, Exploit.in, XSS.is, and Telegram. Organizations that paid still faced the possibility of their records circulating through resale channels, which undercuts the assumption that a payment closes the exposure.

One victim was extorted a second time, with Moucka threatening to release additional data — including personal information belonging to a government official and family members of a former government official. If your data holdings include politically exposed persons, executives, or public officials, a single incident can generate follow-on demands months after you believe the matter is settled.

The customer-side harm reaches at least 100 million individuals. At that scale, your costs extend past forensics and legal counsel into credit monitoring enrollment, call center capacity, and the class-action litigation that reliably follows breaches involving Social Security numbers.

Compliance officers should treat the records consolidated into cloud analytics platforms as in-scope for every regulation that governs their original source system. The data does not shed its regulatory obligations when it moves into a warehouse for reporting.

Detection and Response for Snowflake Environments

Following the NIST Cybersecurity Framework, the first move is an account audit inside your Snowflake tenant — because the campaign ran on valid logins, your user list is the attack surface.

Identify

Pull a full list of users in the account and separate human users from service accounts and integration users. Flag every account with no login activity in the last 90 days, every shared login used by more than one person, and every account that authenticates with a password alone.

Map role grants to the databases and schemas each account can query. If a single analytics role can read billing, HR, and customer tables, one borrowed session reaches all three — and that scope is what determines your notification obligations later.

Protect

• Enforce MFA on every human user, including administrators and contractors, and make it mandatory at the account level so new users inherit it.
• Move service accounts and ETL integrations to key-pair authentication so there is no reusable password to steal from a developer workstation.
• Apply network policies that restrict logins to your corporate and cloud egress ranges; an authenticated session from an unlisted address then fails before it queries anything.
• Rotate all Snowflake passwords and keys, disable the dormant and shared accounts you flagged, and shorten idle session timeouts.

Detect

Review LOGIN_HISTORY for successful logins outside working hours, logins from countries where you have no staff, and connections from client drivers or tools your teams do not use. A single account authenticating from two distant locations within the same hour is worth an immediate call to the account owner.

Then work through QUERY_HISTORY and access history for bulk-read behavior: full-table selects against tables that are normally filtered, sudden spikes in bytes or rows scanned by one user, and exports to external stages or cloud storage buckets you do not recognize. Pair that with egress monitoring on the network side, since terabyte-scale downloads leave a traffic signature even when the query itself looks authorized.

In environments Capstone manages, Adlumin ITDR watches authentication behavior across cloud and identity providers, so a valid login arriving from an unusual location or device raises an alert instead of blending into normal analytics traffic. No public IP indicators were released with this case, which makes behavioral detection the practical path.

Add monitoring for your own data appearing on criminal marketplaces. The stolen datasets in this campaign were advertised on BreachForums, Exploit.in, XSS.is, and Telegram, and that exposure is sometimes the first confirmation a company gets.

Respond

If you find a suspect session, suspend the user rather than only resetting the password, and revoke active sessions and any outstanding OAuth or key pairs tied to it. Preserve login and query history exports immediately — account usage views have retention limits, and you will need the query text to scope what was read.

Build re-extortion into the plan.

Recover

Reissue credentials from a managed vault so keys and passwords are no longer stored in scripts, notebooks, or ticket comments. Tighten role grants to the minimum each job function needs, then re-run the login and query reviews on a schedule so anomalous access surfaces continuously instead of during the next audit.

Document which data categories were exposed per account and hand that to counsel for breach notification decisions. Keep the account inventory and MFA enforcement checks as recurring controls, verified quarterly.

Lessons from Moucka's Conviction for Cloud Security Strategy

Connor Moucka was arrested within months of beginning to target U.S. companies, according to Brett Leatherman, Assistant Director of the FBI's Cyber Division. Prosecution of cloud extortion is real and it is fast. It also arrives after the data has already moved.

That timing is the part worth building your strategy around. The group advertised stolen records for sale on BreachForums, Exploit.in, XSS.is, and Telegram — once your customer data reaches those channels, a guilty plea in Washington state does not pull it back. Moucka personally kept at least $495,000 from the scheme, which tells you the economics still work for whoever picks up the same playbook.

Look at who was hit: AT&T, Ticketmaster, Santander, Advance Auto Parts, LendingTree, Neiman Marcus, Pure Storage, and Bausch Health. These are organizations with funded security programs and mature perimeters. The common factor across them was how credentials for a shared cloud data platform were issued, stored, and watched — not the size of the security budget.

The re-extortion detail should also shape how you think about payment. Moucka went back to one victim a second time, threatening to release additional data including personal information on a government official and family members of a former official. Paying ends a demand, it does not end the attacker's leverage.

What this case proves is narrow and useful: valid credentials against a cloud data platform produced a nine-figure victim population without a single software exploit. The question to answer this week is who in your organization owns credential security for each cloud platform holding regulated data, by name.