On July 11, Microsoft published two blog posts disclosing Storm-0558: a China-based, espionage-motivated actor that had been reading Exchange Online and Outlook.com mailboxes since at least May 15. A Federal Civilian Executive Branch agency — reported in the press as the State Department — caught the anomalous mail access in its own environment and told Microsoft on June 16. Microsoft blocked further use of the forged tokens in Outlook Web Access by June 27 and had a replacement signing key in place by June 29, roughly two weeks before anyone outside the affected organizations heard about it. Those organizations numbered around twenty-five, mostly U.S. and Western European government agencies with a foreign-policy footprint; public reporting has named the State Department and the Department of Commerce, including the mailbox of a sitting cabinet secretary.
The mechanism is the part worth sitting with, because this is not a phishing story or a password story. Storm-0558 had acquired an inactive Microsoft account (MSA) signing key — the kind meant to validate consumer sign-in tokens, nothing enterprise about it — and used a Microsoft token-issuance API, GetAccessTokenForResourceAPI, to mint tokens good enough to read mail through OWA. A design flaw let those consumer-signed tokens pass validation for enterprise mailbox access they were never supposed to reach. Nobody guessed a password, ran a phishing kit, or defeated multi-factor authentication, because none of those sat anywhere in the path. And in one of the year's better scheduling coincidences, Microsoft finished renaming Azure AD to Microsoft Entra ID on the same July 11 it disclosed all this, so half the internet spent the week updating architecture diagrams for a rebrand while the other half read straight past the new name to the incident underneath it. We will deal with the rename on its own terms another time; nothing about this story cares what the identity platform is called.
We spent the week doing what we did after HAFNIUM: reading everything Microsoft, CISA, and the FBI published, then going tenant by tenant with clients and asking two questions. Could this have happened to us. And if it had, would we know. For most of the estates we touch, the honest answer to the second question was no — not from carelessness, but because the log entry that would tell you sits behind a license tier most of them don't carry. That gap is most of what follows.
What Storm-0558 actually did, in the order we understand it
Strip away the branding and the sequence is short. Storm-0558 already held a valid MSA signing key before this campaign began; how the key left Microsoft's control is still not public, and we are not holding space on the calendar for a detailed postmortem, because keys like this rarely get one. From May 15 onward, the actor used that key to forge authentication tokens and called into OWA to read mail in roughly twenty-five tenants. The State Department noticed unusual mailbox access in its own environment and reported it on June 16. Microsoft's investigation confirmed Storm-0558 activity, cut off the abused token-renewal path through GetAccessTokenForResourceAPI by June 26, blocked outright use of tokens signed with the compromised key the next day, and had a replacement key in place by June 29. The two blog posts on July 11, and a deeper technical write-up on July 14, are the first public accounting of any of it.
None of that sequence involved a password spray, a phished MFA prompt, or a misconfigured Conditional Access policy — the categories most of our incident response muscle memory is built around. This was a break in the token-issuing chain itself, upstream of anything a tenant admin configures, monitors, or can independently audit.
Why MailItemsAccessed was the log entry that mattered — and who didn't have it
Every Exchange Online mailbox has had baseline auditing on since 2019; Microsoft leans on that fact and it's true as far as it goes. The Unified Audit Log operation that actually shows a party binding to a mailbox and reading messages — MailItemsAccessed — was never part of that baseline. It shipped under Advanced Audit, gated to Microsoft 365 E5, Office 365 E5, or an E3-plus-add-on, and today sits under what Purview calls Audit (Premium). Audit (Standard), the tier every E3 and G3 tenant gets at no extra cost, keeps ninety days of a shorter operation list and does not include it.
That distinction decided who could actually answer the question a CISO asks after a mailbox incident: which messages did the actor read, not just whether a sign-in occurred. Most tenants that spent this week checking whether they had been touched could confirm mailbox auditing was technically on and still not be able to answer the one question that mattered.
| Purview audit tier | Default retention | Includes MailItemsAccessed |
|---|---|---|
| Audit (Standard) — E3/G3 baseline | 90 days | No |
| Audit (Premium) — E5/G5 or add-on | 1 year (10 years for flagged users) | Yes |
From a CISA advisory to a Senator's letter: the paywall becomes a policy fight
The joint CISA/FBI advisory, AA23-193A, published July 12 and updated July 14, did something advisories rarely do: it named the licensing gap directly, telling organizations without Audit (Premium) to consider Purview or a third-party log pipeline because their default tooling would not have surfaced this pattern. The same week, Senator Ron Wyden's office sent a letter to CISA, the FTC, and the Department of Justice describing Microsoft's practice of gating core detection telemetry behind a premium license as negligent, and asked regulators to treat it as an accountability question rather than a routine SKU decision.
We don't have a stake in the political fight, but the operational point underneath it is one we've made in client meetings for years without anyone in Washington backing us up before now: detection logging for a mailbox platform this central should not be a premium feature. The advisory and the letter landing in the same week put real weight behind that argument, and Microsoft's public tone by midweek suggested the free-tier expansion clients have wanted for years might finally be coming. We will believe it once MailItemsAccessed shows up in an E3 tenant's compliance center rather than in a press cycle. That it took a nation-state incident and a Senator's letter to get even this far should bother every IT leader who has ever been told a security control was available at the next tier up.
What we checked in every client tenant this week
None of our clients were on Microsoft's notification list. That is reassuring for exactly one incident and tells us nothing about the next one, so we ran the same short list everywhere this week, regardless of license tier:
- Confirmed Purview audit logging is actually enabled tenant-wide rather than assumed —
Get-OrganizationConfighas answered "no" for us before, usually after a tenant-to-tenant move nobody re-verified afterward. - Pulled ninety days of
MailItemsAccessedanywhere we had Audit (Premium); pulled sign-in logs and mailbox permission changes as the closest available proxy anywhere we didn't. - Reviewed Conditional Access policies for anything that treats a valid token as sufficient on its own, without device compliance or location as a second signal, since a forged token by definition still clears a downstream MFA claim check.
- Checked delegated and application permissions against mailboxes with
Get-MailboxPermissionandGet-ManagementRoleAssignmentfor anything broader than the job requires. Over-scoped application permissions are how one compromised credential, token or otherwise, turns into a mailbox-wide problem instead of a one-account problem.
Connect-ExchangeOnline
# Confirm org-wide audit logging is actually on, not assumed
Get-OrganizationConfig | Select-Object Name, AuditDisabled
# Pull mailbox-access events for a user over the last 90 days
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) `
-EndDate (Get-Date) `
-RecordType ExchangeItem `
-Operations MailItemsAccessed `
-UserIds user@example.com `
-ResultSize 5000
For the state agency client we have supported since a 15,000-mailbox move to Microsoft 365, this was a short conversation — they are on G5, and the logging was already in place. For a mid-market client still on E3 because nobody had revisited licensing since their own migration finished, the honest answer was that Audit (Premium), or an equivalent third-party log pipeline, is no longer optional, regardless of what Microsoft ships for free next quarter.
Trusting the platform is not, on its own, a control
The uncomfortable lesson here isn't about one compromised key. Microsoft will rotate keys, harden the validation path, and move on, the way it always does. The lesson is that a meaningful slice of the trust boundary in every Microsoft 365 tenant sits inside infrastructure none of us operate, patch, or audit — and that was always true; Storm-0558 just made it visible. The right response is not blanket distrust of the platform. We still put Microsoft 365 and Entra ID ahead of the alternatives we have operated over the years, and that isn't changing because of one bad month. The right response is to stop treating "Microsoft handles that" as equivalent to "that is handled."
In practice, that means layering controls that don't assume the token layer is infallible: Conditional Access that weighs device compliance and location alongside authentication, mailbox audit logging that gets reviewed rather than merely configured, admin and application permissions kept as narrow as the job allows, and a documented answer — worked out before the next incident, not during it — to which log would show this and whether we actually have access to it. If the answer is "that log exists at a tier we don't own," that is a finding, not a shrug.
We are not rewriting client architectures over one bad month. We are correcting what several clients assumed their existing tooling already covered, and in at least two tenants this week, having a licensing conversation that has nothing to do with new features and everything to do with the gap this incident exposed.
If you're facing this
If you cannot tell us right now whether your tenant retains MailItemsAccessed, and for how long, that is the first gap worth closing — before the next incident makes the question urgent instead of hypothetical. We help Microsoft-centric estates work out what their current licensing actually covers, where the detection blind spots sit, and what a defensible answer looks like when a board or a regulator asks. Get in touch if you would like a second set of eyes on your tenant's audit posture before someone else finds the gap first.