Storm-0588 Azure AD Token Forging Attack

Key Takeaways

• Azure Active Directory (AAD) Compromise: The incident involves the compromise of OpenID signing keys within the Azure AD environment, indicating a significant security threat to Microsoft’s authentication process.
• Advanced Persistent Threat (APT) Group: The attack was carried out by a China-based threat actor, Storm-0558, with espionage objectives targeting government agencies and organizations linked to geopolitical interests.
• Limited Impact on Large Organizations: While media reports sensationalized the event as a “Microsoft 365 service compromise,” the analysis suggests that large organizations might have been less affected due to the APT group’s more selective targeting.
• The Significance of Compromised OpenID Keys: The compromised OpenID signing keys play a crucial role in the authentication process within AAD. Unauthorized access, token forgery, and security breaches are possible consequences, affecting different types of applications.

Recommendations

• Regular Key Rotation: Implement a strict key rotation policy for OpenID signing keys within Azure Active Directory (AAD) to mitigate the risk of compromise and enhance the overall security of the authentication process.
• APT-Specific Monitoring: Employ advanced threat monitoring and detection mechanisms to identify and respond promptly to potential APT group activities. Focus on monitoring government agencies and organizations with geopolitical interests to enhance early detection.
• Strengthen Application Security: Enhance security measures for all applications connected to Azure AD by adopting multi-factor authentication, role-based access controls, and continuous monitoring to minimize the impact of compromised OpenID keys.
• Conduct Security Assessments: Conduct regular security assessments and audits of your Azure AD environment to identify potential vulnerabilities and ensure that the necessary security controls are in place to prevent unauthorized access, token forgery, and security breaches.

Introduction

Our Threat Intelligence team is closely monitoring the recent compromise of OpenID signing keys within the Azure Active Directory (AAD) environment, identifying this event as an evolution of the JWT key forging attack. The attack leverages a potentially leaked key used to support OAuth handling in Microsoft Online.

While the media reports have escalated the situation to the scale of a ‘Microsoft 365 service compromise,’ our analysis suggests a more nuanced understanding of the phenomenon. The impact on large organizations and corporations appears to be limited due to the different targeting that is typical of APT (Advanced Persistent Threat) groups. Such groups may focus their efforts more selectively, and the broad generalizations made in some reports might not accurately reflect the risks to all entities.

In the context of this new development in the threat landscape, the significance of a compromised OpenID signing key cannot be understated. These keys play a crucial role in the authentication process within AAD, and a compromised key can lead to unauthorized access, token forgery, and various security breaches across different application types.

It should be remembered that the number of organisations attacked is limited to a dozen or so – mainly government agencies in the US/Europe and Taiwan, and they were directly informed by Microsoft that they were being targeted.

Technical Details

Storm-0558 is a China-based threat actor with espionage objectives, primarily targeting government agencies, related consumer accounts, and organizations connected to various geopolitical interests. The campaign began on May 15, 2023, with malicious activities focused on email access through forged authentication tokens. Approximately 25 organizations were impacted, including U.S. and European governing bodies and individuals linked to Taiwan and Uyghur interests. Microsoft successfully identified and blocked the campaign, coordinating with multiple government entities and notifying impacted customers. Further information on the nature and history of Storm-0558, working patterns, and objectives is detailed below.

Storm-0558 has targeted media companies, think tanks, and telecommunications equipment and service providers. Methods include exploiting vulnerabilities in public-facing applications, deploying malware like China Chopper, using shared tools like Cigril, and engaging in sophisticated credential theft.

In the middle of June 2023, a particular FCEB (Federal Civilian Executive Branch ) agency noticed events labeled as MailItemsAccessed within the M365 Audit Logs, exhibiting an unfamiliar ClientAppID and AppID. These events are typically generated when licensed users engage with items in Exchange Online mailboxes via any client or connectivity protocol. This activity was deemed suspicious by the FCEB agency since the observed AppId was not commonly associated with mailbox access within their systems. The incident was promptly reported to both Microsoft and CISA.

