Dangerous Application 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.

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

• Application permissions: this Indicator of Exposure examines this first type, see the related Indicator of Exposure "Dangerous Application Permissions Affecting the Tenant" for threats to the entire Microsoft Entra tenant. The consent comes from administrators and the permissions apply tenant-wide. Microsoft describes them as:

  Application permissions are used by apps that run without a signed-in user present. For example, apps that run as background services or daemons. Application permissions can be consented only by an administrator.

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

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.

• Application permissions always require administrator consent. Train these administrators to identify suspicious applications and sensitive permissions, including data-related application permissions. 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.

Make sure to remove the dangerous 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 high-risk service principals highlighted here.

Name: Dangerous Application Permissions Affecting Data

Codename: DANGEROUS-APPLICATION-PERMISSIONS-AFFECTING-DATA

Severity: Medium

Type: Microsoft Entra ID Indicator of Exposure