threatintel
actor tracker
Named attack · kill-chain walkthrough

Storm-0558

A stolen consumer signing key forges enterprise mail access for 25 organizations

Storm-0558 (PRC, espionage)May 15 – July 12, 2023 (detected June 16; remediated July 12)High confidence

Microsoft attributes this activity with high confidence to Storm-0558, a threat actor assessed to be based in China and focused on espionage against Western European and U.S. government targets. No criminal indictment has been issued as of the time of writing.

Storm-0558 exploited two compounding failures inside Microsoft's identity infrastructure to read email from approximately 25 organizations — including the U.S. State Department and Commerce Department — without ever phishing a single victim employee. The actor first obtained a 2021-era Microsoft Account (MSA) consumer signing key via a crash dump that had been inadvertently moved from an isolated production signing system onto the corporate network, where it was later accessible after Storm-0558 compromised a Microsoft engineer's corporate account. A separate token-validation logic flaw in Microsoft Authentication Library (MSAL) and related systems then caused enterprise Azure AD / Entra ID token verification to incorrectly accept tokens signed with the consumer key. Together, these allowed the actor to forge valid Outlook Web Access and Exchange Online tokens for any Azure AD tenant — a structural identity-layer compromise with no endpoint malware required. Detection came only when a U.S. State Department analyst noticed anomalous MailItemsAccessed audit events — events gated behind the M365 E5 license tier, a restriction CISA would later force Microsoft to lift for all tenants.

