[German]A suspected China-based hacking group, dubbed Storm-0558 by Microsoft, was able to gain access to email accounts of about 25 organizations in the Microsoft cloud. In a follow-up late last week, Microsoft followed up with a "comprehensive" text with some limited information about what happened. In a nutshell, Microsoft probably succeeded in stopping the attack (discovered and reported by customers by accident) after weeks. But it is still unclear how the attackers got hold of an abused Microsoft Account (MSA) customer key, and (now corrected) bugs in the Azure code probably enabled the abuse of the MSA key.
Advertising
Review: Hack of Outlook cloud accounts
In mid-June 2023, Microsoft was notified by customers from the U.S. Department of State that unauthorized third parties had been gaining access from certain employee email accounts since mid-May 2023. The whole thing was an accidental discovery by the customer, who had noticed unusual access to mailboxes in their monitoring. Microsoft's investigation then revealed that a (suspected Chinese) hacker group called Storm-0558 had managed to penetrate the mailboxes in question.
Microsoft had published the first post Microsoft mitigates China-based threat actor Storm-0558 targeting of customer email on July 11, 2023, admitting to the hack. It said there that it had mitigated an attack by a China-based threat actor (Storm-0558) on customer email. The Storm-0558 group primarily targets government agencies in Western Europe, according to Microsoft, and focuses on espionage, data theft and credential access.
I had picked up on the story in the blog post China hacker (Storm-0558) accessed Outlook accounts in Microsoft's cloud and explained that the incidend thing was more explosive than the portrayal in Microsoft's soft-pedaled post suggests. For example, it is clear that the attackers used forged authentication tokens to access users' emails. They were able to generate the required Azure AD authentication tokens via an internal Microsoft consumer account signature key (MSA).
The abbreviation MSA stands for Microsoft Account. The term is used for the single sign-on service on the Internet operated by Microsoft. MSA is managed on Microsoft servers in the cloud and the Microsoft Account login can then be used for many websites and services. The last sentence above basically says: logging into a "private" Microsoft account intended for consumers allowed to create authentication tokens that could also be used to access Microsoft Azure AD (more recently called Microsoft EntraID).
Microsoft wrote that they quickly stopped the use of the authentication tokens and later revoked the MSA key. But the attackers had access to the mailboxes of around 25 organizations for many weeks. Of course, the question immediately arose: how did the Storm-0558 attackers get their hands on this private Microsoft account signature key (MSA)? And why can this consumer MSA key be used to forge Azure AD tokens? Microsoft avoided admitting in its post that these are bugs and an exploited 0-day.
Microsoft's second report – much remains unclear
Last Friday, July 14, 2023, Microsoft then published a second report Analysis of Storm-0558 techniques for unauthorized email access about this incident. There, the incident was confirmed again and it is said that the affected customers were notified directly. In addition, the accesses of the Storm-0558 group had been prevented and the infrastructure had been hardened.
Advertising
Microsoft is monitoring "the situation" and wants to take further steps to protect customers. It is an extensive report with a lot of text, which virtually bludgeons the reader with a lot of irrelevancies. More interesting, however, is the following information found in the text.
Unclear how hackers got the MSA key
In the first and second articles, Microsoft confirms that the Storm-0558 group used a so-called MSA Consumer Signing Key to forge authentication tokens for Azure AD Enterprise and MSA Consumer to access OWA and Outlook.com. Regarding this, the text states:
Storm-0558 acquired an inactive MSA consumer signing key and used it to forge authentication tokens for Azure AD enterprise and MSA consumer to access OWA and Outlook.com.
[…]
The method by which the actor acquired the key is a matter of ongoing investigation.
In the excerpted sentences, Microsoft admits that it has no idea yet how the attackers were able to access and steal the MSA signing key that exists internally at Microsoft. In the text, Microsoft writes, "The method by which the actor acquired the key is the subject of ongoing investigation."
The key was "inactive," meaning "not in use," it continues. The only action Microsoft could take was to lock the tokens and invalidate all MSA keys that were active before the incident (this includes the MSA signing key used by Storm-558).
Bug in the validation
In the above text another problem becomes obvious. Why is it possible to generate authentication tokens for MSA Consumer and also for Azure AD Enterprise with an inactive MSA signing key for Consumer in order to gain access to OWA and Outlook.com? The original text from Microsoft only says:
Though the key was intended only for MSA accounts, a validation issue allowed this key to be trusted for signing Azure AD tokens.
Although the key was only intended for MSA accounts, it could be used to sign Azure AD tokens due to a validation issue. Or in plain language: A bug in the validation code led to the acceptance of authentication tokens that were actually invalid. The issue has been corrected, Microsoft writes. But the incident throws a special spotlight on the matter.
Microsoft's report reads as if the company did everything it could to stop the attack (true, but when Storm-558 realized the tokens were locked, they realized the vector was burned and scaled back activity, in my eyes). Since the ways the attackers got the MSA key are unknown, it would be theoretically possible for the group to use the approach again.
To this end, however, Microsoft notes that the internal hardening and isolation measures would have worked the mechanisms for access via unauthorized authentication token. Since Microsoft invalidated the MSA signing key acquired by the actor, no key-related activity by the actor has been observed. In addition, Storm-0558 was seen to have moved on to other techniques, which, according to Microsoft, indicates that the actor is not able to use or access signing keys.
Many words but little plain text
In the report, Microsoft explains in detail what the attacker was able to do with the hijacked accounts and what was done to harden them after the discovery. However, what Microsoft avoids at all costs in its reports is writing about a 0-day vulnerability in the code for validating the tokens.
Security researcher Kevin Beaumont already wrote on the occasion of the first Microsoft report that it looks to him as if Redmond had made a gross mistake. In the following discussion on Mastodon between Beaumont and Dan Goodin (responsible for security topics at ArsTechnica), it is about Microsoft beating around the bush as soon as it comes to its role in its own cloud service.
The vulnerabilities in the cloud
The above facts and discussion cast a shadow on the question "how secure is the (Microsoft) cloud?". After all, it is often argued that migrating to the cloud automatically increases security – because the cloud provider takes care of securing it. At the end of the day, however, cloud users have only bought a "black box" and can only hope that it does not contain too many errors and vulnerabilities.
While updates are distributed for on-premises solutions and any vulnerabilities are not only fixed but also made public, the software used in the cloud often remains a black box. Outsiders do not find out whether and when vulnerabilities in the cloud solution have been patched. According to Kevin Beaumont, Microsoft does not provide a CVE identifier for vulnerabilities found in the cloud. Only when a security incident becomes public does the cloud provider feel compelled to disclose some information.
In this context, I also came across the above tweet from the crowstrike blog over the weekend, which discloses another problem in the post Adversaries Can "Log In with Microsoft" through the nOAuth Azure Active Directory Vulnerability. Attackers could use the nOAuth vulnerability to log into Microsoft's Azure Active Directory in the cloud, they say. The post comes on the heels of one published by Descope on June 20, 2023, describing how a combination of a vulnerability in Azure Active Directory and poorly integrated third-party applications ("nOAuth" it calls them) – could enable a full takeover of cloud accounts. nOAuth is the latest in a multitude of vulnerabilities and architectural weaknesses in Microsoft software and systems such as Active Directory that can be exploited and put organizations at risk, it says.
Similar articles:
Azure Hack? Strange Azure AD IP 20.119.0.42:443 "safe-hse.com" alerted on June 13, 2023
Advertising
