Keypoints
- Researchers abused the preAuthorizedApplications manifest attribute to include a malicious app alongside a verified publisher app during consent.
- The attack relies on default user-consent settings that allow users to consent to multi-tenant apps without requiring user assignment.
- Attackers craft sign-in URLs that reference the verified app’s AppId (client_id) while specifying the malicious app as a requested scope, making the consent prompt appear legitimate.
- Setting a malicious app’s displayName to resemble the verified app obscures the presence of the unverified application in the consent UI.
- Successful consent adds both the legitimate and malicious applications to the tenant; attackers then request access tokens for the malicious app against target apps that only validate issuer/audience.
- Detection can be performed by querying audit logs for two apps added within a short window and checking AppOwnerOrganization via the Microsoft Graph API.
- Mitigations: Microsoft modified the consent dialog to show two apps and mark unverified apps, and organizations should restrict or disable user consent and follow Microsoft hardening guidance.
MITRE Techniques
- [T1087] Account Discovery – Enumerated existing published applications via Microsoft Graph by reading the ‘verifiedPublisher’ attribute in the servicePrincipal object (‘…the ‘verifiedPublisher’ attribute exposed in the servicePrincipal object…’).
- [T1098] Account Manipulation – Modified the malicious application’s manifest ‘preAuthorizedApplications’ attribute to pre-approve access alongside a verified app (‘…populated the application manifest of the malicious application under the ‘preAuthorizedApplications’ attribute.’).
- [T1078] Valid Accounts – Requested access tokens for the malicious application using any target app that accepts valid Azure AD tokens based on issuer/audience, leveraging default user assignment settings (‘…request access tokens for any application in the tenant that does not require user assignment…’).
Indicators of Compromise
- [API endpoint] Graph API servicePrincipal GET – https://learn.microsoft.com/en-us/graph/api/serviceprincipal-get?view=graph-rest-1.0 (used to read ‘verifiedPublisher’ and servicePrincipal details).
- [Sign-in URL parameter / AppId] client_id parameter and AppId enumeration – ‘?client_id={appId}’ used to reference a verified application’s AppId when crafting malicious sign-in URLs.
- [Report / Reference] Secureworks analysis URL – https://www.secureworks.com/research/spoofing-microsoft-entra-id-verified-publisher-status (detailed technical report and images).
Researchers used a targeted “application smuggling” procedure that exploits default Microsoft Entra ID (Azure AD) consent behavior and the preAuthorizedApplications manifest field. Attackers enumerate verified-publisher applications (via the Microsoft Graph servicePrincipal ‘verifiedPublisher’ attribute), obtain a verified app’s AppId, and create a malicious multi-tenant app whose manifest includes the verified app in preAuthorizedApplications. Because many applications (e.g., Azure Web Apps/Functions with default Azure AD auth) only validate issuer and audience, the attacker can later request tokens for the malicious app and access resources that accept those tokens.
The step-by-step technique: 1) discover a verified app’s AppId and add an entry into the malicious app’s application manifest under ‘preAuthorizedApplications’; 2) craft a sign-in URL that uses the verified app’s AppId as the client_id while setting the malicious application’s identifier as a requested scope; 3) set the malicious app’s displayName to mimic the verified application so the consent prompt emphasizes the legitimate app; 4) when a user in a tenant with default consent settings approves the prompt, both apps are added to the tenant and the attacker can request access tokens for the malicious app against target applications that do not enforce strict token validation (beyond issuer/audience).
Detection involves querying audit logs (KQL) for cases where two apps are consented/added within a short timeframe by the same user and then using the Microsoft Graph API to compare AppOwnerOrganization values to spot mismatches. Mitigations include disabling or restricting user consent, limiting consent to verified publishers, and applying Microsoft’s recommended Azure AD hardening steps. Microsoft also updated the consent dialog to explicitly indicate when consent applies to two apps and to label unverified applications, reducing the attack’s success rate.
Read more: https://www.secureworks.com/research/spoofing-microsoft-entra-id-verified-publisher-status