Microsoft Storm-0558, the seven-year-old signing key.

Summary

In May 2023, discovered June to July 2023, Microsoft detected anomalous access to Exchange Online mailboxes belonging to approximately 25 organisations, including US government agencies. Investigation revealed that the attacker had forged OAuth tokens using a stolen Microsoft Services Account (MSA) signing key, a key used to sign authentication tokens for consumer Microsoft accounts, not the separate Azure AD (now Entra ID) enterprise signing keys.

The MSA key itself dated to 2016. Microsoft's subsequent post-incident investigation concluded the key had likely been exposed through a Windows crash dump that captured the key material during a 2021 signing-process crash; the crash dump was later accessed by an engineer whose corporate account was subsequently compromised, allowing the key to move from Microsoft's production environment into the attacker's hands. The attacker then exploited a separate token-validation flaw to use the consumer-key to forge tokens for enterprise accounts, a cross-boundary bypass that should have been architecturally impossible.

Timeline (per Microsoft disclosures and the CSRB report)

Attack chain

1. Key generation (2016). An MSA consumer-account signing key generated in Microsoft's production environment.
2. Key exposure via crash dump (2021). A crash in Microsoft's consumer signing service produced a memory dump that included the key material. Sanitisation of such dumps depended on a "key scrubber" component that failed to identify this particular key.
3. Dump movement to corporate environment. The crash dump was moved from Microsoft's production debugging environment into the corporate debugging environment, a crossing that should have triggered stricter handling.
4. Engineer-account compromise. Storm-0558 (through a separate initial-access path, not fully disclosed) compromised a Microsoft engineer's corporate account that had access to the corporate debugging environment and the exposed crash dump.
5. Token validation flaw. The stolen key was an MSA consumer key, which should not have been valid for enterprise Exchange Online. However, a token-validation flaw in Microsoft's authentication library, subsequently fixed, accepted consumer-signed tokens for enterprise endpoints under certain conditions.
6. Token forgery. Storm-0558 crafted OAuth tokens signed with the 2016 key and submitted them against Exchange Online for targeted mailboxes.
7. Mailbox access. Approximately 60,000 State Department emails and mailbox content at ~25 organisations, including senior US officials, accessed over several weeks.

NHI root cause analysis

Multiple OWASP NHI Top 10 risks converge in Storm-0558:

• NHI1, Improper offboarding. The dominant failure. A signing key from 2016 was still valid in 2023. Seven years past any reasonable rotation schedule. Microsoft's own post-incident guidance acknowledged that the key should have been retired far earlier.
• NHI7, Long-lived secrets. Same root cause from a different angle. Signing keys for production authentication services should rotate on a schedule, typically measured in years for infrastructure keys, but on an active rotation curve, not indefinite life.
• NHI2, Secret leakage. The crash dump was the leakage vector. A signing key should not be present in memory dumps; where scrubbing depends on a fallible component, secondary controls (never moving the dump to a lower-security environment, encrypting dumps at rest, key-specific identification patterns) are needed.
• NHI4, Insecure authentication. The token-validation flaw, accepting consumer-signed tokens for enterprise endpoints, is a cross-boundary authentication bug. In a mature NHI architecture, consumer and enterprise signing boundaries are cryptographically separated.

The US Cyber Safety Review Board report (April 2024)

The Cyber Safety Review Board (CSRB), established by CISA after the Colonial Pipeline and Log4Shell incidents, issued an unusually critical report on Storm-0558 in April 2024. Key conclusions:

• The intrusion was preventable with proper key-lifecycle management.
• Microsoft's security culture was "inadequate" and "requires an overhaul," particularly given the company's ubiquity in government and enterprise.
• Microsoft's initial public communications about the root cause were later revised, reducing confidence.
• Recommendations included mandatory post-incident reviews, improved customer-facing logging (not monetising basic log access), and broader security culture changes.

Microsoft's subsequent "Secure Future Initiative", announced in late 2023 and expanded following the CSRB report, committed to (among other things) eliminating legacy authentication, reducing long-lived credentials, and making security an explicit performance objective for senior leadership.

