Forged Azure Access Tokens Exploited by Storm-0558: A Cloud Vulnerability Transparency Gap

Starting May 15, 2023, threat actor Storm-0558 illicitly employed forged Azure Access tokens tokens to gain unauthorized access to user emails in around 25 organizations, encompassing government agencies and various consumer accounts hosted on the public cloud.

By June 2023, a Federal Civilian Executive Branch (FCEB) agency noticed unusual MailItemsAccessed events in M365 Audit Logs, revealing unexpected ClientAppID and AppID information. These events are generated when licensed users access items in Exchange Online mailboxes through different connectivity protocols and client applications. The FCEB agency found the activity suspicious because the observed AppID was not typically associated with accessing mailbox items in their environment and they promptly reported the suspicious activity to Microsoft and CISA. Upon investigation, Microsoft determined that the security breach had been orchestrated by a threat actor known as Storm-0558, operating out of China. The malevolent actor managed to breach the system and extract unclassified Exchange Online Outlook data.

In this blog post, we examine the findings of both Microsoft and Wiz regarding the cyberattack by Storm-0558, exploring the forged authentication tokens used to gain unauthorized access to user emails. We analyze the contradiction between their analyses, discuss the impact of the attack, and provide recommendations for enhancing security measures. Additionally, we will discuss a critical issue affecting cloud security – the systematic lack of transparency around cloud vulnerabilities. We will explore the implications under communication and under documentation of cloud vulnerabilities, along with the absence of assigned CVE IDs on cloud service provider’s end users. 

Background Details on the Forged Azure Access Tokens

Authentication Tokens

Authentication tokens are used to verify the identity of entities (e.g., users, applications) that request access to specific resources, in this case, email services. These tokens are issued by identity providers like Azure Active Directory (AD) when a user or application successfully authenticates.

Token Signing and Validation

To ensure the authenticity of the token, the identity provider signs the token using a private signing key, creating a digital signature. When the entity presents the token to access a resource, the receiving party (relying party) validates the token’s signature using a corresponding public validation key provided by the identity provider. If the signature is valid, the relying party trusts the token and grants access to the requested resource.

Token Forgery 

Token forgery occurs when a malicious actor gains access to a private signing key. With this key, the actor can create fake tokens with valid signatures, making them appear legitimate to the relying parties. As a result, the malicious actor can gain unauthorized access to resources.

Microsoft Attack Analysis

Upon receiving the report of malicious activity, on July 16, 20223, Microsoft promptly initiated an in-depth analysis of the attack.

The investigation revealed that Storm-0558 had gained unauthorized access to customer data through Microsoft’s Exchange Online service, which is responsible for handling email and calendar functions. Initially, Microsoft suspected that the attacker might be stealing valid Azure Active Directory (Azure AD) tokens through malware-infected customer devices. However, further scrutiny unveiled a different approach used by Storm-0558 – the forgery of authentication tokens.

First Issue

The threat actor accomplished token forgery by obtaining an inactive Microsoft Account (MSA) consumer signing key, which was intended for MSA accounts (personal Microsoft accounts). They used this key to forge authentication tokens for both Azure AD enterprise and MSA consumer accounts. Since Microsoft did not validate inactive account keys or the issuer of the signing keys the attackers successfully took advantage of the key.

During their investigation, Microsoft’s team noticed the attacker misused the acquired MSA consumer signing key to sign access requests improperly. This abnormal behavior was a red flag as no legitimate Microsoft system signs tokens in such a manner, clearly indicating suspicious activity.

Second Issue

Since the GetAccessTokenForResource API had a design flaw that allowed access issued not only from Azure AD or MSA, the threat actor accessed the Outlook Web Access (OWA) API to retrieve a token for Exchange Online from the GetAccessTokenForResource API used by OWA. By presenting previously issued tokens, the threat actor successfully obtained new access tokens.

Impact

Storm-0558 utilized a collection of PowerShell and Python scripts to interact with the OWA Exchange Store service through REST API calls.

The threat actor can use the minted access tokens obtained during the attack to extract various email-related data, such as downloading emails, attachments, locating and downloading conversations, and retrieving email folder information. According to Microsoft, the incident did not impact Azure AD keys, meaning the keys used for enterprise accounts were not compromised in this attack.

The threat actors were found to be exfiltrating unclassified Exchange Online Outlook data from a small number of accounts. 

Wiz Attack Analysis

Contradiction

On July 21, 2023, Wiz released their attack analysis, which contradicted some of Microsoft’s initial statements. According to Wiz, the compromised signing key possessed more power than Microsoft had acknowledged and was not limited to just Outlook Web Access (OWA) and Outlook.com. Instead, Wiz found that the compromised MSA key could potentially forge access tokens for various Azure Active Directory applications, including those supporting personal account authentication like SharePoint, Teams, OneDrive, applications utilizing the “login with Microsoft” feature, and certain multi-tenant applications.

Wiz also highlighted that while Microsoft had taken measures to mitigate the attack, detecting the use of forged tokens in customer applications remained challenging due to the lack of logs related to the token verification process.

