On Wednesday, a Seattle federal courtroom closed out one of the largest data breaches in recent memory. Connor Riley Moucka, 26, of Kitchener, Ontario, pleaded guilty to computer fraud, wire fraud, aggravated identity theft, and conspiracy over a 2024 hacking spree that reached at least 165 organizations and exposed records belonging to at least 100 million people. He personally pocketed at least $495,000 from ransoms and data sales. He's due to be sentenced October 27 and faces a two-year mandatory minimum on the identity theft count alone, with exposure up to 30 years on the rest.

Those numbers are the headline. The detail worth sitting with is smaller and much less cinematic: prosecutors say what actually let Moucka in were old passwords. Not a zero-day. Not a flaw in the targeted platform, which the Justice Department still hasn't named publicly (Snowflake and the incident-response firm Mandiant identified themselves as involved back in 2024, tying the case to the wave of breaches against Snowflake customer accounts that year). The credentials had been harvested years earlier by infostealer malware, sat unused and unrotated, and unlocked accounts that also happened to have multi-factor authentication switched off.

Why "unrotated" is doing all the work in that sentence

Infostealer malware is a category of malicious software that, once it lands on a device — often via a pirated app, a fake browser update, or a malicious attachment — quietly siphons off whatever credentials are sitting in that machine's browser autofill and saved-password stores, then ships them to whoever operates the malware. This isn't new or exotic; it's been a commodity criminal service for years, with stolen credential batches bought and sold in bulk.

The part that makes the Snowflake case a useful teaching example is the gap between theft and use. These particular passwords were reportedly harvested "years earlier." That means for a long stretch, the people who owned those accounts had a compromised credential sitting active in a database somewhere, and nothing forced them to change it. No login attempt was flagged as suspicious, because the attacker wasn't trying yet. No password reset was triggered, because there was no active exploit for anyone to notice. The credential just waited, valid, until someone decided to use it at scale against Snowflake customer accounts.

That's the failure mode reused and unrotated passwords create: it's not that they're weak, necessarily — infostealer malware will happily grab a strong, unique password too, straight out of a browser's saved-password vault. It's that a stolen password has no expiration date unless a human or a policy gives it one. A breach from 2021 can still be opening doors in 2024 if nobody ever rotated the credential in between.

The second lock that wasn't there

The other detail prosecutors flagged — MFA switched off on the affected accounts — is what turned a stolen password into full account access. Multi-factor authentication is designed for exactly this scenario: it assumes passwords will leak eventually and adds a second proof of identity (a code, a push notification, a hardware key) that a stolen password alone can't satisfy. When it's disabled, a leaked credential is the whole barrier. Reporting on the broader 2024 Snowflake-linked breach wave has noted that many affected accounts didn't have MFA enforced by default, which meant the setting depended on each customer organization actively turning it on.

What this actually means for you

Most readers of this newsletter aren't running a Snowflake data warehouse, but the mechanics here apply to any account you hold anywhere:

  • Assume old passwords are compromised, not just weak. If you reused a password on multiple sites and haven't changed it since, treat it as burned — not because someone guessed it, but because it may already be sitting in a stolen-credential list you'll never see.
  • Rotate credentials after any service you use discloses a breach — even if you're told your specific account "wasn't affected." Initial breach notices are frequently incomplete as investigations continue.
  • Turn on MFA everywhere it's offered, and don't assume a service enables it by default. Check account security settings directly rather than trusting that the safest option is already active.
  • A password manager solves the root cause, not just the symptom: it makes unique, un-reused passwords the path of least resistance instead of the thing you have to remember to do.
  • If a device may have been infected with infostealer malware (an unfamiliar program installed, a pirated download, a suspicious login alert), rotating every saved password afterward — not just the one you think mattered — is the only way to know an old infection isn't still paying dividends for whoever collected the data.

The mismatch is the lesson

There's something almost uncomfortable about a case this consequential — a 30-year maximum exposure, a mandatory minimum, 100 million people's records — resting on a mechanism this mundane. No exploit chain, no novel technique, just a password nobody got around to changing and a security setting nobody turned on. That mismatch is exactly why the case is worth remembering after the sentencing headlines fade: the biggest breaches don't usually need a brilliant attacker. They need one credential that was never rotated, sitting on one account where MFA was never switched on.