Tenant admins can act now on the CSRB report about Storm-0558

Whenever a major cloud security incident hits the headlines, the tenant reviews that follow tend to look the same. People are unsure what it means for them, there are plenty of open questions, and visibility is often missing exactly where it would help most. The CSRB report on Storm-0558, released in early April 2024, takes a hard look at Microsoft's security culture. It covers technical gaps, but it also goes after communication and shared responsibility. Among admins, the Storm-0558 breach (summer 2023, forged tokens and access to Exchange Online mailboxes via a stolen Microsoft account signing key) was already well known. The Cyber Safety Review Board's public criticism has now reopened the discussion about what tenant admins can and should do in practice.

The CSRB report on Storm-0558 matters for every tenant admin

Storm-0558 is the name for a China-based threat actor that stole an MSA signing key in 2023 and used it to forge tokens for Exchange Online mailboxes. Around 25 organizations were affected, government agencies among them. The technical side was impressive, but the bigger problem was how long certain details stayed out of view. Most admins, for example, had no idea that an MSA key could sign tokens that Entra ID (then Azure AD) would trust. Microsoft's own technical blog post and its investigation results explain the techniques in depth. The CSRB report goes a step further and criticises Microsoft for slow disclosure and a lack of proactive communication. For tenant admins it comes down to two things: how would you know whether your tenant was affected, and how do you prepare better for next time?

Audit logs like MailItemsAccessed now decide how well you can respond

The biggest technical lesson from Storm-0558, in my view, is that audit logs make or break incident response. Afterwards, Microsoft expanded audit logging as part of the Secure Future Initiative. The "MailItemsAccessed" audit event, which is the one that really counts here, is now part of Audit (Standard) and no longer reserved for Purview Audit (Premium). So every admin can now see which mailboxes were accessed and when, something many of us badly missed in 2023. I wrote about this in more detail in Purview Audit MailItemsAccessed and better mailbox forensics.

In real tenants I still find plenty of admins who aren't sure which logs exist, how long they're retained or where to look for them. Trying to figure that out in the middle of an incident rarely ends well. As a minimum, you should know where your audit logs land (Purview, Entra ID, Azure) and what the default retention is (usually 90 days). You should also know whether you need Purview Audit (Premium) or Log Analytics for longer-running scenarios, and how you protect the logs against tampering. If you don't, you may find gaps at the exact moment you need visibility.

# Example: Query recent MailItemsAccessed activity for a specific mailbox
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) -Operations MailItemsAccessed -UserIds "[email protected]"

My practical tip: Put a monthly slot in your calendar to spot-check the audit logs. Look for unusual access and confirm that you actually see important events like MailItemsAccessed. A boring routine helps far more than heroics during a breach.

OAuth apps and token usage remain a weak spot in many tenants

Storm-0558 showed how dangerous access tokens can be in Microsoft clouds. A stolen signing key is an extreme case, but token abuse in general is an everyday risk. In many tenants I look at, OAuth apps and the permissions granted to them are a blind spot. With more third-party integrations and homegrown scripts piling up, it's easy to lose track. Incidents like Midnight Blizzard show why you need to review consented apps and their permissions (what Midnight Blizzard teaches us about OAuth apps and test tenants).

The Entra portal gives you a decent overview under "Enterprise applications", but you'll often need automation (Graph API or KQL) to keep up. Review critical or broadly permissioned apps regularly, and restrict user consent policies as far as you can. I've come across too many tenants where excessive permissions or forgotten apps gave attackers an easy way in.

Shared responsibility means you verify without panicking

One point the CSRB report on Storm-0558 makes is that cloud services shouldn't be a black box. Microsoft carries a huge responsibility as the provider, yet tenant admins and security teams are still the ones doing the monitoring, detection and incident response. Shared responsibility is more than a buzzword. In practice it means you know your logs, your controls and your escalation paths. If the provider gets something wrong, you can't simply sit and wait for guidance. Panic and blanket distrust don't help either, though. The tools exist, but somebody has to use them, and not everything can be automated away.

No single fix exists, but admins have plenty of practical levers

Storm-0558 and the CSRB report make it obvious that security isn't a box you tick once. Microsoft's Secure Future Initiative is progress, but actual resilience depends on tenant admins owning what's within their reach: audit logging, OAuth app governance, clean permissions and a healthy dose of skepticism. In customer projects I keep seeing this mindset decide whether an incident stays manageable or turns into a full crisis. If you know which levers you can pull, you'll be ready when the next alert comes in, and it will come.

It helps to picture how a Storm-0558-style attack can (and should) show up when the right monitoring and logs are in place. Here's a simple flow:

flowchart TD
    KeyTheft["Signing key stolen"] --> TokenForge["Token forged"]
    TokenForge --> MailAccess["Mail access via API"]
    MailAccess --> AuditLog["MailItemsAccessed in audit log"]
    AuditLog --> Detection["Detection via monitoring"]

Figure: Tracing a Storm-0558-like attack through the audit logs.