Discoveries

During their investigation, Wiz thoroughly examined the keys responsible for signing OpenID tokens for Microsoft accounts and Azure Active Directory applications. By referring to Microsoft’s official documentation for OpenID token verification, they discovered that Azure personal account v2.0 applications relied on 8 public keys, while Azure multi-tenant v2.0 applications with Microsoft account enabled depended on 7 public keys.

Through the Wayback Machine, Wiz observed that one of the keys had been in use since at least 2016 but was replaced between June 27th and July 5th, 2023, aligning with Microsoft’s key replacement timeline mentioned in their blog post. This specific key had been issued on April 5th, 2016, and expired on April 4th, 2021, further corroborating the fact that attackers used an inactive key, which Microsoft subsequently fixed. Interestingly, Wiz also found this very key listed in Microsoft’s latest blog post under the “Indicators of compromise” section.

Impact

Wiz’s analysis indicated that Storm-0558 could have potentially utilized the acquired private key to forge tokens and authenticate as any user to any affected application that trusted Microsoft OpenID v2.0 mixed audience and personal-accounts certificates.

Additionally, multi-tenant applications relying on the “common” v2.0 keys endpoint (instead of “Organizations”) were affected, though this configuration should be considered misconfigured. The official Microsoft documentation lacked clarity on when the “common” endpoint should be used, leading to potential impacts on some multi-tenant applications.

However, single-tenant applications and Azure Active Directory applications that worked with Microsoft’s OpenID v1.0 were determined to be not affected.

Exploit

To forge a valid access token, the threat actor could have crafted a JWT token, inserted victim data (e.g., email address), and then signed it using the compromised key listed under the Azure Active Directory public certificates’ endpoint. By presenting the signed token to a targeted application, the malicious actor could impersonate the victim, gaining unauthorized access.

Potential Risk

As the threat actor exploited the vulnerability before the key revocation on customers’ environments, they could have potentially used their access to establish persistence. This might have been achieved by leveraging the obtained application permissions to issue application-specific access keys or creating application-specific backdoors. A significant instance of this occurred when Storm-0558 successfully forged access tokens for Outlook Web Access (OWA), granting them valid Exchange Online access tokens before Microsoft’s mitigation measures were implemented.

Additional potential risk can be for applications that retained copies of the Azure Active Directory (AAD) public keys prior to Microsoft’s certificate revocation. Applications relying on local certificate stores or cached keys that still trust the compromised key are susceptible to token forgery. 

Microsoft Response

According to Wiz, there is a lack of standardized practices regarding application-specific logging, leading to challenges for application owners in identifying and investigating events related to access tokens and their signing keys.

Just two days before Wiz released their research, Microsoft made an announcement regarding the expansion of Microsoft’s cloud logging accessibility and flexibility. This new development allows customers to utilize Microsoft Purview Audit, providing detailed logs of email access and over 30 other types of log data, which were previously only available at the Microsoft Purview Audit (Premium) subscription level. Additionally, Microsoft has increased the default retention period for Audit Standard customers from 90 days to 180 days. 

Wiz’s analysis suggests that millions of applications, both Microsoft apps and customer apps, might be vulnerable, making it challenging to fully determine the extent of the incident.

In response, Microsoft disputes some of the claims made in Wiz’s blog, stating that they are speculative and lack concrete evidence. While Microsoft acknowledges reviewing and validating Wiz’s post, they clarify that Wiz’s blog highlights hypothetical attack scenarios that they have not observed in real-world situations.

Microsoft Actions

In response to the discoveries, Microsoft has taken action to mitigate the token forgery technique and validation error in OWA and Outlook.com without requiring any customer intervention. The following steps were taken:

• On June 26, OWA stopped accepting tokens issued from GetAccessTokensForResource for renewal, preventing token renewal abuse.
• On June 27, Microsoft blocked the usage of tokens signed with the acquired MSA key in OWA, halting further threat actor enterprise mail activity.
• On June 29, Microsoft invalidated all active MSA keys prior to the incident, including the one acquired by the actor in order to prevent further misuse of these keys. New MSA signing keys were issued with enhanced security measures.
  • Microsoft increased the isolation of key-related systems from corporate environments, applications, and users while refining monitoring and implementing automated alerting for key activity.
  • The MSA signing keys were moved to the key store used for enterprise systems.
• On July 3, Microsoft blocked the key’s usage for all affected consumer customers, preventing the use of previously-issued tokens.

Microsoft mentions that ongoing monitoring indicates that all actor activity related to this incident has been blocked, and that it will continue to monitor Storm-0558 activity and implement further protections for customers. As a result, Microsoft states that its services have been safeguarded against the described techniques, and no additional action is needed from customers to protect Exchange Online and Outlook.com.

Validation of Signing Keys

Microsoft introduced an extension to the OpenID protocol. This extension, which has been added to their official Azure SDK on July 12, advises developers to validate the issuer. To assist Azure developers with adopting this validation functionality.

