Writing
Anatomy of an Identity Incident

It Wasn't a Vulnerability. It Was a Setting Left Off.

Anatomy of an Identity Incident — Snowflake, 2024. The platform was never breached. Around 165 customers were, because multi-factor authentication was optional and nobody made it mandatory.

Michael AbramovichJuly 15, 20246 min read

Forensic write-ups of public identity breaches, strictly at the identity layer. No vendor is the villain — the point is the structural class of failure, not the logo on it.

The 60-second version

In 2024, an actor tracked as UNC5537 worked through a long list of organizations' cloud data warehouses and walked out with enormous volumes of data from around 165 of them — names you'd recognize among the victims. There was no vulnerability in the platform. There was no clever exploit. The attacker logged in. They used usernames and passwords that had been sitting in infostealer-malware logs for years — some dating back to 2020 — bought or scraped from cybercrime forums, and they worked because the accounts they belonged to required nothing more than a username and password.

Multi-factor authentication would have stopped essentially all of it. It was available. It simply wasn't enforced — not by the platform as a default, and not by the customers who could have switched it on. The credentials were old, the leak was years stale, and none of it mattered, because the one control that turns a leaked password into a useless password was switched off.

The identity timeline

Only identity-relevant events; this is a campaign across many victims, so the pattern is the story.

  • 2020 onward — Employees and contractors at various organizations get infected by infostealer malware (RedLine, Raccoon, Vidar, Lumma, and others). Among the harvested data are corporate credentials, including ones for cloud data-warehouse accounts. These credentials circulate and are sold for years.
  • The reuse — UNC5537 takes these long-dead credentials and simply tries them against the data-warehouse accounts. For accounts protected only by a password, a valid old password is a valid login.
  • No second factor — The targeted customer accounts do not have MFA enforced, so a correct username and password is sufficient. There is no second challenge to fail.
  • No network limits — The affected accounts also lack network allow-lists that would have restricted access to trusted locations, so the logins from the attacker's infrastructure are not blocked.
  • The exfiltration — With direct, authenticated access, the actor pulls large volumes of customer data and moves to extortion.
  • May 23, 2024 — The platform vendor becomes aware of unauthorized access to certain customer accounts. Investigation attributes the activity to credential-based access against customers lacking MFA — not a breach of the platform itself.

The pivot point

The pivot is the absence of an enforced second factor, and it's worth resisting the urge to make it more complicated than that.

A leaked password is not, by itself, an incident. Credentials leak constantly; that is the steady-state weather of the internet. The entire point of multi-factor authentication is to make a leaked password insufficient — to add a second thing the attacker can't pull from a years-old malware log. When MFA is enforced, the 2020 infostealer dump is a curiosity. When it isn't, that same dump is a master key, and the age of the credential is irrelevant because nothing ever required more than the credential.

So the pivot moment isn't a moment at all; it's a configuration state that existed before the attack began. The decision — or the non-decision — to leave MFA optional is the breach, made in advance, waiting for someone to notice the door was unlocked. Everything UNC5537 did afterward was just turning the handle, 165 times.

What would have caught it

Naming controls, not products.

Enforced MFA, as a policy and not an option. This is the whole game. MFA that customers can enable is not the same as MFA that is on. The single control that would have collapsed this campaign is mandatory MFA with no quiet exceptions.

Network allow-lists. Restricting account access to known, trusted networks would have blocked logins from the attacker's infrastructure even with valid credentials. The affected accounts didn't have them.

Credential rotation triggered by infostealer signals. Many of these passwords were knowable to be compromised — they were in malware dumps. Monitoring for your credentials in infostealer data and forcing rotation closes the window before reuse.

Detection of logins from new locations and clients. Direct authentication from never-before-seen infrastructure to a sensitive data store is a high-signal event, even when the credentials are valid.

Continuous posture enforcement, not one-time setup. The accounts weren't misconfigured once; they stayed misconfigured. The control that matters is the one that keeps checking that MFA is on everywhere, today, and not just that it was available at signup.

The last mile

This is the cleanest illustration in this entire series of responsibility sliding downhill and landing on no one.

Start at the top. The platform vendor was, technically, not breached — a defensible position, and a true one. The product worked as specified. But "we offer MFA" and "MFA is on across every one of a customer's accounts" are separated by exactly the stretch of work this series is about, and the vendor had left that stretch to the customer by making the control optional. Now go to the customer. Often a team without deep identity expertise, running a data warehouse among a hundred other responsibilities, who turned the thing on, loaded their data, and reasonably assumed that logging in with a password meant they were authenticated and therefore fine. And the credentials themselves came from infected endpoints belonging to employees and contractors — yet another span, the endpoint hygiene of people two steps removed from the data.

No single party here was negligent in a way that's satisfying to point at, and that is precisely the shape of the last mile. The vendor's responsibility ended at "available." The customer had the responsibility but neither the expertise nor the attention to enforce posture across every account continuously. And the result was 165 organizations breached not by a flaw but by a setting — the same setting, left off, in the same way, over and over.

This is also the case that most directly answers "whose job is this." Posture is not a state you reach; it is a process you run — and running it across many accounts, many tenants, with mandatory MFA and network policy and rotation on infostealer signals, continuously, is exactly the work an operator standing on the mile can own and a busy customer cannot. The platform can offer the control. Someone has to make it mandatory and keep it that way. When that someone doesn't exist, "we support MFA" and "165 customers got breached through accounts without MFA" are the same sentence, read from two ends.

For defenders

Five things you can check this week.

  1. Enforce MFA everywhere — make it mandatory, not available. Audit for any account, on any platform, that can still log in with just a password. Those are your Snowflake accounts.
  2. Add network allow-lists to sensitive data platforms so valid credentials from untrusted locations still fail.
  3. Monitor for your credentials in infostealer dumps and force rotation when they appear.
  4. Alert on authentication from new infrastructure to sensitive stores, even when the login succeeds.
  5. Make posture a recurring check, not a setup step. "Is MFA on across every account right now?" is a question to answer continuously, not once.

Built from public reporting and the parties' own disclosures; sources below.

Sources

#snowflake #unc5537 #mfa #infostealer #posture #last-mile