Dangerous Delegated Permissions Affecting Data

Microsoft exposes APIs through applications in Entra ID to allow 3rd-party applications to perform actions on Microsoft Entra ID itself, Microsoft 365 (O365), and services like SharePoint Online and Exchange Online. "API permissions" protect the access to these APIs, which should only be available to the service principals that require them. The permissions approval is called an "application role assignment" or a "consent grant".

Certain permissions on some Microsoft APIs can pose a threat to the environment sensitive data, because a service principal with these permissions is able to access potential sensitive information while being more discreet than a user with a powerful administrator role such as Global Administrator.

When legitimate, these permissions increase the risk of data compromise. When they are not legitimate, they may indicate a malicious attempt to access and steal sensitive data, such as emails and projects.

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

• Application permissions: see the related Indicator of Exposure "Dangerous Application Permissions Affecting Data".

• Delegated permissions: this Indicator of Exposure examines this second type, see the related Indicator of Exposure "Dangerous Delegated Permissions Affecting the Tenant" for threats to the entire Microsoft Entra tenant. 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 danger level 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. Microsoft describes them as:

  Delegated permissions are used by apps that have a signed-in user present and can have consents applied by the administrator or user.

This Indicator of Exposure (IoE) reports only on service principals, as API permissions apply solely to service principals, not users.

This IoE tracks a list of sensitive permissions, most of which are self-explanatory. However, the following permission require further explanation:

• Group.Read.All (exposed by the Microsoft Graph API and Office 365 Exchange Online): This permission is surprisingly risky, as it allows to read even the content of the M365 groups "calendar, conversations, files, and other group content". Consider the implications for M365 Groups used by Microsoft Teams.

Legitimate applications with these sensitive permissions request access that may be overly broad. This can also indicate a phishing attack known as an "illicit consent grant," where an attacker successfully obtains consent from an administrator.

By default, this IoE ignores disabled service principals because attackers cannot immediately use them.

External references:

• Cloudbrothers - Azure Attack Paths
• Microsoft - Exchange Web Server API abuse
• Microsoft - Threat actors misuse OAuth applications to automate financially driven attacks

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 sensitive permissions.
    • If this is an internal application, evaluate its features and reduce permissions by following the least privilege principle, as outlined in the Consent and Authorization section of the Microsoft Graph API documentation. This guidance specifies the minimal permissions required for each API.
    • If this is a 3rd-party application, validate that data access is appropriate for this application (same perimeter). If not, challenge the vendor to document the reason why those permissions are necessary and if they can be safely removed.
  • As a defense-in-depth measure, if you have the required Workload Identities Premium licenses, consider using Conditional Access for Workload Identities. This allows you to restrict high-risk service principals to known trusted locations and limit access based on risky sign-ins.

• By default, all users can delegate permissions to any application and this lets them make sensitive security decisions. Refer to the corresponding "Unrestricted User Consent for Applications" Indicator of Exposure. 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.

• Train administrators to identify suspicious applications and sensitive permissions, including 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. Please follow Microsoft guidance to review permissions granted to enterprise applications. Unfortunately, this functionality is not available in the Microsoft Entra admin portal:

  You cannot revoke permissions from the "User consent" tab using the Microsoft Entra admin portal. However, you can revoke these permissions through Microsoft Graph API calls or PowerShell cmdlets. For more details, refer to the PowerShell and Microsoft Graph sections of this article.

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

Make sure to remove the sensitive permission from the service principal (found in the "Enterprise applications" menu of the portal), rather than from the application (found in the "App registrations" menu). Removing it from the application only deletes the permission request and does not affect the actual permission assignment.

Finally, enable Graph API activity logs to capture detailed information about Graph API events, helping your SOC or SIEM identify suspicious activity or conduct forensic investigations in the event of an attack. Additionally, monitor service principal sign-ins and configure alerts for suspicious behavior, particularly for the sensitive service principals highlighted here.

Name: Dangerous Delegated Permissions Affecting Data

Codename: DANGEROUS-DELEGATED-PERMISSIONS-AFFECTING-DATA

Severity: Medium

Type: Microsoft Entra ID Indicator of Exposure