Upon investigation, Microsoft discovered that actors affiliated with an Advanced Persistent Threat (APT) had accessed and removed unclassified data from Outlook within Exchange Online. Only a small number of accounts were affected. The APT culprits utilized a Microsoft account (MSA) consumer key to create forged tokens, which allowed them to impersonate both individual and business users. Microsoft resolved the problem by initially blocking tokens made with the compromised key and subsequently replacing it to halt further unauthorized use.

The team at wiz.io initiated an investigation to identify which keys could sign OpenID tokens for Microsoft accounts and Azure Active Directory applications. By delving into Microsoft’s official OpenID token verification documentation, the team unearthed that all Azure personal account v2.0 applications were tied to 8 public keys, and all Azure multi-tenant v2.0 applications with Microsoft account activation were linked to 7 public keys, as noted at the time of writing.

Using the Internet Archive’s Wayback Machine, the team discovered that one of the public keys, in place since at least 2016, was replaced between June 27th and July 5th, 2023. This coincided with the timeframe Microsoft reported for replacing the acquired key in their blog post.

Upon examining the old public key’s certificate, the team found it was issued on April 5th, 2016, and expired on April 4th, 2021. Its thumbprint matched the thumbprint of the key that Microsoft referenced in their latest blog post, titled “Thumbprint of acquired signing key.”

These findings led the wiz.io team to conclude that the compromised key, obtained by Storm-0558, was not only intended as a private key for Microsoft’s MSA tenant in Azure but also had the ability to sign OpenID v2.0 tokens for various Azure Active Directory applications. The information provided a deeper understanding of the situation and will undoubtedly contribute to their further research and analysis.

Additionally, the wiz.io team learned that the compromised key could potentially impersonate organizational accounts as well. According to Microsoft’s blog post, OWA was impacted by an issue akin to this one.

In a responsive move, Microsoft took steps to assist Azure developers in adopting this validation functionality. On July 12, they integrated it into their official Azure SDK.

For applications supporting accounts in any organizational directory, specifically those categorized as “Any Azure AD directory – Multi-tenant,” the team at wiz.io noted that if the multi-tenant application is set to depend on the “common” v2.0 keys endpoint (instead of “Organizations”), it would be affected. It should also be considered misconfigured. The official Microsoft documentation did not provide clear guidance on when to utilize the “common” endpoint. As a result, some multi-tenant applications could be affected as well.

Regarding applications supporting accounts in a single organizational directory, referred to as “Single tenant,” the wiz.io team found that single tenant applications remained unaffected.

These insights contribute further to the wiz.io team’s understanding of the situation, shedding light on potential vulnerabilities and Microsoft’s responsive actions to ensure the security of Azure applications.

Detection Methods

Considering that threat actors can generate access tokens offline without any trace in the Azure portal, the sole means for cloud clients to ascertain if the key has been utilized against their applications or users is by analyzing particular logs for potentially compromised AAD apps. Hence, those responsible for the applications who aim to safeguard their systems must examine if a counterfeit token has been exploited.

To our understanding, the exclusive impacted applications were those employing Microsoft v2.0 access token authentication with the specified endpoints. This information enables the isolation of applications that remained unaffected.

Initially, to recognize AAD applications that could be at risk in your surroundings, execute the following Azure CLI commands:

az ad app list –filter “(signinaudience eq ‘AzureADMultipleOrgs’ or signinaudience eq ‘AzureADandPersonalMicrosoftAccount’ or signinaudience eq ‘PersonalMicrosoftAccount’)” –query “[?id].{AppName:displayName, AppID:appId, ObjID:id, HomePageURL:web.homePageUrl}”

Moreover, your AAD applications may have links to Azure WebApps. Identify them by executing the CLI command:

az ad app list –filter “(signinaudience eq ‘AzureADMultipleOrgs’ or signinaudience eq ‘AzureADandPersonalMicrosoftAccount’ or signinaudience eq ‘PersonalMicrosoftAccount’)” –query “[?web && web.homePageUrl && contains(web.homePageUrl, ‘azurewebsites.net’)].{AppName:displayName, AppID:appId, ObjID:id, HomePageURL:web.homePageUrl}”

