Storm-0558: forged Entra tokens from a stolen signing key to mailbox access

Storm-0558, a China-nexus actor, read Exchange Online and Outlook Web Access mailboxes at targeted organizations without stealing a single password. There was no phishing lure, no interactive sign-in, and no MFA prompt to approve or deny. The actor held a stolen identity-provider token-signing key and, through a token-validation gap, minted authentication tokens for targeted users outside the victim tenant. Each mailbox request presented a freshly forged token. In ATT&CK terms the core technique is T1606 Forge Web Credentials, with the forged material replayed as T1550 Use Alternate Authentication Material to carry out T1114 Email Collection.

This is distinct from a golden SAML attack, where an attacker steals an on-premises federation signing certificate and forges tokens your own IdP would issue. Here the compromised signing key sits upstream at the identity provider, and the forged token is accepted because of a gap in how the resource validates it. It is a supply-side identity-provider compromise, and it changes what detection and containment even mean.

How it works

Two things had to be true. First, an identity-provider token-signing key was stolen (T1552 Unsecured Credentials, T1528 Steal Application Access Token as the actor obtained and repurposed key and token material). Second, a token-validation gap let a token that should not have been honored for enterprise mail be accepted anyway, for example a token signed by the wrong key or minted for the wrong scope or audience.

With both in place, the actor mints tokens offline. A mail resource trusts an access token because it is signed by a key the identity provider vouches for, not because it re-checks a password or re-runs MFA. So a validly signed token with the right-looking claims is honored, and the actor reads mail directly over Exchange Web Services and Graph mail scopes. Because the tokens are minted outside the tenant, none of this produces an interactive sign-in, an MFA challenge, or a Conditional Access evaluation.

Why it matters

You cannot revoke a session you never issued. Every account-level reflex assumes a tenant-issued sign-in that never happened. Reset the password and the forged token keeps working, because it never depended on the password. Force MFA re-registration and nothing changes, because MFA is never evaluated at issue time. Revoke sessions with sign-out-everywhere and there is no session to revoke, because the tenant never created one. In a real intrusion the mailbox reads continue straight through a password reset, which is the moment responders realize they are fighting the wrong layer.

The credential here is the signing key, and it lives at the identity provider, not in your tenant.

How to detect it

Detection lives in the mailbox-access telemetry and the token claims, not in the sign-in logs. The signature is authenticated access with no authentication behind it: MailItemsAccessed and OWA read events against targeted mailboxes with no matching interactive sign-in, no MFA challenge, and no Conditional Access evaluation for those accounts.

Look at the tokens themselves. A forged token carries a signing key identifier and claims (issuer, audience, scope) that do not map to anything your tenant issued. A token signed by a consumer or wrong-scope key that is nonetheless being accepted for enterprise mail is the tell. Correlate the sign-in logs against the mailbox-audit logs for the same accounts: mail being read with no corresponding sign-in is the anomaly.

In this scenario the mailbox reads came from 198.51.100.42 against mailboxes in example.com, but the source address is not the signal. The signal is mail access with no authentication event and a token your tenant never issued.

How to contain and shut it down

Cut the forging at the source. Work with the identity provider to revoke and rotate the compromised token-signing key so no new forged tokens can be minted, and invalidate every token issued by that key so the already-minted ones stop being accepted. There is no per-session revoke to perform, because the tenant never issued these sessions. That single action at the identity-provider layer is what stops the access, and it is the move that account resets, MFA, IP blocks, and session revocation all miss.

Then close the validation gap so a token is only accepted when its issuer, audience, scope, and key provenance all match what the enterprise resource should trust. Protect the signing key so it is hard to steal and, if stolen, short-lived and rotatable through hardware isolation and a short key lifecycle. Monitor token claims for key and scope mismatches.

Scope the exposure from the mailbox and unified audit logs, not the sign-in logs, which are empty here by design. Enumerate MailItemsAccessed, folder binds, and mail read events per mailbox to determine exactly which mailboxes and messages were read. Obligations follow the mail that was actually exposed and the jurisdictions and contracts that govern it, and the absence of a sign-in does not reduce that exposure. Because the root cause is upstream, engage the identity provider on the key compromise itself.

Practice it

GraphLattice Range runs this exact chain so teams learn to spot mailbox access with no matching sign-in, read the token claims, and contain by revoking and rotating the signing key instead of resetting passwords that change nothing.