Four Failures, Zero Excuses

A forgotten 2016 signing key. No automated rotation. A shared authentication endpoint that crossed trust boundaries nobody bothered to enforce. And zero capability to detect any of it.
Before we talk about the fix, we need to talk about just how bad the starting position actually was.

---

Welcome back. In the last post we covered Storm-0558 and why the CSRB was so scathing about it.

Quick recap if you’re just joining. A Chinese threat actor used a forgotten 2016 signing key to forge authentication tokens, walked into 22 organizations’ Exchange Online mailboxes, stayed for six weeks, and Microsoft had no idea until a government agency called them.

The root cause of how the key was stolen remains officially unknown to this day.

This post is about the specific failures that made it possible. Not the vague hand-waving version. The actual, specific, architectural problems, one by one. Because “bad key management” covers a lot of ground and it’s easy to wave at it without understanding what was really going on.
There were four failures. And they stacked on top of each other beautifully. If you were designing a worst-case scenario for a cloud identity provider, you’d struggle to do better.

Failure 1: Keys in Software Storage

Microsoft’s token signing keys for Entra ID and the Microsoft Account service were not stored in hardware. They lived in software-managed storage, which means a sufficiently privileged attacker who could reach that storage could extract the key material.

That appears to be exactly what happened, though the precise method remains unconfirmed. What the CSRB found is that Storm-0558 had compromised an engineer’s device at a company called Affirmed Networks, a 5G tech startup that Microsoft acquired in April 2020.
The important detail is that the compromise happened before the acquisition closed. When Microsoft welcomed the Affirmed Networks team in, they handed corporate credentials to a device Storm-0558 had already been sitting on. Microsoft failed to assess the security posture of the devices it was onboarding. So it didn’t just inherit a company. It inherited an active intrusion.

The attackers used that foothold between April and August 2021 to access Microsoft’s corporate network and search SharePoint specifically for documentation on Azure service management and identity systems. That was the groundwork laid two years before the 2023 intrusion. Patient, targeted, and entirely undetected.

Failure 2: Nobody Was Rotating the Keys

There was no automated rotation. Keys rotated manually, and the 2016 MSA key was supposed to be retired in March 2021.
Here’s the specific reason it wasn’t. In 2021, a manual key rotation caused a major cloud outage. Microsoft’s response was not to fix or automate the rotation process.
They paused manual rotations entirely and put no alerting in place to flag that keys were aging. The 2016 key sat there, forgotten and live, for two more years.

A seven-year-old signing key in production with nobody watching it. The decision to stop rotating was bad. The fact that nobody noticed for two years was worse. The fact that there was no system to even flag it was the thing that should keep a CISO up at night.

Failure 3: Broken Trust Boundaries

Someone at Microsoft once had the idea to make authentication simpler for developers. They created a shared OpenID Connect (OIDC) discovery endpoint that listed signing keys for both the consumer Microsoft Account service and the enterprise identity system in one place. A convenience feature. Reasonable enough on its face.
The problem is that the SDKs were never updated to enforce the trust boundary that endpoint violated. Consumer MSA and enterprise Entra ID are supposed to be completely separate systems. A key from one should not be able to do anything in the other. But because the SDKs just trusted whatever the shared endpoint listed, that boundary didn’t exist in practice.

So when Exchange Online received a token signed with the 2016 consumer key, the validation logic accepted it as legitimate. Two entirely separate systems, made cross-compatible by a feature request that created a hole nobody went back to close. That’s not a subtle architectural flaw. That’s a fundamental failure of separation between two systems that were never supposed to share keys, left sitting open for years.

The plumbing wasn’t just inconsistent.
It was broken at the foundation, and had been for a long time.

Failure 4: No Way to Catch It

Once a forged token was in flight, there was nothing to catch it. The token looked legitimate because it was signed with a real key. Microsoft had no forged-token detection whatsoever. No stateful checks, no anomaly detection, nothing. A perfectly forged token was indistinguishable from a real one.

This is ultimately why Storm-0558 stayed undetected for six weeks. Not just because they were good. Because Microsoft had built no mechanism to catch them even if they had been obvious about it.

• Keys in software storage.
• No automated rotation because a previous rotation caused an outage, so they just stopped.
• A shared OIDC endpoint that made consumer keys valid for enterprise services, never enforced.
• No forged-token detection, so abuse was invisible once a token was minted.

The Part That Should Really Sting

Here’s the part that should make you put your coffee down.
These weren’t exotic attack vectors nobody had thought of.
They weren’t zero-days. They were gaps in basic controls that Microsoft’s peers had already closed, and the reason those peers closed them is worth saying out loud.

Google got hit by the same group in Operation Aurora back in 2009 and immediately hardened their token infrastructure, moving to stateful tokens with unique IDs, automated key rotation, and hardware-backed authentication.
AWS built request-level signing so that every API call is cryptographically tied to exactly what it authorizes.
Oracle gave each customer tenancy its own key pair.
AWS and Oracle drew the same conclusions without even needing to get hit. Microsoft, unlike its peers, essentially twiddled their thumbs and waited fourteen years for their own Operation Aurora.

The Board’s assessment of security practices at other cloud service providers, which maintained security controls that Microsoft did not.

The CSRB didn’t tuck that away in a footnote. It’s Finding #3. Named. Documented. Compared. That sentence doesn’t need interpretation. It’s the board saying, politely, that Microsoft’s peers got the memo fourteen years ago and Microsoft filed it under “definitely, maybe later.”

So that’s the before picture.
Keys in software.
No rotation.
A trust boundary violated by a feature request and never fixed.
No detection.
And a peer comparison that was, to put it diplomatically, not flattering.

The next post is about the fix. And to Microsoft’s credit, when they actually got to work on it, they didn’t just patch the minimum. They built something worth understanding.

More to follow.

Questions or pushback welcome. Drop a comment.