Most account takeovers on this site start with a password: sprayed, stuffed, phished or stolen by malware. Storm-0558 skipped the password and the sign-in altogether. From 15 May 2023 the group, which Microsoft tracks as China-based and espionage-focused, read the mail of about 25 organisations, including the US State and Commerce Departments, plus several hundred related personal accounts. The US Commerce Secretary's mailbox was among them, and the State Department later said about 60,000 emails were taken from ten of its accounts.
They did it with one thing: a Microsoft signing key that should never have worked for those mailboxes, and that should have been retired years earlier.
What a signing key does
When you sign in to a modern service, the identity provider doesn't send your password to every app. It gives you a token: a short piece of text that says "this is alice@example.gov, valid for the next hour, for Outlook", followed by a digital signature made with the provider's private key. Each app checks the signature against the provider's published public key and, if it matches, believes the token. The app never asks how you signed in; that question was answered when the token was signed.
So whoever holds the private signing key is the identity provider. They can write a token for any user, with any lifetime, and every app that trusts that key will accept it. MFA, conditional access and password policies all live at sign-in, and a forged token never passes through sign-in.
Step 1: a consumer key from 2016
Microsoft runs two identity systems: Microsoft accounts (MSA) for consumers (Outlook.com, Xbox) and Azure AD, now Entra ID, for organisations. Each has its own signing keys. The key Storm-0558 used was an MSA consumer key created in 2016. The Cyber Safety Review Board (CSRB) found that Microsoft had stopped rotating consumer keys by hand in 2021, had no automated alert for keys that were too old, and so a key that should have expired was still live in 2023.
Step 2: the key leaves Microsoft (nobody knows how)
In September 2023 Microsoft said the most probable route was a 2021 crash dump from the consumer signing system that kept the key by mistake, was copied to a debugging environment, and was taken from an engineer's account later compromised by the group. The CSRB found Microsoft had no evidence of that: no crash dump with the key was ever found. Microsoft corrected its post on 12 March 2024, after the board's questions. How the key was stolen is still unknown.
Step 3: a consumer key accepted for enterprise mail
A stolen consumer key should have opened consumer mailboxes and nothing else. It opened government mailboxes because of a validation error, Microsoft's words:
• In 2018 Microsoft began publishing the public keys of both systems through a common metadata endpoint, so apps that accept both kinds of account could find them in one place.
• Microsoft's libraries checked the signature but did not add the scope check automatically. The mail system moved to the common endpoint in 2022.
• An app checking a token against that list would find the consumer key there and see a valid signature.
• The missing check was who is allowed to sign for whom: an enterprise mailbox token must come from the enterprise issuer, not the consumer one. In Microsoft's words, the mail system's developers "incorrectly assumed libraries performed complete validation".
• A second flaw let the group swap a token from the GetAccessTokenForResource API for fresh ones, which kept access going.
With both, the group could write an Outlook Web Access token for any enterprise user it knew the address of, and Exchange Online served the mail.
Step 4: found by a customer with the expensive log
On 16 June 2023 analysts at the US State Department saw something odd in their Microsoft 365 audit data: MailItemsAccessed events, one entry each time a mailbox item is read, from an app ID that their own users didn't normally use. They had a rule for it, and it fired.
Most victims couldn't have seen that. MailItemsAccessed was part of Purview Audit (Premium), sold with the top E5/G5 licences. Agencies on lower tiers had no record of which messages were read. CISA's advisory in July 2023 pointed customers to this exact event, and after pressure from CISA and Congress, Microsoft made the expanded logs available to more licence levels from September 2023.
Step 5: Microsoft's fix
• 26 June: Outlook Web Access stopped accepting tokens from GetAccessTokenForResource for renewal.
• 27 June: tokens signed with the stolen key were blocked in OWA.
• 29 June: all consumer signing keys were replaced and the old ones revoked; the new keys moved into the enterprise key store with more isolation.
• 3 July: the key was blocked for the affected consumer customers too.
• Customers didn't have to change anything. That is the uncomfortable part: the fix, like the flaw, was entirely on Microsoft's side.
What the review board concluded
The CSRB's April 2024 report called the intrusion preventable and the result of "a cascade of Microsoft's avoidable errors", and said Microsoft's security culture was inadequate and needed an overhaul. It recommended that cloud providers rotate keys automatically and alert on old ones, validate token issuers and scope in every service rather than trust a shared library, and give every customer the logs needed to investigate, without a premium licence.
What a small tenant should do
You can't protect Microsoft's keys. You can make sure that if a token is forged or stolen, you see it.
1. Check which audit events you actually have. In Microsoft 365, open Purview Audit and confirm auditing is on (it usually is) and that MailItemsAccessed events appear for your mailboxes. Since the 2023 change they are included for far more licences than before; don't assume.
2. Keep the logs longer than the default. Standard audit retention is 180 days; attackers here were inside for a month before anyone noticed. Export the unified audit log weekly to storage you control, or to a cheap log store, and keep a year.
3. Write two alerts: mailbox access from an app ID or IP range your staff don't use, and a burst of MailItemsAccessed for one mailbox in a short time.
4. Know your admins and app consents. Review enterprise applications with mail permissions every quarter; forged and stolen tokens both show up as an app reading mail.
5. If you sign your own tokens (your web app issues JWTs or session tokens): rotate the signing key on a schedule, store it in a key vault or HSM, never in crash dumps or logs, and check the issuer, audience and key ID on every request, not just the signature. Keep a written procedure for "rotate now and invalidate every token".
Two related cases on this site: Midnight Blizzard's password spray into Microsoft's leadership inboxes, where OAuth apps did the reading, and session cookie theft after MFA, where the token is stolen rather than forged.
osec Auth signs your users in with email codes, Google or Apple and keeps the token handling on our side: short-lived tokens, server-side sessions you can end for everyone at once. Free, no OAuth setup on your site.
Try osec AuthSources: Microsoft Threat Intelligence: Analysis of Storm-0558 techniques for unauthorized email access (14 July 2023); MSRC: Results of major technical investigations for Storm-0558 key acquisition (6 September 2023, corrected 12 March 2024); CISA and FBI:Enhanced monitoring to detect APT activity targeting Outlook Online, AA23-193A; CISA: Cyber Safety Review Board review of the Summer 2023 Microsoft Exchange Online intrusion; TechTarget: Cyber Safety Review Board slams Microsoft security failures; The Record: DHS review board cites cascade of security failures at Microsoft; Lawfare: CSRB lashes Microsoft's cascade of security failures; The Hacker News: US cyber safety board slams Microsoft.