Detections
Analytics

Dangerous Application Permissions Affecting the Tenant

HIGH

Language:

Description

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 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 (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: this Indicator of Exposure examines this first type. 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 the Tenant".

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

Moreover, it focuses on permissions that allow access to the Microsoft Graph API and the legacy Azure AD Graph API.

This IoE tracks the following dangerous permissions:

  • AdministrativeUnit.ReadWrite.All: Allows attackers to remove a Global Administrator from a Restricted Management Administrative Unit (RMAU) to then reset their password if combined with other permissions.
  • Application.ReadWrite.All: Allows attackers to inject authentication credentials into more privileged applications, enabling unauthorized access up to Global Administrator through impersonation.
  • Application.ReadWrite.OwnedBy: This is the same as Application.ReadWrite.All, but it applies only to service principals owned by the reported service principal.
  • AppRoleAssignment.ReadWrite.All: Allows attackers to grant themselves the RoleManagement.ReadWrite.Directory permission.
  • DeviceManagementConfiguration.ReadWrite.All: Allows attackers to compromise Intune-managed devices by deploying malicious management scripts, as described by Mandiant in (In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments. This can allow privilege escalation to Global Administrator if an administrator uses an Intune-managed device.
  • DeviceManagementRBAC.ReadWrite.All: Allows attackers to assign privileged Intune roles to an account they control, enabling them to execute arbitrary commands on Intune devices, as described in DeviceManagementConfiguration.ReadWrite.All.
  • Directory.ReadWrite.All: Allows attackers to add themselves as members of non-role-assignable groups, potentially gaining privileges in the Azure cloud. This can enable them to pivot through Azure resources, which may lead to privilege escalation to Global Administrator in Entra ID (e.g., via managed identities) or even Domain Admins in Active Directory (e.g., through domain controller VMs hosted in Azure).
  • EntitlementManagement.ReadWrite.All: Allows attackers to update the assignment policy of an access package that grants the Global Administrator role, enabling them to request the role without approval.
  • Group.ReadWrite.All: Same as Directory.ReadWrite.All
  • GroupMember.ReadWrite.All: Same as Directory.ReadWrite.All
  • Organization.ReadWrite.All: Allows attackers to add a trusted root certificate to Entra ID and authenticate as any user, including those assigned to Global Administrator. This requires either Certificate-Based Authentication (CBA) to be enabled, or if it's not enabled, the Policy.ReadWrite.AuthenticationMethod permission to enable CBA beforehand.
  • Policy.ReadWrite.AuthenticationMethod: Allows attackers to enable the Temporary Access Pass (TAP) authentication method, which is a prerequisite to exploit the UserAuthenticationMethod.ReadWrite.All permission when combined with this one. Alternatively, it allows attackers to enable Certificate-Based Authentication (CBA) to exploit the Organization.ReadWrite.All permission.
  • Policy.ReadWrite.PermissionGrant: Allows attackers to create a permission grant policy for a controlled service principal, granting the RoleManagement.ReadWrite.Directory permission and enabling exploitation.
  • PrivilegedAccess.ReadWrite.AzureADGroup: Allows attackers to add a controlled user account as a member of a group assigned to the Global Administrator role.
  • PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup: Same as PrivilegedAccess.ReadWrite.AzureADGroup.
  • PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup: Allows attackers to make a controlled user account eligible for a group assigned to the Global Administrator role and then activate the membership to escalate privileges.
  • RoleAssignmentSchedule.ReadWrite.Directory: Allows attackers to assign the Global Administrator role to a controlled user account by creating an active PIM role assignment.
  • RoleEligibilitySchedule.ReadWrite.Directory: Allows attackers to make a controlled user account eligible for the Global Administrator role and then activate it to escalate privileges.
  • RoleManagement.ReadWrite.Directory: Allows attackers to elevate themselves to the Global Administrator role.
  • RoleManagementPolicy.ReadWrite.AzureADGroup: Allows attackers to remove group role assignments and activation constraints, such as MFA requirements or admin approval, to leverage PrivilegedAccess.ReadWrite.AzureADGroup, PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup, or PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup, and follow the same path as those permissions in a tenant with strict PIM settings.
  • RoleManagementPolicy.ReadWrite.Directory: Allows attackers to remove Entra role assignment and activation constraints such as MFA requirements or administrator approval to leverage RoleAssignmentSchedule.ReadWrite.Directory or RoleEligibilitySchedule.ReadWrite.Directory, and follow the same path as those permissions in a tenant with strict PIM settings.
  • User.DeleteRestore.All: Allows attackers to delete all user accounts in the tenant, rendering it unavailable, and then demand a ransom to restore one of the break-glass accounts. While it does not allow escalation to Global Administrator, it disrupts access.
  • User.EnableDisableAccount.All: Allows attackers to disable all user accounts in the tenant, rendering it unavailable, and then demand a ransom to restore one of the break-glass accounts. While it does not allow escalation to Global Administrator, it disrupts access.
  • User.ReadWrite.All: Allows attackers to edit sensitive properties of a controlled user account, such as "Employee ID" and "Department", to make it a member of a dynamic group (see corresponding IoE) with assigned privileged Azure permissions. They can then leverage Azure resources to eventually escalate to Global Administrator.
  • User-PasswordProfile.ReadWrite.All: Same as Directory.ReadWrite.All
  • UserAuthenticationMethod.ReadWrite.All: Allows attackers to generate a Temporary Access Pass (TAP) and take over any user account in the tenant. If TAP is not already enabled, they must combine this with Policy.ReadWrite.AuthenticationMethod to enable TAP as an authentication method in the tenant (see corresponding IoE).

Legitimate applications with these dangerous 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:

Solution

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 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, challenge the vendor to lower the required permission(s) or at least to document the reason they are necessary.
    • 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 tenant-wide 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.

Specifically for the DeviceManagementConfiguration.ReadWrite.All permission, you can use access policies to require multiple administrative approvals. This approach ensures that the creation or modification of management scripts requires validation by another account, reducing the risk of a single application introducing malicious changes.

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.

Indicator Details

Name: Dangerous Application Permissions Affecting the Tenant

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

Severity: High

Type: Microsoft Entra ID Indicator of Exposure

MITRE ATT&CK Information: