Writing
Anatomy of an Identity Incident

Nothing Was Stolen. The Tokens Were Forged.

Anatomy of an Identity Incident — Storm-0558, 2023. A leaked signing key let an attacker mint valid identities for anyone. No password was guessed, because none was needed.

Michael AbramovichSeptember 12, 20236 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 mid-2023, an actor tracked as Storm-0558 read the email of roughly 25 organizations, including government agencies, without guessing a single password or tripping a single MFA prompt. They did it by forging authentication tokens — minting their own valid-looking proof of identity — using a Microsoft signing key they had obtained. A signing key is the thing an identity system uses to vouch that a token is real. Hold the key, and you don't break into accounts; you issue yourself the credentials to be them.

Two failures had to line up. First, a consumer signing key escaped the secured environment it should never have left, ending up in a crash dump that moved to a corporate network where an attacker eventually reached it. Second, a validation flaw meant that key — meant only for consumer accounts — was accepted to forge tokens for enterprise mailboxes too. The boundary between two trust domains quietly didn't exist. Nothing was stolen from the victims. The authority that vouches for their identities was simply borrowed.

The identity timeline

Only identity-relevant events.

  • A signing key leaks into a crash dump. After a system crash, a consumer (MSA) signing key — material that is supposed to live only inside a hardened, isolated environment — is inadvertently captured in the resulting memory dump.
  • The dump leaves the vault. The crash dump moves from the isolated production environment into the internet-connected corporate debugging environment, carrying the key with it. The key's protections travel no further than its original home.
  • The key reaches the attacker. Storm-0558 compromises a Microsoft engineer's corporate account; through it, they reach the debugging environment and the key sitting in the dump.
  • From May 15, 2023 — Using the key, the actor forges authentication tokens and begins accessing email at ~25 organizations via Outlook Web Access and Outlook.com.
  • The boundary that wasn't there — A token-validation error allows the consumer signing key to produce tokens accepted for enterprise Azure AD mailboxes. One leaked key now reaches far beyond the domain it belonged to.
  • June 27–29, 2023 — Microsoft blocks tokens signed with the key and then replaces the key, ending the forging.
  • July 11, 2023 — Public disclosure.
  • Sept 6, 2023 — Microsoft publishes its root-cause findings: the crash-dump leak, the environment crossing, and the validation flaw.

The pivot point

The pivot is not the compromised engineer account, and not even the leaked key on its own. It is the validation flaw that erased the line between two trust domains.

Here is why that is the heart of it. A signing key is not a password; it is the authority that makes passwords unnecessary. The entire identity system is built to trust, without further question, anything that key signs. So the security of a signing key rests on two assumptions: that it can never leave its vault, and that its authority is strictly scoped — a consumer key vouches only for consumer identities. Storm-0558 broke both at once. The key left its vault. And the scope check that should have said "this is a consumer key, it cannot speak for an enterprise mailbox" did not fire. With both gone, the attacker held a universal forger: the ability to produce cryptographically valid tokens for accounts across an entire boundary they were never supposed to touch.

And the cruelest property of a forged token is that it is, by every check the system performs, real. There is no failed login to alert on, no impossible-travel anomaly, no brute-force pattern. The authentication layer cannot catch it, because the authentication layer is exactly what was counterfeited.

What would have caught it

Naming controls, not products.

Keys that physically cannot leave. Signing keys belong in hardware (HSMs) where the private material is non-extractable and can never appear in memory, logs, or a crash dump. The single root fix is that the key was extractable enough to land in a dump at all.

Scope and issuer validation that actually fires. A token's signer must be checked against what that signer is allowed to vouch for. Consumer key, consumer accounts — full stop. The flaw here was a missing boundary check, and boundary checks between trust domains are the load-bearing walls of federated identity.

Scrubbing secrets out of crash dumps and debugging paths. Memory dumps move around for legitimate reasons. Treating them as potential carriers of key material — and scanning/scrubbing them before they cross any environment boundary — closes the path the key actually traveled.

Detection that doesn't depend on a failed login. Because forged tokens authenticate cleanly, the only place to catch this is downstream: anomalous mail-access patterns, tokens whose claims don't match any real sign-in event. That requires comprehensive access logs — which brings us to the last mile.

The last mile

This looks, at first, like a pure vendor failure, and the key management absolutely was. But follow what it meant for the customers, because that is where the last mile lives.

A victim organization did nothing wrong at the authentication layer and could do nothing right there either — the tokens were valid. Their only hope of noticing was downstream: detailed logs of which mailboxes were accessed, by what, when. And here is the part that turned a vendor's key failure into a customer's blind spot: the access logging needed to detect this was, for many organizations, gated behind a premium licensing tier. Plenty of the affected customers did not have, by default, the data required to investigate whether their own email had been read.

That is a last-mile failure of a specific and instructive kind. The vendor owned the trust root and broke it. The customer owned the consequences but was handed neither the ability to prevent it (you cannot defend against a forged token) nor, without paying more, the ability to detect it. The span between "the identity authority was counterfeited" and "the customer can see identity abuse in their own tenant" was owned by no one and, worse, partly paywalled. After enough public pressure, the deeper logging was made broadly available — which is itself an admission that the detection mile had been on the wrong side of a paywall.

The durable lesson is uncomfortable: when you depend on a provider's identity authority, you inherit the blast radius of that authority's failures, and your only real leverage is detection. So the question to ask of any identity provider is not just "how do you protect your signing keys," but "when your trust root fails, what will I be able to see, and do I have to pay extra to see it?" The answer defines how much of this particular last mile you are allowed to own.

For defenders

Five things you can check this week.

  1. Turn on — and retain — the access logs that show token and mailbox use. If detecting forged-token access requires a license tier you don't have, that gap is your finding number one.
  2. Alert on access without a matching sign-in. Mail or resource access that corresponds to no real authentication event is the signature of a forged or replayed token.
  3. Inventory your trust-root dependencies. Know which providers' signing authority your identity rests on, and what their key-protection and transparency posture is.
  4. Demand HSM-backed, non-extractable signing keys from providers, and ask how they keep key material out of dumps and logs.
  5. Plan for "the token was valid." Build a response assumption that some intrusions will pass authentication cleanly, so detection and containment live in your logs, not your login screen.

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

Sources

#microsoft #storm-0558 #signing-key #token-forgery #last-mile