The extension performed in this commit in the Microsoft.IdentityModel library. it introduces checks for security tokens issued by the Microsoft identity platform. The fix includes the following improvements:

• Validation of Signing Key from Certificate: When a signing key is derived from a certificate, the fix validates that the certificate is currently active and has not expired. This ensures that only valid and up-to-date certificates are used for signing tokens.
• Issuer Validation: The fix enables validation of the issuer of the signing keys used by the Microsoft identity platform (Azure Active Directory – AAD) against the issuer of the token. This step ensures that the issuer of the token matches the expected issuer based on the signing key, enhancing the overall security of the authentication process.

In summary, these updates in the Microsoft.IdentityModel library strengthen the security of the tokens issued by the Microsoft identity platform by carefully validating the signing keys and their associated certificates, ensuring their integrity and validity during the authentication and authorization process.

In a recent commit in the Microsoft.Identity.Web library, Microsoft added the issuer validation check imported from the Microsoft.IdentityModel library.

A Systematic Lack of Transparency Around Cloud Vulnerabilities

Unfortunately, these issues bring forth a recurring pattern around cloud vulnerabilities and security issues – lack of sufficient transparency. As cloud adoption continues to accelerate, Cloud vulnerabilities are inevitably becoming an industry-wide issue, yet are often under communicated and under documented. In most cases, cloud security issues will not even be assigned a CVE ID. While customer action is often required in order to remediate these issues, the absence of assigned CVEs by cloud providers makes it challenging to document, track, and monitor these vulnerabilities. Although some cloud providers may send alerts or publish blog posts alerting on these security issues, it falls short in garnering enough attention. Existing security tools are designed to rely on identifiers, making vulnerabilities without them practically invisible.

In one of Wiz’s talks at Black Hat 2021, they presented new cross-account vulnerabilities in AWS, which, unfortunately, did not receive a CVE and hence are not tracked by NIST. Scanning tools offering IAM vulnerability results also overlook these vulnerabilities. As a potential solution, Wiz proposed collaborating with cloud providers to establish a cloud vulnerability database, aptly named CLOUDVULNDB. Such a database would cater to vulnerabilities lacking identifiers, thereby improving the overall visibility and management of cloud vulnerabilities.

Now, returning to our case, Microsoft identified two main issues that required fixing: a validation issue and a design flaw. The first issue stemmed from Microsoft not properly validating inactive account keys or the issuer of the signing key, which allowed attackers to exploit an inactive key and forge authentication tokens for both Azure AD enterprise and MSA consumer accounts.

The second issue arose from a design flaw in the GetAccessTokenForResource API, which permitted access not only from Azure AD or MSA but also from unauthorized sources. This flaw enabled the threat actor to successfully obtain new access tokens, bypassing proper authorization checks.

These identified issues resemble vulnerabilities that, if found in another vendor’s product, would likely be assigned a CVE. Specifically, the first issue aligns with CWE-287 (Improper Authentication) and CWE-285 (Improper Authorization).

• CWE-287 is relevant when an actor claims to have a given identity, and the product fails to prove or insufficiently proves the claim’s correctness. In this case, Microsoft’s failure to validate inactive account keys or the issuer of the signing key allowed the threat actors to successfully authenticate with an inactive token that did not belong to them.
• CWE-285 pertains to situations where an application does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. In this case, the design flaw in the GetAccessTokenForResource API permitted the threat actor to access the Outlook Web Access (OWA) API and retrieve new access tokens for Exchange Online from unauthorized sources, beyond just Azure AD or MSA. This lack of proper authorization checks allowed the threat actor to obtain new access tokens, which they should not have been able to do.

The absence of assigned CVEs to these two vulnerabilities creates a significant security gap, leaving them invisible to most standard security tooling and potentially under-addressed. The exploitation of these vulnerabilities by the storm-0558 threat actors highlights their critical nature. What makes the situation even more concerning is that users must take action and update the Azure AD identity model extension to mitigate the risks, when they are probably not aware of their existence. 

A comprehensive cloud vulnerabilities DB, like the one proposed by Wiz, could help bridge this gap and improve the overall security of cloud environments, but ultimately the CSPs should be upheld to a more strict standard of transparency and accountability.

Recommendations

In order to avoid similar cyberattacks and detect suspicious activity, users are recommended to follow the following steps:

• Enable Audit Logging and Advanced Audit for at least twelve months in active storage and an additional eighteen months in cold storage as dictated by OMB M-21-31. Although Microsoft expanded cloud logging accessibility and flexibility, it is still not enough to comply with the OMB M-21-31 standard.
• Monitor potentially affected applications in your environment and leverage the Indicators of Compromise (IoCs) published by Microsoft on their blog in order to identify suspicious activity.
• To enhance security against such threats, it is crucial for applications to promptly refresh their list of trusted certificates. Microsoft advises refreshing the cache of local stores and certificates at least once a day to ensure robust protection.
• Make sure to update the Azure AD identity model extensions to the latest version which offers an extension to the OpenID that validates the issuer.

About the author: Ofri Ouzan is a security researcher with Rezilion.