Cloud Security Office Hours Banner

Storm-0558 2023 — 2023

Step-by-step kill chain mapped to MITRE ATT&CK Cloud, sourced from official post-mortems and primary technical analyses.

April 2021 – June 2023 (2 year operation) Critical Azure AD / Exchange Online

Storm-0558 – Compromised Engineer → Crash Dump → Stolen MSA Signing Key → Forged Tokens → Government Email Espionage

Chinese nation-state actor Storm-0558 compromised a Microsoft engineer's corporate account, discovered a consumer MSA signing key that had accidentally been included in a crash dump in a debugging environment, and used it to forge authentication tokens. A token validation bug in Exchange Online accepted these consumer tokens as enterprise credentials, enabling access to ~25 organisations' email — including 60,000 US State Department emails — for weeks before discovery.

~25 organisations breached
60,000 State Dept emails exfiltrated
2 years initial intrusion to exploitation
Threat actor: Storm-0558 (PRC / Chinese SVR equivalent)
📄 MSRC July 2023 ↗ 📄 MSRC key acquisition investigation ↗ 📄 Wiz Research analysis ↗
🎯 Initial Compromise — Engineer Account
01
Microsoft engineer's corporate account compromised (April 2021)
T1078 – Valid Accounts

Storm-0558 targeted an engineer whose device had been compromised prior to joining Microsoft (likely during a company acquisition). After the engineer joined Microsoft, the attackers used this foothold to access Microsoft's corporate network — where they would remain for approximately two years before exploiting the signing key.

Hypothesis: Pre-acquisition device compromise; credentials reused on Microsoft corporate account
Dwell time on Microsoft network: April 2021 – ~June 2023 (2 years)
Log retention gap: Microsoft could not confirm exfiltration due to log retention policy limits
Nation State APTCorporate AccountAcquisition RiskT1078
🔑 Key Acquisition — The Crash Dump
02
Consumer MSA signing key found in crash dump in engineering debug environment
T1552 – Unsecured Credentials

A 2021 system crash in Microsoft's signing infrastructure generated a crash dump that, due to a race condition bug, incorrectly included consumer MSA signing key material that should never leave the isolated signing environment. The dump was copied to a debugging environment accessible to engineering accounts. Storm-0558, using the compromised engineer's account, accessed and exfiltrated the key.

Key leaked: Consumer MSA signing key (2016 vintage, still active)
How it leaked: Race condition bug caused crash dump to include signing key material
How accessed: Crash dump in debug environment — accessible via compromised engineer account
Microsoft quote: "Operational errors resulted in key material leaving the secure token signing environment"
MSA Signing KeyCrash DumpRace ConditionDebug Environment
🔐 Token Forgery — The Core Technique
03
Stolen MSA key used to mint forged authentication tokens for government targets
T1606.001 – Web Token Forgery

Starting May 15, 2023, Storm-0558 used the stolen MSA consumer signing key to forge OpenID v2.0 access tokens impersonating specific users at targeted government organisations. The tokens were correctly signed — any service validating them against Microsoft's published public keys would accept them as legitimate.

Token type: OpenID v2.0 access tokens (signed with MSA consumer key)
Blast radius (per Wiz): Could forge tokens for any Azure AD app supporting personal account auth — not just Exchange
Services potentially at risk: OneDrive, SharePoint, Teams, any app using "Login with Microsoft"
Token ForgeryMSA KeyOpenID v2.0T1606.001
🐛 Exploitation — Token Validation Bug
04
Exchange Online accepted consumer-signed tokens as enterprise credentials (SDK validation bug)
T1212 – Exploitation for Credential Access

Consumer and enterprise signing keys are separate systems and should only be valid for their respective scopes. However, the Exchange Online team had incorrectly assumed the Azure AD SDK validated token issuers by default — it didn't. This meant Exchange Online accepted the forged consumer-scoped tokens as valid enterprise credentials. An additional OWA GetAccessTokenForResource API bug let attackers generate fresh Exchange tokens from forged tokens.

The validation bug: Exchange Online assumed Azure AD SDK performed issuer validation — it didn't
OWA additional bug: GetAccessTokenForResource API issued fresh tokens from already-issued forged tokens
Result: Consumer MSA token → accepted as enterprise Exchange Online credential
Token Validation BugExchange OnlineOWA APIAzure AD SDK
📬 Collection and Exfiltration
05
Email access and exfiltration across ~25 government organisations via OWA REST API
T1114.002 – Remote Email Collection

Using PowerShell and Python scripts against the OWA REST API with forged tokens, Storm-0558 read and exfiltrated email from ~25 organisations including senior US State Department and Commerce Department officials. Access ran for at least 6 weeks before discovery.

Method: OWA Exchange Store REST API calls using forged tokens
State Dept loss: ~60,000 emails including communications of the US Ambassador to China
Other victims: Commerce Secretary Raimondo + senior officials across ~25 organisations
OWA REST APIEmail ExfiltrationGovernment EspionageT1114.002
🚨 Discovery
06
US State Dept detects via custom MailItemsAccessed alert ("Big Yellow Taxi") — June 16, 2023

The State Dept detected the breach via a custom alert rule triggered by the MailItemsAccessed audit event — which was only available to organisations that had purchased Microsoft's E5 license tier. Organisations on lower tiers could not see this event and were unable to detect the breach independently. Following CISA pressure, Microsoft extended MailItemsAccessed to E3 customers in September 2023.

Detection event: MailItemsAccessed — unknown application ID accessing mailboxes
Critical licensing gap: MailItemsAccessed was E5-only at time of breach · Most victims couldn't see it
Dwell time: ~6 weeks of confirmed email access; potentially 2 months total
MailItemsAccessedE5 Logging GapCustom Alert6 Week Dwell

🛡 How to Defend Against This Chain

Enable MailItemsAccessed auditing in Exchange Online — now available to E3. Alert on unknown application IDs accessing mailboxes. This was the only control that detected Storm-0558.
Explicitly validate token issuers in your applications — don't assume the SDK does it. For Azure AD apps, confirm tokens are signed by the correct key type for your audience. Don't rely on library defaults.
Protect crash dump pipelines — scan for key material before copying to non-isolated environments. Crash dumps should be treated as potentially sensitive and scanned for credentials and key material before being moved to debugging environments.
Treat acquired companies' devices as untrusted until fully re-enrolled under your MDM. Devices from acquisitions should go through a full wipe-and-re-enrol process before receiving corporate credentials.
Maintain an approved OAuth application inventory and alert on deviations. Alert on any application accessing mailboxes that is not in your approved inventory. Conditional Access policies can enforce application restrictions.