Results of Major Technical Investigations for Storm-0558 Key Acquisition

MSRC

/ By MSRC / September 06, 2023 / 5 min read

March 12, 2024 update

As part of our continued commitment to transparency and trust outlined in Microsoft’s Secure Future Initiative, we are providing further information as it relates to our ongoing investigation. This new information does not change the customer guidance we previously shared, nor have our ongoing investigations revealed additional impact to Microsoft or our customers. No additional customer action is required.

On July 11, 2023, Microsoft published the results of our preliminary investigation into activity by the threat actor group Storm-0558, a threat actor operating from China. On September 6, 2023, we announced that major technical investigations were complete.

However, we continued to research the threat actor’s tactics and techniques to help ensure customers were protected from similar attacks. Today we are providing this addendum to clarify and ensure the accuracy of our content based on our latest knowledge.

First, what hasn’t changed:

Our leading hypothesis remains that operational errors resulted in key material leaving the secure token signing environment that was subsequently accessed in a debugging environment via a compromised engineering account.

There is no change in the customer or Microsoft impact or actor activity. Current information may still be found in our Microsoft Security Blog.

Here are the key items which we are updating based on what we have learned since September 6, 2023:

The blog below states that the actor access may have resulted from a crash dump in 2021, but we have not found a crash dump containing the impacted key material.

The race condition mentioned in the blog below did not impact whether the key could be present in the crash dump, but rather whether the crash dump could be removed from the secure token signing environment.

We indicated moving crash dump material out of the secure signing environment was consistent with standard debugging process – we intended to indicate that this was not prohibited in the past, and thus could have happened. Our standard debugging process at Microsoft prohibits removing such materials from the production environment today.

Our ongoing investigations have revealed limitations in cred scanning technologies which we will address as we discover them.

Our investigations are ongoing, and we will continue to provide updates if relevant to our customers or the industry to help protect others from similar attacks.

On July 11, 2023, Microsoft published a blog post which details how the China-Based threat actor, Storm-0558, used an acquired Microsoft account (MSA) consumer key to forge tokens to access OWA and Outlook.com. Upon identifying that the threat actor had acquired the consumer key, Microsoft performed a comprehensive technical investigation into the acquisition of the Microsoft account consumer signing key, including how it was used to access enterprise email. Our technical investigation has concluded. As part of our commitment to transparency and trust, we are releasing our investigation findings.

Key acquisition

Microsoft maintains a highly isolated and restricted production environment. Controls for Microsoft employee access to production infrastructure include background checks, dedicated accounts, secure access workstations, and multi-factor authentication using hardware token devices. Controls in this environment also prevent the use of email, conferencing, web research and other collaboration tools which can lead to common account compromise vectors such as malware infections or phishing, as well as restricting access to systems and data using Just in Time and Just Enough Access policies.

Our corporate environment, which also requires secure authentication and secure devices, allows for email, conferencing, web research and other collaboration tools. While these tools are important, they also make users vulnerable to spear phishing, token stealing malware, and other account compromise vectors. For this reason - by policy and as part of our Zero-Trust and “assume breach” mindset - key material should not leave our production environment.

Our investigation found that a consumer signing system crash in April of 2021 resulted in a snapshot of the crashed process (“crash dump”). The crash dumps, which redact sensitive information, should not include the signing key. In this case, a race condition allowed the key to be present in the crash dump (this issue has been corrected). The key material’s presence in the crash dump was not detected by our systems (this issue has been corrected).

We found that this crash dump, believed at the time not to contain key material, was subsequently moved from the isolated production network into our debugging environment on the internet connected corporate network. This is consistent with our standard debugging processes. Our credential scanning methods did not detect its presence (this issue has been corrected).

After April 2021, when the key was leaked to the corporate environment in the crash dump, the Storm-0558 actor was able to successfully compromise a Microsoft engineer’s corporate account. This account had access to the debugging environment containing the crash dump which incorrectly contained the key. Due to log retention policies, we don’t have logs with specific evidence of this exfiltration by this actor, but this was the most probable mechanism by which the actor acquired the key.

Why a consumer key was able to access enterprise mail

To meet growing customer demand to support applications which work with both consumer and enterprise applications, Microsoft introduced a common key metadata publishing endpoint in September 2018. As part of this converged offering, Microsoft updated documentation to clarify the requirements for key scope validation – which key to use for enterprise accounts, and which to use for consumer accounts.

As part of a pre-existing library of documentation and helper APIs, Microsoft provided an API to help validate the signatures cryptographically but did not update these libraries to perform this scope validation automatically (this issue has been corrected). The mail systems were updated to use the common metadata endpoint in 2022. Developers in the mail system incorrectly assumed libraries performed complete validation and did not add the required issuer/scope validation. Thus, the mail system would accept a request for enterprise email using a security token signed with the consumer key (this issue has been corrected using the updated libraries).