Dangerous Delegated 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 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: see the related Indicator of Exposure "Dangerous Application Permissions Affecting the Tenant".

• Delegated permissions: this Indicator of Exposure examines this second type. 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.

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: Same as Application.ReadWrite.All but it applies only to service principals owned by the reported service principal. Note that it is not typically available as a delegated permission.
• 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:

• Andy Robbins - Azure Privilege Escalation via Azure API Permissions Abuse
• Andy Robbins - Directory.ReadWrite.All Is Not As Powerful As You Might Think
• Carsten Sandker - Untangling Azure Active Directory Permissions II: Privileged Access
• Dirk-jan Mollema - Azure AD privilege escalation - Taking over default application permissions as Application Admin
• Emilien Socchi - Tier 0 permissions (refer to it for further details including exploitability justifications)
• Huy Kha - Everything about Service Principals, Applications, and API Permissions
• Lina Lau - How to Backdoor Azure Applications and Abuse Service Principals
• Mandiant Red Team - (In)tuned to Takeovers: Abusing Intune Permissions for Lateral Movement and Privilege Escalation in Entra ID Native Environments
• Marius Solbakken Mellum - Surprising ways to escalate privileges in Entra ID
• Sahil Malik - How to grant admin consent to an API programmatically
• Stian A. Strysse - What's lurking in your Microsoft Graph app role assignments?

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.

• 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. 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.

Name: Dangerous Delegated Permissions Affecting the Tenant

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

Severity: High

Type: Microsoft Entra ID Indicator of Exposure