BIPI
BIPI

Microsoft Storm-0558: One Stolen Key, Two Identity Realms

Threat Intelligence

A consumer signing key from a 2016 crash dump ended up forging Azure AD tokens for government email. The CSRB report on Storm-0558 reads like a master class in key-management failures. A practitioner walk-through of what happened and what changed.

By Arjun Raghavan, Security & Systems Lead, BIPI · April 24, 2024 · 9 min read

#microsoft#storm-0558#azure-ad#government

Storm-0558 is the rare incident where the official post-incident review is the document defenders should read first. The US Cyber Safety Review Board's report on the campaign reads as a series of compounding key-management decisions, each individually defensible, that combined to let a PRC-linked actor forge identity tokens for at least 22 organizations including the US State Department and the Commerce Secretary's mailbox.

Timeline

  1. April 2016: a crash dump from a Microsoft engineering workstation captures process memory that includes an MSA (Microsoft consumer account) signing key. Internal policy says crash dumps with keys should not leave the production network. This one does.
  2. Years 2016 through 2021: the crash dump is moved into the corporate network during routine debugging. Token validators are written that, due to a separate bug, accept MSA-signed tokens for Azure AD scopes.
  3. Mid-2023: Storm-0558 obtains the MSA private key. The CSRB report concludes Microsoft could not definitively determine how.
  4. May 15, 2023: Storm-0558 begins forging tokens for Outlook Web Access against Azure AD accounts at targeted organizations.
  5. June 16, 2023: the US State Department detects anomalous email access via custom MailItemsAccessed audit-log analysis and reports it to Microsoft.
  6. July 11, 2023: Microsoft publishes the initial disclosure. Affected customers are notified.
  7. September 6, 2023: Microsoft publishes a deeper post-incident analysis with the crash-dump narrative.
  8. April 2024: the CSRB publishes its report concluding the intrusion was preventable and citing systemic issues at Microsoft.

Root cause

Two failures in series. The first was the key escape: a signing key reached a crash dump, the crash dump moved out of the secure zone, and the key sat in a corporate environment for years. The second was scope confusion: a token validator accepted MSA-issued tokens for Azure AD endpoints due to a flaw in shared libraries. Either failure alone would have been a finding. Together they meant one consumer-grade key could mint tokens for any tenant.

The CSRB language is unusual for a federal report: the intrusion was preventable and never should have occurred.

Attacker actions

Token forgery, targeted, quiet. Storm-0558 minted tokens for specific user mailboxes and authenticated to Outlook Web Access. Email was accessed and exfiltrated through normal-looking OWA traffic. The actor did not lateral within tenants and did not deploy malware. The objective profile is collection: read mail, leave no payload.

Detection signals

  • MailItemsAccessed events in tenants that did not normally see them at scale. This audit-log family was a paid-tier-only feature at the time, which became a public policy issue.
  • OWA sessions issued without a corresponding interactive sign-in event in the Azure AD sign-in logs.
  • Token issuer field set to MSA on tokens used against Azure AD resources. Once the validation flaw was understood, this became the cleanest IOC.
  • Anomalous JWT lifetimes or unusual claim sets on tokens reaching mail endpoints.

Lessons

  • Make MailItemsAccessed and equivalent audit signals available to every customer regardless of license tier. Microsoft moved on this after the incident; other vendors should not need the same prompt.
  • Audit signing key escape paths. Crash dumps, error reports, and memory snapshots can capture cryptographic material if the process is not segregated.
  • Strictly validate the issuer and audience claims in every token validator your team writes or vendors. Loose validation is the structural class behind this incident.
  • Demand transparency from cloud vendors after incidents. The CSRB pressure that produced the September analysis is a model worth requesting at smaller scale through procurement.

Microsoft's Secure Future Initiative, announced in late 2023 and elaborated through 2024, is the corporate response. The structural lesson for the rest of us is to assume that key escape happens and to build validators that fail closed on every claim that does not match the expected tenant, audience, and issuer triple. Storm-0558 was a watershed because it broke the most-trusted identity provider's signing surface. Treating it as a once-in-a-decade event is the wrong read; treating it as the new baseline is the correct one.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.