Storm-0558 and Cloud Key Theft Profile: Forged Tokens and Signing Key Protection

Storm-0558 showed that whoever holds an identity provider's token signing key does not need passwords, MFA bypasses or phishing: they can mint access to any account that trusts that key. This profile covers the China-based actor Microsoft tracks as Storm-0558, the 2023 Exchange Online intrusion, and the wider class of attack it represents: theft of cloud signing keys and the forging of tokens. It focuses on three defensive levers the official reviews kept returning to: protecting signing keys, validating tokens properly, and having the logs to see misuse. It is written for identity architects, cloud security engineers, application developers who validate tokens, and SOC teams. The incident timeline itself is in the Microsoft Storm-0558 Key Breach 2023 analysis and is not repeated here.

Key takeaways

• A signing key is the most privileged non-human identity there is. One 2016 consumer key, still trusted in 2023, let the actor forge tokens that Exchange Online accepted for enterprise mailboxes.
• Signature checks are not token validation. Microsoft said its shared libraries verified signatures but did not automatically validate key scope, and mail developers assumed they did; relying parties must check issuer, audience and tenant as well.
• Rotation that stops silently is a failure mode. The CSRB found manual rotation of consumer keys was halted in 2021 after an outage, with no alert for old keys still in use.
• Logging decided who could see the attack. A US government agency detected it with the MailItemsAccessed event, which at the time required premium licensing; the CSRB said paid-tier security logging should stop.
• Key protection is now hardware-backed and automatic at Microsoft. Its April 2025 Secure Future Initiative report says Entra ID and MSA signing keys moved to HSMs with automatic rotation; customers should hold their own keys to the same standard.

Who they are (names and aliases)

Storm-0558 is Microsoft's temporary designation ("Storm-" plus a number is used for developing clusters). Microsoft assesses with moderate confidence that it is a China-based actor with espionage objectives, operating largely during Chinese working hours on weekdays, and distinct from Violet Typhoon (ZIRCONIUM, APT31) despite minor overlaps. Microsoft's own analysis page records that the actor was renamed Antique Typhoon in August 2024. The Cyber Safety Review Board (CSRB) assessed it as affiliated with the People's Republic of China. At the time of writing there is no MITRE ATT&CK group entry for Storm-0558 or Antique Typhoon in ATT&CK v20, so the technique mapping below is NHI Mgmt Group's own mapping from Microsoft's and the CSRB's descriptions. For context on other state actors, see the Threat Actor Groups Guide.

Targeting and motivation

The objective is political and diplomatic intelligence through email. Microsoft lists US and European diplomatic, economic and legislative bodies, individuals connected to Taiwan and Uyghur interests and, historically, media, think tanks and telecommunications providers. Microsoft says the actor had shown interest in OAuth applications and token replay since at least August 2021.

Post-compromise activity was limited to reading and exfiltrating email, according to Microsoft. The CSRB also judged that the key and validation flaw together could have given access to far more than the accounts actually read.

Tactics and techniques (MITRE ATT&CK)

How they abuse identities and credentials

The trust chain that failed

Microsoft's September 2023 report, corrected on 12 March 2024, sets out the chain. In September 2018 Microsoft introduced a common key metadata endpoint for converged consumer and enterprise identity and documented that applications must validate key scope. Shared libraries provided a signature validation API but did not perform scope validation automatically. When the mail system moved to the common endpoint in 2022, its developers assumed the library validated fully, so enterprise mail accepted tokens signed with a consumer key. The March 2024 addendum states that no crash dump containing the key has been found, and that moving crash dump material out of the signing environment, then permitted, is now prohibited.

Signing key protection

Microsoft's April 2025 Secure Future Initiative report states that Entra ID and MSA access token signing keys now sit in hardware security modules and virtualisation-based security with automatic rotation, that the MSA signing service runs on Azure confidential VMs with Entra ID migrating, and that 90% of Entra ID tokens for Microsoft apps are validated by one hardened identity SDK. See the Cryptographic Key Management Guide and the Code Signing Security Guide for applying the same discipline to your own keys.

Token validation for relying parties

The same failure can happen in any application that accepts tokens from a multi-tenant identity provider. Microsoft's identity platform documentation for access tokens sets the baseline:

• Audience: A web API must only accept tokens whose aud is one of its own App ID URIs.
• Issuer: iss must exactly match the issuer in the metadata for the token version; for multi-tenant apps using the common or organizations endpoints, substitute the token's tid into the templated issuer and require an exact match.
• Tenant: tid must be a GUID and must be the tenant segment of iss; personal accounts use the consumers tenant 9188040d-6c67-4c5b-b112-36a304b66dad, which an enterprise-only API should reject.
• Key selection: Select the signing key by kid from the jwks_uri in the metadata, check each key's own issuer property, refresh keys about every 24 hours and when an unknown kid appears.
• Identity: Treat tid plus sub as the identity, never sub alone.

