Microsoft IDs Security Gaps that Let Threat Actors Steal Signing Key

Several security missteps on Microsoft's part allowed a China-based threat actor to forge authentication tokens and access user email from some 25 Microsoft enterprise customers earlier this year, the company's investigation has shown.

The attacks by a Chinese cyber espionage group that Microsoft is tracking as Storm-0558 were noteworthy because they involved the threat actor using a Microsoft account (MSA) consumer signing key to forge Azure AD tokens for accessing enterprise email accounts. MSA consumer keys are typically used to cryptographically sign into a Microsoft consumer application or service such as Outlook.com, OneDrive, and Xbox Live.

Cyber Espionage Campaign

Storm-0558 is believed to be a China-nexus cyber espionage group that has been active since at least 2021. Its targets have included US and European diplomatic entities, legislative governing bodies, media companies, Internet service providers, and telecommunications equipment manufacturers. In many of its attacks, the threat actor has used credential harvesting, phishing campaigns, and OAuth token attacks to gain access to target email accounts.

Microsoft discovered the group's latest campaign in May when a customer reported anomalous activity involving their Exchange Server account. The company's initial investigation showed the threat group had accessed the customer's Exchange online data via Outlook Web Access. Early on, Microsoft assumed the adversary had somehow obtained an Azure AD enterprise signing key and was using it to forge tokens for authenticating to Exchange Server. But further investigation showed that Storn-0558 in fact was using an acquired MSA consumer signing key to do the token forging — something the company attributed at the time to a "validation error."

In a report this week, Microsoft released the findings of its subsequent two-and-a-half-month long technical investigation into the incident, which describes exactly how the attack chain played out and the now-corrected mistakes that enabled the whole thing.

A Series of Unfortunate Errors

According to the company, the problem started with a now-resolved race condition that resulted in the signing key being present in a crash dump.

Typically, the signing key should never have escaped the company's otherwise secure production environment, which is isolated and incorporates several security controls. These include background checks for employees, dedicated production accounts, secure workstations, and hardware token-based two-factor authentication. "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," Microsoft said in its report this week.

Those controls, however, were not enough when a consumer key-signing system in the production environment crashed in April 2021 and a signing key was included in either the crash dump or a snapshot of the crashed system. Normally, the key should have been redacted from the dump, but that didn't happen because of the race condition. Worse, none of Microsoft's controls detected the sensitive information in the crash dump, which eventually ended up with the debugging team on Microsoft's Internet-connected corporate network. Here again, the company's controls for spotting credential data in the debugging environment failed to spot the leaked consumer key.

As Microsoft explained it, while the company's corporate environment is secure, it also allows for the use of email, conferencing, and other collaboration tools that make users somewhat more vulnerable to spear-phishing attacks, token-stealing malware, and other attack vectors.

At some point, Storm-0558 actors managed to successfully compromise a Microsoft engineer's corporate account and used the account's access to the debugging environment to steal data — including the runaway key — from there.

The Consumer Key Mystery Explained

As to how a consumer key allowed the attacker to forge Azure AD tokens, Microsoft points to a common key metadata publishing endpoint it established 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," Microsoft said.

But here again — and for a variety of reasons having to do with ambiguous documentation and library updates, APIs, and other factors — the key scope validation did not work as intended. The net result was the "email system would accept a request for enterprise email using a security token signed with the consumer key," Microsoft said.

To address the problem, Microsoft has eliminated the race condition that allowed the key data to be included in crash dumps. The company has also upped its mechanisms for detecting signing keys in places where they should not be, including in the debugging environment. In addition, Microsoft said it has improved its automated scope validation mechanism to eliminate the potential for a similar mishap.