The most consequential intrusions of the last few years have not involved novel exploits. They have involved a username, a password, and a platform that was perfectly happy to accept both from anywhere on the internet. The Snowflake campaign of 2024 is the cleanest example we have, and with Connor Riley Moucka of Kitchener, Ontario now pleading guilty to computer fraud and conspiracy relating to more than 165 organisations, the legal file is closing while the underlying control gap is very much still open.
I want to be careful about what this news actually is. A plea is not a technical disclosure. It tells us who, roughly how many, and confirms scale — including the theft of call and text metadata belonging to over 100 million AT&T customers. It does not hand us new indicators. So the useful exercise is not to re-read the incident; it is to ask whether the conditions that made it possible have changed in your estate. In most estates, they haven't changed nearly enough.
The platform wasn't breached. The tenants were.
This distinction matters because it determines who owns the remediation. There was no compromise of the provider's infrastructure. Customer accounts were accessed with valid credentials, and those credentials worked because the accounts in question had single-factor authentication and no restriction on source network. That is a customer-side configuration outcome, delivered by a platform whose defaults at the time made it easy to get wrong.
The pattern repeats across the industry: the security model is technically available, documented, and switched off. Snowflake supported multi-factor authentication and network policies long before 2024. What it did not do, until afterwards, was make MFA something an administrator could enforce tenant-wide without depending on each user to opt in. If your control depends on individual users choosing it, you do not have a control. You have a hope with a documentation page.
Analytics platforms are identity systems, and nobody treats them that way
Ask most IT teams to list the identity-critical systems in their estate and you'll get the directory, the VPN, the email tenant, maybe the privileged access tooling. You will rarely get the data warehouse. Yet the warehouse is where the organisation deliberately concentrates its most sensitive material in query-optimised, bulk-exportable form. It is, by design, the single place where one authenticated session can retrieve more customer data than any application ever would.
That inversion of value against scrutiny is the real lesson. Conditional access policies get applied rigorously to Microsoft 365 because that's where the security team's attention naturally sits. The BI and analytics stack often sits under a data engineering function with a delivery deadline, its service accounts created ad hoc, its credentials pasted into an orchestration tool, its authentication path entirely separate from the corporate IdP. Two governance regimes, one blast radius.
Credential half-life is measured in years, not days
Reporting at the time indicated some of the credentials used had been harvested by commodity infostealer malware years earlier — including from machines belonging to contractors rather than employees. That is the part I'd put in front of a risk committee. An infostealer infection on a third-party laptop in 2020 produced an extortion event in 2024 because nothing in between invalidated the credential.
Static credentials do not expire on their own. They persist in orchestration tools, in scheduled jobs, in the config file someone copied to get a pipeline working on a Friday. If your only response to a stealer log appearing on a criminal marketplace is to reset the user's primary password, you have addressed a fraction of the exposure. The service account, the personal access token, the connection string in the ETL job — all still valid, all still single-factor, all still reachable from any IP address on earth.
Nobody noticed the data leaving
The other uncomfortable observation: across 165-odd organisations, large volumes of data were queried and exfiltrated, and the detection generally came from the extortion demand rather than from telemetry. Query history and access logs existed. They were not being watched in a way that would flag an anomalous bulk read at an unusual hour from an unfamiliar network.
This is a solvable monitoring problem and it is boring, which is why it doesn't get done. A rule that alerts when a single session reads more than some multiple of its historical baseline is not sophisticated behavioural analytics. It's a threshold and a schedule. The reason it isn't in place is usually that nobody has decided who owns alerting on the data platform — the security operations team assumes the data team has it, the data team assumes it's a security concern, and the logs accumulate unread.
What I would actually check this quarter
Concrete and finite, in rough order of return on effort:
- Enumerate every authentication path into your data platforms. Not the intended one — every one. Include service accounts, personal access tokens, JDBC/ODBC connection strings and anything a contractor was given during a migration.
- Enforce MFA or federation at tenant level, not per user, and confirm enforcement by attempting a single-factor login rather than by reading the policy page.
- Apply network policies so that credentials alone are insufficient from an arbitrary source address. This is the cheapest compensating control available and it would have blunted the entire campaign.
- Give every non-human credential an expiry and an owner. A credential with no rotation date is a permanent liability recorded nowhere.
- Wire one bulk-egress alert per data platform and route it to a queue a human reads.
- Extend stealer-log response to third-party devices. If a contractor's machine is compromised, assume everything they touched in your estate needs invalidating.
Arrests are not a control
It's genuinely good that this ended in a courtroom, and the deterrent value of a 26-year-old facing sentencing over 165 victim organisations is real. But the actors were interchangeable; the misconfiguration was not. The next campaign will use the same technique against whichever platform currently ships with optional MFA and no default network restriction, and it will succeed for the same reasons.
The uncomfortable truth about the Snowflake extortions is that almost every organisation affected already owned the controls that would have stopped them. That's the finding worth carrying forward — not the indictment.