SUMMARY
In early 2023, Secureworks® Counter Threat Unit™ (CTU) researchers discovered how to manipulate the consenting process of a legitimate verified publisher application to implant malicious unverified applications within a Microsoft Entra ID (formerly known as Azure Active Directory) tenant[1]. Any tenant that retained the default user consent configuration for enterprise applications was susceptible to this attack.
CTU™ researchers disclosed the issue to Microsoft in February 2023. Microsoft confirmed that spoofing was possible and assigned an “important” severity rating. At the end of June, Microsoft modified the consent request dialog to mitigate the issue.
ANATOMY OF THE ATTACK
The attack uses a novel ‘application smuggling’ approach to abuse an Azure AD feature. This feature’s default setting allows a malicious application to request access tokens for any application in the tenant that does not require user assignment, regardless of the permissions granted for the malicious application (see Figure 1). The attacker could gain access to applications that only verify that the request uses a valid Azure AD token that has a correct audience value. As of this publication, the default behavior for Azure Web Apps and Functions when configured to use Azure AD authentication makes them susceptible to this attack. Applications that validate the token beyond issuer and audience value are not susceptible.
Figure 1. Microsoft notification about the default behavior. (Source: Microsoft)
CTU researchers investigated a preAuthorizedApplications setting that pre-approves applications as part of the application consent. The attack uses this setting to obtain consent for both a verified application and an attacker-controlled application. Because both applications are multi-tenant, it does not matter if they are hosted in different tenants or if one of them is not from a verified publisher.
Applications published by verified organizations display a blue badge on the consent prompt. This graphic indicates that Microsoft verifies the organization’s authenticity. Using the preauthorized application setting, we crafted a malicious sign-in URL. The objective was to achieve a sign-in URL that highlights the legitimate application for the consent rather than the existence of the malicious application.
An application’s display name can be set to any value, so we set the ‘displayName’ attribute of the malicious application to be ‘verified application’ (see Figure 2). By a choosing a displayName that appears to reference the legitimate application in the consent prompt text, we obscured the secondary access to the unverified malicious application.
Figure 2. Incorporating a malicious application into a legitimate consent request. (Source: Secureworks)
Configuring preAuthorizedApplications
We first identified existing applications published by the verified publisher. This task is trivial, as this information is not hidden. This information can be read in the Microsoft Graph API by reviewing the ‘verifiedPublisher’ attribute exposed in the servicePrincipal object (see Figure 3).
Figure 3. Verified publisher information. (Source: https://learn.microsoft.com/en-us/graph/api/serviceprincipal-get?view=graph-rest-1.0)
We then performed the following steps to conduct the spoofing attack depicted in Figure 4.
Figure 4. Spoofing process. (Source: Secureworks)
- After acquiring the ‘AppId’ value of a verified publisher application, we populated the application manifest of the malicious application under the ‘preAuthorizedApplications’ attribute.
- We then configured the sign-in URL that is sent to the targeted organization’s users. This URL referenced the legitimate application’s AppId in the ‘?client_id={appId}’ parameter and defined the malicious application as the scope value of the legitimate application.
- If a user approves the consent prompt in any tenant configured with default settings, they add both the legitimate and malicious applications to the tenant (see Figure 5).
Figure 5. This verified application is the malicious application. (Source: Secureworks) - The attacker then requests access tokens for the malicious application using any target application that retains the default configuration for user assignment.
This analysis does not discuss AppID enumeration. This process typically requires checking the victim’s existing services for Azure AD login authorize URLs and then acquiring the AppID for the target application. As a mitigating factor, the malicious application does not have permission to enumerate existing AppIDs. However, AppIDs are not secret, so they could be easily discovered.
DETECTION
We can check for abuse in Azure AD by querying the workspace that retains the audit logs (see Figure 6). There are legitimate scenarios for consenting two applications in single operation, but they appear less common. Therefore, this approach is a relatively good way to detect possible abuse.
Figure 6. Query to identify abuse. (Source: Secureworks)
If the query reveals that two apps were added within a 10-second timeframe by the same user (see Figure 7), organizations can use the Microsoft Graph API to determine if both apps are from the same organization. This information is exposed in the Microsoft Graph servicePrincipal object’s ‘AppOwnerOrganization’ value.
Figure 7. Result of KQL query. (Source: Secureworks)
COMMUNICATION WITH MICROSOFT
CTU researchers reported this vulnerability to the Microsoft Security Response Center (MSRC) on February 11, 2023. In June, Microsoft addressed the issue by modifying the dialog to clearly indicate that the consent would apply to two apps and that the second app is unverified (see Figure 8). This transparency greatly reduces the success of this spoofing attack.
Figure 8. Modified dialog revealing the request for consent to two apps. (Source: Secureworks)
CONCLUSION
This attack relies on the default consent setting that allows user consent for any app (see Figure 9). Disabling user consent or only allowing it for verified applications prevents this attack.
Figure 9. User consent options. (Source: Secureworks)
Organizations should apply the Microsoft recommendations for hardening Azure AD application consent settings if the tenant retains the default settings. Our method of smuggling the malicious application into the target tenant would not have succeeded in a tenant with hardened consent settings, as the application was not from a verified publisher.
[1] This analysis retains the Azure AD terminology that was in use during the investigation.
https://www.secureworks.com/research/spoofing-microsoft-entra-id-verified-publisher-status