Storm-0558 (July 2023): A Stolen Signing Key and Forged Tokens Into Government Email

Retrospective: this article looks back at events from July 2023, written in 2026 with the benefit of hindsight.

In July 2023, Microsoft disclosed that a China-based threat actor it tracks as Storm-0558 had accessed email accounts at roughly two dozen organizations, including US government agencies, by forging authentication tokens. The attacker didn't phish users or guess passwords. It used a stolen Microsoft signing key to mint its own credentials.

1. Signing key obtainedStorm-0558 acquires a Microsoft account (MSA) consumer signing key. How it was stolen was never conclusively established.
2. Validation flawDue to a validation issue, Exchange Online accepts tokens signed with the consumer key for enterprise accounts.
3. Forged tokensThe actor forges authentication tokens and accesses mailboxes through Outlook on the web.
4. Customer detectionThe US State Department spots anomalous MailItemsAccessed events in its premium audit logs and alerts Microsoft.
5. FalloutMicrosoft revokes the key, expands default logging and later faces a critical Cyber Safety Review Board report.

For customers, the most important part of the story wasn't the key. It was how the intrusion was found: a customer noticed it in its own audit logs — logs that many other Microsoft 365 customers didn't have at the time.

What happened

Storm-0558 obtained a Microsoft account (MSA) consumer signing key, the kind used to sign tokens for consumer Microsoft accounts. Because of a validation issue, Exchange Online and Outlook on the web accepted tokens signed with that consumer key as valid for enterprise accounts. The attacker forged tokens and used them to read mailboxes.

The US State Department detected the activity through anomalous MailItemsAccessed events in its audit data and reported it to Microsoft. That level of mailbox auditing was then part of Microsoft's premium audit offering, which led to public criticism that customers had to pay extra to see whether their email had been read.

What Microsoft said — and corrected

In September 2023, Microsoft published the results of its technical investigation. Its leading hypothesis was that the key had been exposed in a crash dump from 2021 that was later moved to a debugging environment, which the attacker accessed after compromising an engineer's account.

In a March 2024 update to the same post, Microsoft acknowledged that it had not found a crash dump containing the impacted key material. The crash-dump explanation remained a hypothesis, not a confirmed finding. How the key was actually stolen has never been conclusively established publicly.

The Cyber Safety Review Board report

In April 2024, the US Cyber Safety Review Board published its review. It concluded that the intrusion was preventable and resulted from "a cascade of security failures" at Microsoft, criticized the company's security culture, and noted that a consumer signing key created in 2016 was still able to sign tokens that enterprise systems accepted years later. Microsoft responded by expanding its Secure Future Initiative and stating that security would take priority over new features.

Why it mattered

Identity provider keys are crown jewels. Whoever holds a signing key can impersonate anyone who trusts it. Customers can't protect a provider's keys — but they can make sure they would notice misuse.

Logging is a security control. The difference between detecting Storm-0558 and never knowing was a log category. After public pressure from the US government, Microsoft expanded the audit logging available to standard customers, including mailbox access events, and extended default retention.

Provider transparency changes over time. The revised root-cause narrative is a reminder to treat early incident explanations as provisional — and to base your own actions on what you can verify in your environment.

What to do now

1. Confirm unified audit logging is on. In Exchange Online PowerShell, Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled should return True.
2. Confirm mailbox auditing hasn't been disabled. Get-OrganizationConfig | Format-List AuditDisabled should return False.
3. Check which mailbox actions you capture. Make sure MailItemsAccessed and other high-value events are recorded for owners, delegates and admins, now that Microsoft makes more of them available by default.
4. Decide on retention. Standard audit retention may not cover a slow investigation. Microsoft Purview Audit (Premium) extends retention; alternatively, stream audit data to Microsoft Sentinel or another SIEM with at least a year of retention.
5. Practice an investigation. Ask your team: "Which mailboxes did this account access last week, from which IP addresses?" If they can't answer within an hour, fix logging and tooling now.
6. Correlate mailbox access with sign-ins. Mailbox access from IP addresses that never appear in a user's Entra ID sign-in logs is worth investigating — especially for executives.
7. Review provider contracts. Look at incident notification terms and access to security logs in your agreements with major cloud providers.

How to look for forged-token or stolen-token access

You can't detect a stolen provider key directly, but you can look for its effects:

• Mailbox access without a matching sign-in. In Microsoft Sentinel or Defender XDR, compare MailItemsAccessed events with Entra ID sign-in logs. Access from IP addresses that never appear in the user's interactive or non-interactive sign-ins, especially from hosting providers, deserves review.
• Unusual clients and user agents accessing executive mailboxes through Outlook on the web.
• Bulk access patterns, such as many items read in a short window or sync-type access from an unfamiliar source.

Expect false positives from Microsoft service infrastructure and mobile carriers. Build a watchlist of executive and high-value mailboxes and review anomalies for those first.

Common mistakes

• Assuming defaults are enough. Many tenants never reviewed which audit events they capture or how long they keep them.
• Keeping logs only in the source system. If an attacker gains admin rights, logs stored only in the tenant are at risk. Copy security logs to a separate system with restricted access.
• Never testing the investigation path. The first time a team tries to answer "who read this mailbox?" shouldn't be during a real incident.
• Taking early root-cause statements as final. As Storm-0558 showed, explanations can change. Base your response on your own evidence.

Questions for leadership

• If someone read our CEO's email last month, could we prove it — and see what was read?
• How long do we keep audit logs, and where are copies stored?
• Who reviews Microsoft's security advisories and decides whether we were affected?

Key takeaways

• Storm-0558 used a stolen signing key and a validation flaw to forge tokens into enterprise mailboxes.
• A customer detected it because it had detailed mailbox audit logs.
• Microsoft's initial crash-dump explanation was later corrected: no crash dump containing the key was found.
• The CSRB called the intrusion preventable and criticized Microsoft's security culture.
• Your defense is visibility: audit logging, retention and practiced investigation.