Privilege escalation in Microsoft Entra ID (formerly Azure AD) is one of the most consistently underestimated attack paths in hybrid cloud environments. Security teams usually have a clear picture of who holds the Global Administrator role. What they often miss is that several seemingly minor roles can be chained together to reach that same level of access in just a few steps — no exploits required, just legitimate API calls.
Why Entra ID is a natural target for privilege escalation
Entra ID ships with over a hundred built-in roles. The instinct to distribute them generously — because they seem specialized — is understandable, but dangerous. Microsoft's permission model relies on nested delegations, and some roles expose very powerful primitives: adding credentials to applications, resetting MFA methods, managing authentication policies. None of that is obvious from the role name alone.
The result is that an attacker who compromises a mid-tier account often has a direct stepping stone toward full tenant control, without ever touching a vulnerability.
The most exploitable escalation paths
Application Administrator: a backdoor into any Service Principal
The Application Administrator role allows adding credentials — secrets or certificates — to any registered application in the tenant, including those with privileged Microsoft Graph permissions such as RoleManagement.ReadWrite.Directory. If an existing application already holds that kind of granted permission, an attacker with this role can add a new secret, authenticate as the application's Service Principal, and call the Graph API to assign themselves the Global Administrator role.
The chain is short: Application Administrator → add credentials to a privileged app → API call → Global Admin. No exploit, no vulnerability, just delegated trust being abused.
Helpdesk Administrator: MFA reset as an account takeover vector
Helpdesk Administrator can reset authentication methods for users who are not Global Administrators. The attack targets an account holding a higher role — say, Privileged Role Administrator or Authentication Administrator — resets its MFA registration, then hijacks the session. The constraint is that the target cannot be a Global Admin, but there are plenty of high-value roles below that threshold that still represent significant blast radius.
Combining two roles to cross barriers
Some escalation paths require stacking two apparently harmless roles. An account holding both Application Administrator and Cloud Application Administrator can, depending on tenant configuration, reach permissions neither role would grant alone. Similarly, a Groups Administrator who can add themselves to groups assigned to elevated roles creates an indirect path to privilege escalation. This graph-of-permissions logic is exactly what BloodHound for Azure is built to model.
Audit methodology with AzureHound and BloodHound
Data collection with AzureHound
AzureHound is the dedicated collector for Entra ID and Azure resources. It authenticates via a Service Principal or user account and enumerates tenant entities: users, groups, roles, applications, Service Principals, and the relationships between them. A basic collection command looks like this:
azurehound -u [email protected] -p PASSWORD list --tenant <TENANT_ID> -o output.json
Best practice is to use a read-only account with the minimum necessary permissions (Directory.Read.All at the Graph level) to keep the audit footprint small. The output is a JSON file that imports directly into BloodHound.
Path analysis in BloodHound
Once the data is ingested, BloodHound Community Edition or the Enterprise version lets you run Cypher queries to surface escalation paths. A few particularly useful ones:
- Find all principals with a path to Global Administrator:
MATCH p=shortestPath((n)-[*1..]->(m:AZRole {name:'Global Administrator'})) RETURN p - List applications with sensitive Graph permissions where an Application Administrator could add credentials.
- Identify accounts without MFA that a Helpdesk Administrator could target.
The graph interface lets you visualize those paths, rank them by length and criticality, and generate findings that remediation teams can act on. To practice these techniques in a safe, reproducible environment, the Entra ID lab catalog on CyberAct provides hands-on scenarios built around real attack chains.
Concrete remediation steps
An audit only matters if it drives action. The priorities worth focusing on first:
- Enable Privileged Identity Management (PIM) for all sensitive roles, including Application Administrator and Helpdesk Administrator. Just-in-time activation with justification and time limits dramatically shrinks the permanent attack surface.
- Audit all registered applications with elevated Graph permissions on a regular basis. Any application holding
RoleManagement.ReadWrite.DirectoryorAppRoleAssignment.ReadWrite.Allshould be treated as a critical asset. - Use Conditional Access Policies targeting Service Principals to restrict credential addition to applications.
- Deploy Microsoft Sentinel or Defender for Cloud Apps alerts on credential addition events and authentication method resets that fall outside normal IT workflows.
It is also worth maintaining a static map of which roles can act on which other roles — kept current with every directory change, and used as a reference during access reviews. If you want to benchmark your current Entra ID posture before diving into remediation, a structured cyber diagnostic gives you a clear starting point.
Frequently asked questions
Can an Application Administrator really reach Global Administrator without exploiting any vulnerability?
Yes, in many default configurations. If a tenant application already holds privileged Graph permissions and no policy restricts credential additions, the escalation is achievable through legitimate API calls alone. No software vulnerability is needed — only delegated trust being misused.
What is the practical difference between Application Administrator and Cloud Application Administrator in Entra ID?
Application Administrator manages all applications, including those synchronized from an on-premises Active Directory. Cloud Application Administrator is scoped to cloud-only applications. The distinction sounds meaningful, but the escalation paths through Service Principals remain largely the same — it is not a meaningful security boundary on its own.
Does AzureHound require elevated permissions to run an audit?
No. AzureHound works with a read-only account that holds Directory.Read.All on the Graph API. The recommended approach is to create a dedicated Service Principal for the audit, with a short credential lifetime and audit logging enabled throughout the collection window.
Is PIM enough to block these escalation paths?
PIM significantly reduces risk by limiting how long roles remain active. But it does not eliminate the paths: an attacker who compromises a PIM-eligible account can still attempt to activate the role if approval workflows are not properly enforced. PIM needs to be paired with alerting on activation events and regular access reviews to be effective.