Dangerous API Permissions Affecting the Tenant

Microsoft exposes APIs through applications in Entra ID to allow 3rd-party applications to perform actions on Microsoft Entra ID itself, Microsoft 365 (O365), Azure cloud, etc. "API permissions" protect the access to these APIs which only the service principals that need them can have. The permissions approval is called an "application role assignment" or a "consent grant".

Certain permissions on some Microsoft APIs (see below) can pose a serious threat to the entire Microsoft Entra tenant, because a service principal with these permissions becomes very powerful while being more discreet than a user with a powerful administrator role such as Global Administrator. Abusing this can allow an attacker to bypass the Multi-Factor Authentication (MFA) and resist user password resets.

When legitimate, the permissions increase the attack surface for the tenant. When they are not legitimate, it can be an malicious attempt to escalate privileges or persistence method.

There are two types of API permissions in Microsoft Entra ID as described in the Microsoft documentation Introduction to permissions and consent:

• Application permissions: The consent comes from administrators and the permissions apply tenant-wide.
• Delegated permissions: The consent comes from users or administrators on behalf of the entire organization. Note that these permissions limit the application's ability to perform actions based on the signed-in user's privilege (i.e. the intersection of the permission and the user's privilege level). Therefore, the dangerousness of these delegated permissions depends on the actual permissions of the user of the application, as described in Developing delegated permissions strategy. Example: If a normal user delegated the "Group.ReadWrite.All" permission, it actually allows the application to modify only the groups that the user can edit and not all groups.

This Indicator of Exposure examines both types of permissions. It only reports on service principals because API permissions can only apply to service principals and not users.

This Indicator of Exposure is also focused on permissions that allow access to the Microsoft Graph API and the legacy Azure AD Graph API. In particular, the following dangerous permissions can pose a security risk:

• RoleManagement.ReadWrite.Directory: Allows attackers to elevate themselves to the Global Administrator role.
• AppRoleAssignment.ReadWrite.All: Allows attackers to grant themselves the RoleManagement.ReadWrite.Directory permission (see above).

Legitimate applications with these dangerous permissions ask for permissions that may be too broad. This can also signal a phishing attack called an "illicit consent grant", where an attacker succeeds in obtaining the consent of an administrator.

Disabled service principals are ignored by default because they cannot be immediately used by attackers.

Begin by determining if the reported service principal with the permission is legitimate. Be aware that it is technically possible to spoof the display name in a phishing attack. If the service principal appears to belong to a known software vendor, ask them to confirm that the reported application ID belongs to them. If the service principal is illegitimate and it spoofs a known application name, you should do a forensic analysis.

• If the service principal is legitimate, identify its owner and role to evaluate whether it actually needs these dangerous permissions. If this is an in-house application, depending on its features, reduce the permission(s) using the least privilege principle best practice as described in the "Consent and authorization" section of the Microsoft Graph API documentation, which specifically describes the required minimal permissions for each API. If this is a 3rd-party application, challenge the vendor to lower the required permission(s) or at least to document why they are needed.
• By default, all users can delegate permissions to any application and this lets them make sensitive security decisions. Microsoft Entra ID provides options that you can enable to configure user consent. When you enable restrictions, Microsoft Entra administrators with certain roles must Manage consent to applications and evaluate consent requests. See also how to Review admin consent requests.
• Application permissions always require administrator consent. Train these administrators to identify suspicious applications and sensitive permissions, particularly tenant-wide application permissions, as well as delegated permissions from privileged or sensitive users. This must be part of a larger application governance effort.
• Remove a permission if you deem it to be illegitimate. Tenable recommends that you save evidence first if you plan to perform a deeper forensic investigation. The Microsoft Entra portal has a dedicated feature to Review permissions granted to enterprise applications.

Microsoft also published two guides on how to perform an Application consent grant investigation and how to Detect and Remediate Illicit Consent Grants.

Name: Dangerous API Permissions Affecting the Tenant

Codename: DANGEROUS-API-PERMISSIONS-AFFECTING-THE-TENANT

Severity: High