Subsequently, to spot possible malevolent actions, suspicious authentication attempts must be inspected via OpenID tokens signed with the breached key by scrutinizing the access tokens and looking for a specific string within the JOSE Header.

Signs of compromise concern the presence of the string “1LTMzakihiRla_8z2BEJVXeWMqo” in the “kid” value of the JOSE header.

According to Microsoft, as the breached key was inoperative, any token signed with this key must be regarded as dubious.

Regrettably, the lack of universal practices for application-specific logging often means that application owners lack detailed logs containing the raw access token or its signing key, making detection and inquiry quite challenging.

When assessing an AAD application intended solely for multi-tenant authentication, forged tokens can be detected by sifting for certain claims within the access token. Any connection attempt with a token signed by the designated tenant ID may signify a compromised key.

Lastly, if HTTP Logs have been activated in your WebApp, you might be capable of viewing which IP addresses accessed your application. Relying on Microsoft’s blog post, specific IPs are linked with the threat actor, so it’s vital to verify if your WebApp was possibly affected by running a particular query in Log Analytics for each potentially vulnerable Web App:

AppServiceHTTPLogs
| where Result == “Success”
and CIp in (“195.26.87.219″,”185.236.228.183″,”85.239.63.160″,”193.105.134.58”,
“146.0.74.16”,”91.231.186.226″,”91.222.174.41″,”185.38.142.249″,
“51.89.156.153”,”176.31.90.129″,”137.74.181.100″,”193.36.119.45″,
“185.158.248.159”,”131.153.78.188″,”37.143.130.146″,”146.70.157.45″,
“185.195.200.39”,”185.38.142.229″,”146.70.121.44″,”31.42.177.181″,
“185.51.134.52”,”173.44.226.70″,”45.14.227.233″,”185.236.231.109″,
“178.73.220.149”,”45.14.227.212″,”91.222.173.225″,”146.70.35.168″,
“146.70.157.213”,”31.42.177.201″,”5.252.176.8″,”80.85.158.215″,
“193.149.129.88”,”5.252.178.68″,”116.202.251.8″)

Recommendations

In the recently disclosed cybersecurity report, a critical incident involving JWT Key Forging on Azure Active Directory (Azure AD) executed by the notorious hacking group Storm-0558 has come to light. This attack has brought to the forefront a significant vulnerability in Microsoft’s security infrastructure, underscoring the gravity of the situation. The incident highlights the pressing need for stronger security measures and dedicated countermeasures to protect organizations from such sophisticated threats.

The JWT Key Forging attack on Azure AD has far-reaching implications for the security of large enterprises that rely heavily on cloud service providers and software architecture. Given the pervasive use of Azure AD across numerous organizations, this breach potentially exposes sensitive data and resources to unauthorized access, making it an alarming and challenging issue to tackle.

One of the most concerning aspects of this incident is the lack of explicit, dedicated recommendations to prevent or mitigate such a breach. As Azure AD and similar cloud services are foundational components of many organizations’ infrastructure, any compromise to the security of these services has cascading effects on overall cybersecurity posture.

The report underscores the urgency for Microsoft to reassess and strengthen their security mechanisms, identifying and addressing any potential weaknesses or misconfigurations within Azure AD. Additionally, it emphasizes the importance for organizations utilizing cloud-based services to adopt comprehensive security practices, such as multi-factor authentication, role-based access control, and regular security audits.

Furthermore, the incident serves as a stark reminder to companies to maintain robust incident response plans. In the face of sophisticated adversaries like Storm-0558, rapid detection and containment are essential to limit the damage caused by a potential breach.

References

https://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr#how-to-detect-the-compromised-key-in-your-environment-57

https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/

https://www.bleepingcomputer.com/news/security/microsoft-chinese-hackers-breached-us-govt-exchange-email-accounts/

Glossary of terms

POC – Proof of Concept­
TI – Threat Intelligence
TLP – Traffic Light Protocol
Mitigations – The reduction of something harmful or the reduction of its harmful effects. It may refer to measures taken to reduce the harmful effects of hazards that remain in potential, or to manage harmful incidents that have already occurred.