Integrating applications, services and systems with Microsoft Entra ID brings organizations many benefits. People who need apps for their productivity love that their organization allows them to bring these apps and integrate them with the organization’s IAM processes. However, adversaries also like this (default) setting.
The default setting that I’m referring to is the ability for people in the organization to integrate apps into the organization’s Entra tenant. Delegated permissions that these people can consent to then perform their magic by presenting all your information to these apps’ back-ends.
In the early years of Entra - when the service was still named Windows Azure Active Directory and Azure AD - the service was positioned as an enabler. Adoption was seen as key to its success. Many default settings in Entra, these days, still reflect this mindset… but it might be welcoming unnecessary risk into your organization.
In the past, we have already seen adversaries compromise organizations with and through malicious OAuth apps.
Amnesty International reported in 2019 that human rights defenders in the Middle East and North Africa were being targeted by adversaries who abused the limited protections offered through the device code flow. Midnight Blizzard (APT29) compromised mailboxes belonging to HPE and Microsoft executives using OAuth attack tactics in 2023 H2. At Microsoft, they moved laterally from one of Microsoft’s test tenants to their production tenant.
Microsoft provided actionable advice on these topics, including disabling the device code authentication flow.
Because of these breaches, many security professionals, including Tenable and the Center for Internet Security, now recommend disabling user consent. The Entra management portal, however, still recommends allowing user consent for apps from verified publishers for selected permissions, as seen in the screenshot below:
Figure 1: User consent settings in the Entra management portal
Whether you choose Allow user consent for apps from verified publishers for selected permissions or Do not allow user consent, you can enable the admin consent workflow. (You can also enable it with the Allow user consent for apps setting, but it just wouldn’t do much)
In this workflow, when a person is unable to consent to an application, service or platform, Entra provides a message box where the person can request consent from an admin. This request goes through the admin consent workflow, finds its way to an admin who then decides whether this app is allowed or not.
The difference between not allowing user consent and allowing user consent for apps from verified publishers can be significant for your organization. From analyzing user-consented OAuth apps in several tenants, I estimate that roughly half of all user consent is towards apps from verified publishers for typically low-risk User.Read, profile, openid, and email permissions.
The consequence is that when admins change user consent settings from Allow user consent for apps from verified publishers for selected permissions to Do not allow user consent and enabling the admin consent workflow with adequate settings, IT support personnel might be burdened with roughly twice the workload on application consent. In some organizations, this is simply not an option.
Even though verified publisher status can be spoofed, it appears that few adversaries use this tactic. Let’s look at two recent adversary tactics:
Malicious Adobe and DocuSign apps
In a recent attack campaign, discovered by Proofpoint, malicious OAuth apps were impersonating Adobe Drive, Adobe Drive X, Adobe Acrobat and DocuSign:
Figure 2: Malicious OAuth apps impersonating Adobe and DocuSign apps
However, as shown above in a screenshot from Proofpoint, their consent prompts, requesting email, openid and profile permissions would not have let people consent to these apps in Entra tenants configured with the Allow user consent for apps from verified publishers for selected permissions setting. Even though the permissions are low-risk permissions, the verified publisher status of these apps was labeled as unverified.
Fake security alerts on GitHub
A widespread phishing campaign has targeted nearly 12,000 GitHub repositories with fake Security Alert issues, tricking developers into authorizing the gitsecurityapp OAuth app that grants adversaries full control over their accounts and code.
What stands out with this campaign is that the permissions adversaries requested in themselves don’t signify the malicious purpose, but that these permissions could be compounded to get full control. Of the repo, user, read: org, read: discussion, write: discussion, gist, delete_repo and workflows permission requested, only delete_repo stands out as privileged.
On GitHub, the verified publisher status is not (yet) used.
As previously mentioned, the permissions configured as low privileged greatly impact the added benefit of using the Allow user consent for apps from verified publishers for selected permissions setting. For the four main permissions that apps typically request to work (User.Read, profile, openid, and email), compounding to having global administrator-equivalent privileges is out of the question.
App Governance Accelerator can help!
If you want to address user-consented apps without verified publishers, the Entra Management portal isn’t a great tool to go through thousands of enterprise applications in your search.
Discovering non-admin consented API permissions
With App Governance Accelerator, it is easy to report on enterprise applications that have mere user consent. For multi-tenant applications, the Non-Admin Consented API Permissions report under the Enterprise Apps node of App Governance Accelerator is the way to go:
Navigate to the AppGov Management Portal.
In the screenshot above, the condition for API Permission User Consent count is the default expression to find user-consented apps. With the additional expression, the results show apps that would typically have been directed through the admin consent workflow. This is a helpful starting point for identifying high-risk user-consented applications from non-verified publishers.
App Governance Accelerator makes short work of analyzing the applications in Microsoft Entra tenants. Minutes from receiving information on new attack campaigns, we were able to create a report and answer the question ‘Should Do not allow user consent be the new recommendation to tackle Malicious OAuth apps?’ for this tenant.
As there were no apps in the report, for this tenant, the Allow user consent for apps from verified publishers for selected permissions setting is the right setting…for now. But what about your tenant?😉