See the JWT Security Guide and the Identity Provider and SSO Security Guide.

Notable incidents

Forged and stolen token attacks recur across the industry. The SolarWinds compromise used forged SAML tokens from stolen signing material, and the Entra ID Actor Token Flaw 2025 was again a cross-tenant token validation weakness.

Detection and defence

Logging you need before an incident

• MailItemsAccessed: Records mail access over POP, IMAP, MAPI, EWS, Exchange ActiveSync and REST. Sync events are one per folder (treat the folder as exposed); Bind events are per message, aggregated per two-minute interval. Microsoft documents it as enabled by default for Office 365 and Microsoft 365 E3/E5 users.
• Retention: AA23-193A cites OMB M-21-31: at least 12 months active and 18 months cold storage for Microsoft audit logs. Export to a SIEM rather than relying on default retention.
• Baselines: AA23-193A says the agency caught the activity because an AppID that did not normally access mailbox items did so. Baseline AppID, ClientAppID, ClientInfoString and source IP per mailbox.
• Token anomalies: The CSRB said alerting on tokens that do not match the provider's own generation patterns could likely have caught the intrusion. Customers can approximate this by alerting when tokens from the consumer tenant, unexpected issuers or unknown key IDs reach enterprise APIs.

See the Cloud Logging and Audit Trail Guide and the Microsoft 365 Security Guide.

Implementation sequence

1. Inventory: List every signing key you own (IdP, SAML, JWT issuers, code signing) with its scope, age, storage and relying parties.
2. Move keys to hardware: Migrate to HSM-backed, non-exportable keys; pilot one issuer, publish the new key in metadata alongside the old one, then switch signing.
3. Automate rotation: Schedule rotation with overlap; alert if a rotation job fails or a key exceeds its lifetime. Roll back by re-publishing the previous public key while the cause is fixed, never by extending a compromised key.
4. Fix validation: Audit relying applications for iss, aud and tid checks; add negative tests with tokens from the wrong tenant, wrong audience and an unknown kid to CI.
5. Enable and retain logs: Confirm MailItemsAccessed and sign-in logs are on, exported and retained to M-21-31 levels; build AppID baselines.
6. Exercise: Run a tabletop on "our signing key is stolen", including emergency revocation and the customer notification path.

Decision guidance

• Using a cloud IdP only: Your lever is validation, logging and contracts. AA23-193A advises reviewing cloud provider contracts for logging and breach notification terms.
• Running your own token issuer: You carry the full key protection burden; managed HSM services are usually cheaper than building enclave controls yourself.
• Smaller organisations: Use well-maintained identity libraries with issuer validation switched on, rather than hand-rolled JWT checks.

Metrics

• Percentage of signing keys held in HSMs or equivalent non-exportable storage.
• Number of keys past their planned retirement date (target zero).
• Percentage of relying applications passing negative token validation tests.
• Percentage of mailboxes with MailItemsAccessed enabled and exported to the SIEM.
• Audit log retention achieved versus the 12 plus 18 month M-21-31 target.

Framework mapping

Practitioner checklist

• Inventory every signing key, its scope, age, storage location and relying parties.
• Hold signing keys in HSMs or confidential computing, with no export path into dumps or debug environments.
• Automate key rotation and alert on stalled rotation and on keys past retirement.
• Validate iss, aud, tid and signing key issuer in every API, and reject consumer-tenant tokens where only work accounts are expected.
• Add negative token tests (wrong tenant, wrong audience, unknown kid) to CI.
• Confirm MailItemsAccessed and sign-in logs are enabled, exported and retained for at least 12 months active.
• Baseline AppIDs and clients per mailbox and alert on new ones.
• Separate engineering and administrator identities and require phishing-resistant MFA for them.
• Review cloud provider contracts for logging, retention and breach notification terms.

Standards and references

• Cyber Safety Review Board: Review of the Summer 2023 Microsoft Exchange Online Intrusion
• CISA and FBI: Enhanced Monitoring to Detect APT Activity Targeting Outlook Online (AA23-193A)
• Microsoft MSRC: Results of Major Technical Investigations for Storm-0558 Key Acquisition
• Microsoft Threat Intelligence: Analysis of Storm-0558 techniques for unauthorized email access
• Microsoft Learn: Access tokens in the Microsoft identity platform
• Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
• Microsoft: Secure Future Initiative April 2025 progress report
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Microsoft Storm-0558 Key Breach 2023 · Cryptographic Key Management Guide · Token and Session Security Guide · Entra ID Security Guide · ITDR Guide