Cyber & Resilience - 7 min read - 10 August 2026

The Snowflake breach hacker pleaded guilty this week. The setting that let him in wasn't Snowflake's to fix.

Connor Riley Moucka, 26, admitted in a US federal court to breaching 165 companies through their Snowflake accounts, stealing records tied to more than 100 million people and extorting at least three victims for a combined $2.5 million. Every account he got into shared one thing in common, and it wasn't a flaw in Snowflake's platform.

On 5 August, Connor Riley Moucka of Kitchener, Ontario, pleaded guilty to computer fraud, aggravated identity theft and conspiracy over a campaign that ran through most of 2024 and is only now reaching a US courtroom. According to The Hacker News and Krebs on Security, the plea confirms what investigators suspected from early on: Moucka and his co-conspirators didn't breach Snowflake. They logged into 165 of its customers' accounts using stolen credentials, and it worked because none of those accounts required a second factor to sign in.

What the plea actually admits to

Moucka faces a two-year mandatory minimum on the identity theft count alone, with exposure up to 30 years across the remaining charges, and is due to be sentenced on 27 October. The scale behind that exposure is what makes this worth revisiting eighteen months on: victims included AT&T, whose exposure covered call and text metadata for more than 100 million customers, alongside Ticketmaster, Advance Auto Parts, Neiman Marcus, Santander, LendingTree and one of the largest school districts in the United States. Court filings put victim companies' direct losses at more than $9.5 million - a figure that explicitly excludes whatever their own customers separately lost. Moucka's crew collected roughly $2.5 million in ransom payments across at least three victims, of which Moucka personally kept at least $495,000 in bitcoin. In at least one case, prosecutors say, he went back and extorted the same victim a second time.

Frostbite: automating the part that used to take a human

What separated this campaign from an ordinary credential-stuffing spree was the tooling built around the stolen logins. Prosecutors and Mandiant's investigation describe custom software the group called Frostbite, purpose-built to take a pile of harvested Snowflake credentials and automatically identify which accounts were worth breaking into - scanning for organisation names, user roles, IP ranges and banking details to separate a throwaway trial account from a Fortune 500 data warehouse. That's the part of this story that should worry security teams more than the credential theft itself: the labour-intensive triage step that used to limit how many stolen-credential campaigns were worth running at scale has been automated away, and Frostbite is not a sophisticated piece of malware - it's a targeting script built on data that shouldn't have been reachable in the first place.

The setting that separates this from a platform breach

Snowflake said at the time, and nothing in this plea contradicts it, that its own platform was not compromised. Every login Moucka's group used was a legitimate set of credentials, harvested months or years earlier by unrelated infostealer malware infections on customer-side machines, then matched against Snowflake accounts that had never been configured to require multi-factor authentication. That distinction matters for where the accountability actually sits. A platform vulnerability is a vendor's problem to fix and disclose. An optional security control that 165 different customer organisations independently chose not to turn on is a shared failure of default configuration, security awareness and, in a lot of these cases, nobody's specific job. Snowflake has since moved toward enforcing MFA by default for new accounts - a change that came after the damage, not before it, which is its own lesson about which security defaults are worth setting before an incident forces the question.

We've made a version of this argument before in a different context: privileged access management only reduces risk if the accounts that matter are actually inside its scope, and identity modernisation programmes tend to stall exactly on the "which accounts are we not getting to yet" question. Moucka's 165 victims are a concrete answer to what that gap costs when it's left open long enough for an automated targeting tool to find it first.

  • Confirm today whether MFA is enforced - not just available - on every account with access to a data warehouse, analytics platform or other bulk-data SaaS tool, not only your identity provider's default applications.
  • Treat infostealer malware logs as a live threat to any SaaS credential a compromised device ever touched, even long after the device itself was cleaned - stolen Snowflake logins in this case sat unused for months before being weaponised.
  • Ask your data platform and analytics vendors directly whether MFA is enforced by default for new accounts today, and whether it can be made mandatory retroactively for accounts your organisation already has.
  • Build a specific inventory of which SaaS platforms hold bulk customer or employee data at scale - these are exactly the targets a tool like Frostbite is built to prioritise, and they deserve tighter defaults than a typical business application.

Sentencing in October will close the legal chapter on Moucka's case, but the setting that let him into 165 companies is still off by default in plenty of SaaS platforms other organisations rely on today. If you want a straight answer on where multi-factor authentication and credential hygiene gaps exist across your own SaaS estate, email sales@halfteck.com.

Explore more resources

Browse our full library of enterprise cloud, software, data and AI content.

View all resources