Mayakshi
Learning Centre for Cyber Security & Privacy Professionals
Amitai Cohen
8 Sept 2023
On September 6th, 2023, Microsoft published a follow-up to their initial investigative report from July 11th about Storm-0558 — a threat actor attributed to China who managed to acquire a signing key that allowed them to gain illicit access to Exchange and Outlook accounts. Microsoft’s latest report about how the signing key may have been compromised by the threat actor
On September 6th, 2023, Microsoft published a follow-up to their initial investigative report from July 11th about Storm-0558 — a threat actor attributed to China who managed to acquire a signing key that allowed them to gain illicit access to Exchange and Outlook accounts.
Newly revealed information
There is evidence that a Microsoft engineer’s corporate account was compromised by Storm-0558
This engineer had permission to access a debugging server in Microsoft’s corporate network.
This debugging server contained a crash dump that originated in a signing system located in Microsoft’s isolated production network.
This crash dump, which was the result of a crash that occurred in April 2021, contained the aforementioned MSA signing key.
The inclusion of the signing key in this crash dump was the result of a bug, and a separate bug caused the signing key to remain undetected on the debugging server.
It mean that the threat actor might have been in possession of the signing key for over two years prior to being discovered in June 2023. Furthermore, while Microsoft have reviewed their logs and definitively identified the use of forged authentication tokens for Exchange and Outlook accounts throughout May 2023, we are nevertheless led to the conclusion that the threat actor might have been forging authentication tokens for other services during this two-year period.
Immediate Actions
Organizations should scan their logs for evidence related to this activity in a time window spanning the period between April 2021 and June 2023
Organizations should use a hardware security module (HSM) for key storage whenever possible.
As a precautionary defense-in-depth measure, debugging and crash dump data should be purged on a regular basis.
Organizations should maintain an inventory of assets in which debugging and crash dump data is collected, stored, or catalogued, and ensure that access controls are in place to limit these assets’ exposure.
Sensitive production environments should be properly isolated from corporate environments.
Signing keys should be rotated on a regular basis, ideally every few weeks.
Secret scanning mechanisms — particularly those put in place to mitigate the risk of keys leaking from high-to-low trust environments — should be regularly monitored and tested for effectiveness.
SDKs should either implement critical functionality by default, or warn users if and when they’ve missed a vital implementation step that must be performed manually.