Impact

• Approximately 60,000 US State Department emails accessed.
• Mailbox access to ~25 organisations total, including senior US officials such as Commerce Secretary Gina Raimondo and US Ambassador to China Nicholas Burns at the time.
• Substantial diplomatic and intelligence implications given the sensitivity of accessed communications during a period of elevated US to China tensions.
• Drove widespread US Federal Government re-evaluation of cloud-vendor dependency concentration, with CISA issuing Emergency Directive 23-02 requiring federal agencies to verify log access for detection.
• Catalysed industry-wide attention to signing-key lifecycle management and crash-dump hygiene.

Mitigation playbook

Lessons for any organisation operating significant signing infrastructure:

1. Inventory every signing key. Age, purpose, current use, rotation schedule, revocation procedure. If you cannot produce this in an hour for all production-signing keys, you have a Storm-0558-style exposure.
2. Rotate on a schedule. Signing keys should have defined maximum lifetimes and automated rotation wherever feasible. Indefinite-lifetime signing keys are OWASP NHI7 findings waiting to happen.
3. Cryptographic boundary separation. Consumer signing, enterprise signing, and sensitive-environment signing should use different keys with validated enforcement that cross-boundary tokens are rejected.
4. Crash-dump hygiene. Production crash dumps should be handled in dedicated, high-security environments. Movement to corporate/developer environments should require explicit sanitisation with verification.
5. Log access for customers. Don't paywall the logs that customers need to detect anomalous access. CISA's Emergency Directive made this explicit for federal agencies; enterprise customers should demand the same of their cloud providers.
6. Tabletop the Storm-0558 scenario. "An old key of ours was stolen and is being used to forge tokens right now" is a high-impact scenario worth exercising.

Lessons that transfer

• Time is the enemy of cryptographic assets. Every signing key, every API key, every certificate that persists beyond its useful life is a future incident.
• Crash dumps are a credential leakage vector. Treat production memory dumps as sensitive data requiring dedicated handling.
• Architectural boundaries need runtime enforcement. "Consumer keys can't work against enterprise endpoints" only counts if the runtime validation rejects them. Design-time assumptions that are not enforced are vulnerabilities.
• Vendor security culture matters. The CSRB made this explicit. Customers have limited visibility into vendor security cultures, but they can ask pointed questions (rotation schedules, incident-review frequency, security objectives for leadership) that reveal maturity.
• Post-incident narrative matters. Initial root-cause statements that are later revised reduce trust. Err toward cautious, confirmed statements; stand behind them.

Frequently asked questions

What is the Storm-0558 timeline of events?

In broad outline: a Microsoft consumer signing key was obtained by the actor, then used to forge authentication tokens that were accepted for enterprise accounts owing to a validation flaw. Access to mail data across a number of organisations followed, and was detected by a customer rather than by Microsoft, prompting investigation, key revocation and a subsequent Cyber Safety Review Board examination. Microsoft's own incident write-ups are the authoritative source for exact dates and we recommend working from them.

What was the Microsoft Storm-0558 incident?

A 2023 intrusion in which forged authentication tokens, signed with a stolen Microsoft signing key, were used to access email belonging to a number of organisations including government bodies. It is the clearest illustration of why cryptographic key material is a non-human identity concern: the compromise was not of an account or a password but of the key that vouched for identity itself, so every downstream control that trusted that key was bypassed.

Why is Storm-0558 relevant to non-human identity governance?

Because it collapses the distinction between credential security and identity infrastructure. A signing key is a non-human identity of the highest possible privilege: everything it signs is trusted. The lessons that generalise are key inventory and ownership, bounded key lifetimes with practised rotation, and validation logic that fails closed when a token's provenance does not match its intended scope.

Was the affected key ever supposed to work for enterprise accounts?

No. The key in question was a consumer signing key, and the reason forged tokens were accepted for enterprise accounts was a flaw in token validation rather than an intended trust relationship. That is the detail most worth carrying into your own architecture: an identity boundary that exists in design but is not enforced in validation code is not a boundary.