Earlier this month, Microsoft and CISA disclosed a security incident and attributed it to the Chinese threat group Storm-0558. The threat actors stole a Microsoft consumer signing key, which was initially thought to have provided them with access to Exchange Online and Outlook.com.
However, it seems like the incident has a broader scope than what was originally assumed.
New Details: More Apps Affected
The only programs known to have been impacted by the token forging technique, according to Microsoft, were Outlook.com and Exchange Online. However, Wiz Research has discovered that the compromised signing key was more potent than it first appeared and was not restricted to just those two services. Their security researchers concluded that the compromised MSA key could have allowed the threat actor to forge access tokens for multiple types of Azure Active Directory applications.
This includes managed Microsoft applications, such as Outlook, SharePoint, OneDrive, and Teams, as well as customers’ applications that support Microsoft Account authentication, including those who allow the ‘Login with Microsoft’ functionality, and multi-tenant applications in certain conditions.
Shir Tamari, Wiz Security Researcher (Source)
Everything in the world of Microsoft leverages Azure Active Directory auth tokens for access… An attacker with an AAD signing key is the most powerful attacker you can imagine because they can access almost any app – as any user. This is the ultimate cyber intelligence’ shape shifter’ superpower.
Ami Luttwak, Wiz CTO and Cofounder to BleepingComputer (Source)
Compromised Microsoft Signing Key Impact (Source)
Furthermore, the researchers also found that customers may find it challenging to detect the use of forged tokens against their applications due to a lack of logs on key fields related to the token verification process, even though Microsoft mitigated this risk by revocation of the impacted encryption key and publication of attacker IOCs.
Microsoft said last week that Storm-0558 used the token forging method to harvest unclassified data from victim mailboxes, but the precise details of the cyber espionage campaign are still unknown.
Internal investigations are still undergoing as to how the threat actor managed to acquire the MSA consumer signing key. But it’s unclear if the key function as a master key of sorts to unlock access to data belonging to nearly two dozen organizations. Some of the gaps are filled by Wiz’s research, which reveals that “all Azure personal account v2.0 applications depend on a list of 8 public keys, and all Azure multi-tenant v2.0 applications with Microsoft account enabled depend on a list of 7 public keys.”
How Users of Each Application Type Were Affected (Source)
Microsoft revoked all active MSA signing keys in response to the security intrusion to make sure that the threat actors couldn’t obtain any additional compromised keys. This precaution prevented any efforts to produce new access tokens.
Are Azure Users Still at Risk?
After invalidating the stolen signing key, Microsoft found no further evidence suggesting additional unauthorized access to its customers’ accounts using the same token-forging technique. However, the threat actor could have leveraged its access to establish persistence during previously established sessions with customer applications, prior to the revocation.
This might have happened via creating backdoors or issuing application-specific access keys using the application permissions that were gained.
Applications that kept copies of the AAD public keys after Microsoft revoked its certificate may also be at risk. Applications that trust the compromised key and depend on local certificate stores or cached keys are still vulnerable to token forging. These programs absolutely must update the trustworthy certificate list right away. Microsoft suggests at least once every day for the local stores and certificates to be refreshed.
How to Detect the Compromised Key in Your Environment?
According to Wiz Researchers, the only way for cloud users to determine whether their apps or users were targeted by the key is to look through the application-specific logs for potentially impacted AAD apps.
Therefore, application owners who want to protect their systems will have to check whether a forged token has been used or not against their applications. Wiz also reported that to their best knowledge, the only affected applications were those that utilized Microsoft v2.0 access token verification using the endpoints:
- https://login.microsoftonline.com/common/discovery/v2.0/keyscommon
- https://login.microsoftonline.com/consumers/discovery/v2.0/keys
For more information on detection, you can check out Wiz’s report here. Currently, the full extent of the incident is hard to determine, as there were millions of applications that were potentially vulnerable, both Microsoft apps and customer apps.
We will keep you updated as more information is available, but we suggest you also check out Microsoft’s Threat Intelligence blog for new information.
If you liked this article, follow us on LinkedIn, Twitter, Facebook, Youtube, and Instagram for more cybersecurity news and topics.