A Signing Key That Should Not Have Worked — But Did
In September 2023, Microsoft published a post-incident review that outlined the attack chain behind the Storm-0558 intrusion. The attacker had obtained a 2021-vintage Microsoft Account (MSA) consumer signing key — the cryptographic credential used to sign authentication tokens for consumer services like Outlook.com and Xbox Live. This was not an enterprise Azure Active Directory (now Entra ID) signing key. It was a consumer-tier key. And it should have had no authority over enterprise Exchange Online resources whatsoever.
The problem: Microsoft's GetAccessTokenForResource API, which Exchange Online used to validate authentication tokens, contained a code path that did not properly enforce the isolation between consumer and enterprise token signing authorities. A forged token signed with the consumer MSA key, targeting an Exchange Online enterprise resource, passed validation checks it should have failed. Storm-0558 discovered this gap — either through structural analysis of Microsoft's token validation logic, or through prior access — and exploited it systematically to access the email of approximately 25 organisations over roughly one month.
The State Department's security team noticed anomalous MailItemsAccessed events in Microsoft Purview audit logs — a premium licensing feature that logs every individual email access event, including the source token and IP. Without that specific audit capability, the intrusion might not have been detected through Microsoft's own monitoring for significantly longer. Microsoft's standard audit logs did not contain the fidelity required to identify the anomaly. The detection was a consequence of a US government security team that had licensed premium audit features and built alerting on access patterns — not a consequence of Microsoft's own detection capabilities identifying the intrusion proactively.
How Storm-0558 Obtained a Microsoft Signing Key
Microsoft's forensic investigation concluded that the MSA signing key was likely obtained from a crash dump generated following a consumer signing system failure in April 2021. The crash dump contained the signing key in its process memory state. Crash dumps from signing system failures are supposed to be scrubbed of cryptographic material before transfer to debug environments. In this case, Microsoft's investigation assessed that the scrubbing process had failed, and the crash dump containing the key material had been transferred to a debug environment connected to Microsoft's corporate network.
Storm-0558 is assessed by US intelligence agencies to be a Chinese state-sponsored actor with a track record of targeting government email infrastructure. Their access to a Microsoft corporate environment — possibly via a compromised engineer account — would have provided the opportunity to identify and exfiltrate the key from the debug environment. Microsoft stated that it does not have complete forensic evidence confirming this specific access path, acknowledging gaps in log retention that predated the incident.
The key had not been rotated between 2021 and the discovery in 2023 — a two-year window during which the compromised key material remained valid. Microsoft's key rotation procedures and the monitoring for unauthorized use of signing keys both failed to identify that an active signing key had been exfiltrated and was being used to forge tokens against production services. The architectural lesson is not simply 'rotate keys more frequently.' It is that signing key use should be monitored for anomalous issuance patterns with automated alerting — forged tokens have distinguishable characteristics from legitimately issued tokens if the monitoring capability exists.
The Boundary Failure: Consumer Keys in Enterprise Token Validation
Microsoft's identity platform serves two distinct populations: consumer accounts (personal Outlook.com, Xbox, OneDrive) and enterprise accounts (Entra ID, Exchange Online, SharePoint in organisational tenants). These populations have different identity providers, different signing authorities, and different trust levels. An authentication token signed for a consumer account should have zero authority over enterprise resources. This is not a subtle technical constraint. It is a fundamental access control boundary.
The bug that Storm-0558 exploited was a failure to enforce this boundary during token validation. When Exchange Online received a token for an enterprise resource, the validation path that was exercised did not check whether the signing key in the token's header was authorised to sign tokens for enterprise-tier resources — only whether the cryptographic signature was valid against a known key. A consumer signing key produced a cryptographically valid signature. The enterprise resource accepted it.
Microsoft remediated the issue by updating token validation logic to enforce strict separation between consumer and enterprise signing authorities, and by rotating the compromised key. They also extended access to premium audit log features — MailItemsAccessed and cloud app security logs — to all government customers regardless of licensing tier, in direct response to the criticism that detection had depended on a paid audit capability that most organisations did not have. The regulatory and Congressional response to the incident led to formal CISA guidance on cloud audit logging as a minimum baseline for federal agencies.
What the Cloud Security Community Missed for Two Years
The most significant finding in the Storm-0558 incident is not the attack technique — it is the two-year gap between the key compromise (2021) and the detection (2023). A valid signing key for one of the world's largest identity platforms was in the possession of a Chinese state-sponsored threat actor for approximately two years before a single US government security team's anomaly detection identified its use.
During those two years, Microsoft's own security monitoring did not identify that a signing key it managed had been exfiltrated and was being used operationally. Every authentication token validation across Exchange Online processed normally. Every audit event generated by Storm-0558's mailbox access appeared as a legitimate access event because the token was cryptographically valid — it was signed with a real key, not a forged signature in the traditional sense. The attack was not an anomaly detectable by signature-based systems. It was a valid token generating valid events from an unexpected geographic source.
The implications extend well beyond Microsoft. Every cloud platform that maintains signing keys for authentication token issuance faces the same fundamental risk: key compromise without detection enables persistent, cryptographically legitimate access that standard security monitoring will not identify. Hardware Security Modules (HSMs) for key storage, continuous audit of token issuance volume and geographic distribution, automated alerting on anomalous resource access patterns in audit logs, and Continuous Access Evaluation (CAE) to invalidate tokens on policy changes — these are the controls that change the detection window from two years to hours.