scene 00 / 07
Production signingsystem (air-gapped)MSA consumer keylives here onlyProcess crashApril 2021race condition: key not scrubbedbefore dump writecrash dumpcontains live MSA keyT1552.004 · T1588.004(redaction failed)moved off air-gapStorm-0558PRC-linked espionageMITRE G1040Corporate debug environmentcrash dump (+ MSA key) now reachablefrom corporate network accountsMSFT engineercorp accountcompromised · T1078MSAL validationlogic flaw: consumer keyaccepted for enterprise tokensT1606MSA signing keyconsumer key in actor's possessionT1552.004Azure AD / Entratoken validationincorrectly acceptsconsumer-signed JWT · T1606.002Forged OWA / Exchange Online tokensOIDC access tokens — signed with MSA keyT1606.002 · T1606 · T1078.004U.S. State DeptAmb. Nicholas Burnsmailboxes accessed · T1114.002Commerce DeptSec. Raimondo's officemailboxes accessed · T1114.002~23 more orgsEuropean govt accounts+ consumer accounts (names not confirmed)Identity-layer stealthno endpoint malware · no phishing of victims · tokens pass MSFT validationMailItemsAccessed audit events gated to M365 E5 — E3 tenants blindT1550.001 · T1078.004E5visibleE3 = blindno C2no IOCREST APIState Dept analystspots anomalous MailItemsAccessed events~June 16, 2023 · E5 license requiredMicrosoft respondsMSA key revoked · validation flaw patchedJuly 12, 2023CSRB report — April 2, 2024Microsoft security culture "inadequate"Audit log access expandedPurview Standard → all tenants, free
  1. Phase 01 · Resource Development — Key AcquisitionTA0042

    A 2021 crash dump inadvertently captured the MSA signing key and later left it reachable on the corporate network

    • In April 2021 a consumer-signing-system process crashed on Microsoft's production signing infrastructure. A crash dump was generated; due to a race condition in the dump-capture pipeline, the MSA signing key — which was supposed to be redacted before the dump was written — was present in the dump in plaintext.
    • Microsoft's MSRC September 2023 root-cause post describes the redaction failure as the result of a race condition: the signing-key material was not scrubbed because the redaction logic ran after the key had already been written to the dump buffer.
    • The crash dump was subsequently moved from the production isolated network — where signing keys are meant to remain — to the corporate debug environment, crossing the air-gap that was designed to protect key material.
    • Once in the corporate environment the dump, containing the live MSA signing key, became accessible from accounts on Microsoft's corporate network.
    • Microsoft's investigation could not definitively confirm that Storm-0558 obtained the key via this specific path, but stated it was the most probable explanation consistent with available forensic evidence.
  2. Phase 02 · Initial Access — Engineer Account CompromiseTA0001

    Storm-0558 compromised a Microsoft engineer's corporate account, gaining access to the debug environment where the crash dump resided

    • According to Microsoft's MSRC September 2023 post, Storm-0558 compromised the corporate account of a Microsoft engineer. The specific means of initial compromise of that account was not publicly disclosed by Microsoft.
    • With access to the engineer's corporate account, the actor could reach the debug environment to which the 2021 crash dump had been moved.
    • The Cyber Safety Review Board's April 2024 report noted that Microsoft lacked sufficient logging in this environment to allow forensic reconstruction of all access events, limiting the completeness of the root-cause investigation.
    • This phase illustrates how insider-risk controls and identity hygiene on developer workstations — not just production systems — are part of the key-material attack surface.
  3. Phase 03 · Credential Access — Token ForgeryTA0006

    The MSA consumer key forged enterprise Azure AD access tokens — a validation logic flaw let consumer-issued tokens pass enterprise verification

    • Microsoft's consumer (MSA) signing infrastructure and its enterprise Azure AD / Entra ID infrastructure use separate key hierarchies. MSA keys are not supposed to be valid for enterprise token signing.
    • However, a token-validation logic flaw in the Microsoft Authentication Library (MSAL) and related Azure AD verification code caused enterprise-side token validation to incorrectly accept tokens signed with the MSA consumer key.
    • Storm-0558 used the stolen consumer signing key to craft forged OpenID Connect (OIDC) access tokens targeting enterprise Azure AD tenants.
    • The forged tokens passed Microsoft's own validation stack and were accepted as legitimate, granting the actor access to Exchange Online and Outlook Web Access for any Azure AD tenant organization without any interaction with the target organization's identity system.
    • Wiz researchers noted in July 2023 that the scope of the signing key may have been broader than initially disclosed — potentially valid for additional Azure services beyond Exchange Online — though Microsoft disputed the full scope of that finding.
  4. Phase 04 · Collection — OWA / Exchange Online Mailbox AccessTA0009

    Forged tokens accessed OWA and Exchange Online for ~25 organizations from mid-May 2023; U.S. State Department and Commerce Department mailboxes confirmed among targets

    • Beginning around May 15, 2023, Storm-0558 used the forged tokens to access Outlook Web Access (OWA) and Exchange Online for approximately 25 organizations, per Microsoft's July 11 disclosure.
    • The U.S. State Department was among the confirmed targets. Reuters and multiple news outlets reported that the mailbox of U.S. Ambassador to China Nicholas Burns was among those accessed.
    • The Washington Post reported that the Commerce Department was also a confirmed victim, with mailboxes associated with Commerce Secretary Gina Raimondo's office among those accessed.
    • Both State and Commerce are U.S. government agencies with significant equities in U.S.-China policy, consistent with Storm-0558's assessed espionage mission.
    • Other victims included unspecified European government accounts and consumer accounts. Microsoft did not publicly name additional government victims.
    • Access was limited to email content; the actor used the GetMail and FolderBindings Exchange REST API calls, which are recorded only in the MailItemsAccessed audit event.
  5. Phase 05 · Defense Evasion — Identity-Layer StealthTA0005

    No endpoint malware, no phishing of victims — forged tokens looked like legitimate cloud authentication to every layer of defense

    • The attack required no malware on victim endpoints, no phishing of victim users, and no exploitation of a published CVE in victim infrastructure — it leveraged only the forged access token, which was indistinguishable from legitimate Microsoft-issued tokens.
    • Because the forged tokens passed Microsoft's own validation stack, cloud access logs showed normal-looking authenticated REST API calls. There was no anomalous authentication failure, no brute-force signal, and no endpoint telemetry.
    • The MailItemsAccessed audit event — which records individual mail-item access operations — was the only log source that could distinguish the anomalous access pattern from normal OWA use. This event is available only to Microsoft 365 E5 / E5 Compliance or Microsoft Purview Audit (Premium) license holders.
    • Tenants on lower license tiers (E3 and below) had no technical means to detect the intrusion independently from their own log data — a condition the CSRB characterized as a serious systemic failure and a Microsoft policy choice that effectively subsidized attacker stealth.
    • CISA's responding directive required Microsoft to expand MailItemsAccessed and related audit events to all license tiers at no additional cost — a policy reversal Microsoft implemented.
  6. Phase 06 · Detection & ResponseTA0040

    A State Department analyst spotted anomalous MailItemsAccessed events — possible only because State held an M365 E5 license

    • Around June 16, 2023, a U.S. State Department analyst noticed unusual MailItemsAccessed audit-log entries indicating mail item access from unexpected client IP addresses and user agents not associated with known State Department activity.
    • The State Department notified Microsoft, triggering Microsoft's internal investigation. Microsoft confirmed the anomaly and began tracing the token-forgery chain.
    • Microsoft revoked the compromised MSA signing key on July 12, 2023. Revocation invalidated all forged tokens derived from the key and terminated the actor's access.
    • Microsoft also deployed fixes to the token-validation logic flaw in MSAL and related Azure AD / Entra ID libraries to prevent consumer-issued tokens from being accepted for enterprise-scope validation going forward.
    • The detection depended entirely on the M365 E5 audit-log tier being in place at State. The CSRB report confirmed that without E5-tier audit logging, the intrusion would have gone undetected by the affected organizations.
  7. Phase 07 · Impact & AccountabilityTA0040

    CSRB found Microsoft's security culture inadequate; audit-log access policy reversed under government pressure

    • The Cyber Safety Review Board's April 2024 report concluded that the intrusion was preventable and that Microsoft had failed to maintain a security culture commensurate with the trust placed in it as critical cloud infrastructure for the U.S. government.
    • The CSRB found that Microsoft lacked sufficient logging across its own production and debug environments to support a complete forensic reconstruction of how the signing key was acquired — a finding it characterized as unacceptable for a provider of this scale.
    • Senator Ron Wyden wrote to CISA, the Department of Justice, and the FTC calling for accountability and urging the agencies to investigate whether Microsoft's practice of charging extra for security-grade audit logs violated its federal contracts.
    • Microsoft's policy of limiting MailItemsAccessed and other security-relevant audit events to M365 E5 / Purview Premium license holders was reversed under CISA pressure: Microsoft extended Purview Audit (Standard) to all license tiers at no additional charge.
    • The intrusion highlighted the structural risk of cloud identity monocultures: when a single provider's token validation is flawed, the blast radius extends across every tenant — government and commercial — simultaneously.
Diamond Model

Caltagirone / Pendergast / Betz 2013 — four-vertex attribution framework.

Adversary
  • Storm-0558 (PRC, espionage)
Capability
  • T1588.004
  • T1552.004
  • T1078
  • T1552
  • T1606.002
  • +1 more
Infrastructure
Victim
  • See narrative above
Primary sources