Wiz Research’s review of Microsoft’s September 2023 Storm-0558 update points to a compound failure: a highly sensitive MSA signing key was exposed through crash dump handling, remained valid long after its stated expiry and was then usable because Exchange accepted tokens under flawed issuer validation logic.
The central governance lesson is key rotation. Wiz notes the signing key was issued in April 2016, expired in April 2021, but remained valid until Microsoft rotated it in July 2023, leaving it effectively usable for more than seven years. Given Microsoft’s own assessment that compromise may have occurred sometime after April 2021, the long-lived key materially increased blast radius because defenders could not know when theft occurred. Combined with limited log retention, this created a long period of uncertainty in which forged tokens may have been possible across more than Exchange and Outlook. The incident shows that “keys to the kingdom” controls fail when secret hygiene, environment isolation, validation defaults and rotation governance are weak at the same time.
| What’s happening | Cause | Action |
|---|---|---|
| A key-to-the-kingdom signing credential stayed usable for years after likely compromise | Wiz cites Microsoft’s timeline showing the MSA signing key was issued in April 2016, expired in April 2021 and was not rotated until July 2023. Microsoft also concluded the key may have been acquired sometime after April 2021. This means the organisation could not bound exposure because the key remained trusted long after the earliest suspected compromise window. | Validate rotation frequency, effective retirement and trust removal for high-impact signing keys, especially identity and token-signing material. SkySiege checks for key rotation across all cloud resources that can be considered keys, whilst the ownership is still up to the organisation, knowing what is effectively permanent access is key to visibility and remediation. |
| Sensitive key material was exposed through crash dump handling across trust boundaries | Microsoft’s reported sequence shows a production-origin crash dump landed on a debugging server in the corporate environment and contained the MSA signing key because of a bug. A second bug left the key undetected on that server. This is a data hygiene and isolation failure, not just a single host compromise. | Validate whether crash dumps, debug artefacts, memory captures and support bundles can contain secrets; ensure purge schedules, storage inventories and access restrictions exist. SkySiege as a cloud platform does not scan logs but would expect and check any access logs for unusual usage of that key. However, when systems using signed keys like this operate they should be treated with the same security level and risk factor as the key itself, as they do effectively have access to the key in memory and in output. |
| A compromised corporate account had a path to highly sensitive diagnostic data | Microsoft reported that a corporate engineer account was compromised using an access token from a malware-infected machine and that account had permission to access the debugging server. Once that path existed, the attacker could exfiltrate the dump containing key material. | Validate access paths from user-controlled corporate identities into diagnostic or privileged support systems and reduce standing access. SkySiege detects cross environment labelling and whether tagging is in place to build an access map. In this regard and with proper classification unprivileged developer access to a production environment would be flagged. |
| Incorrect token issuer validation made the stolen key operationally useful against enterprise services | Wiz notes Microsoft confirmed the Azure AD SDK did not properly validate issuer ID by default and the Exchange team incorrectly assumed it did. That design gap led Exchange to accept Azure AD tokens signed by an MSA key. | Validate that applications enforce issuer, audience, signing key type and trust-boundary checks explicitly rather than assuming SDK defaults are safe. |
| Detection and scoping were weakened by incomplete historical visibility | Wiz states Microsoft could only partially account for attacker activity between April 2021 and May 2023 because of log retention limits and Microsoft did not publish new technical indicators from corporate-network activity. This left open whether other services were abused. | Validate log retention for identity, token use, admin activity and sensitive data access over periods aligned to stealthy compromise scenarios. Logs are fine however in time visibility is the key to controlling the environment, hence why SkySiege is not a log parser but a realtime environment analysis. |
| Secret leakage controls failed to detect crown-jewel material in a lower-trust environment | Wiz attributes the presence and persistence of the key on the debugging server to one bug that included the key in the dump and another that failed to detect it afterward. This indicates secret scanning and control validation were not effective for a high-consequence path. | Validate that secret scanning mechanisms are tested against real key material patterns and monitored for failure, especially on data moved from production into engineering or support systems. Keys usually follow a strict format that can be controlled for using regex expression detection. |
The main lesson is not only that a signing key was stolen, but that Microsoft’s control environment allowed the compromise to remain strategically valuable for far too long. For high-trust credentials, rotation is one of the few controls that reduces blast radius even when compromise goes undetected. Wiz’s timeline makes that point clear: if the key may have been exposed shortly after April 2021 but remained valid until July 2023, the lack of timely rotation preserved attacker utility for roughly two additional years. That is a governance failure as much as a technical one.
This also highlights a detection gap that many enterprises share. If defenders do not know when a key was compromised and do not retain enough logs to reconstruct token abuse over long periods, they cannot confidently scope impact. That uncertainty directly affects incident cost, disclosure quality, regulatory posture and customer trust.
Architecturally, the incident shows how crown-jewel secrets can be lost without direct production compromise. Moving diagnostic data from isolated production systems into corporate-accessible environments created an indirect path to the same outcome. When that is paired with excessive access, weak secret hygiene and insecure validation defaults, a single credential theft can become a broad identity-trust failure.
For enterprise risk, this is the core takeaway: long-lived signing keys, especially those anchoring authentication across multiple services, create disproportionate financial, operational and reputational exposure when rotation discipline is weak.
