How Azure Managed Identity Abuse Enables Privilege Escalation Without Credentials

You already know that Azure Managed Identities eliminate the need to store credentials in your code. But that convenience creates a blind spot most teams never address. If an attacker gains execution on your VM or App Service, they don't need passwords; they just ask the instance metadata endpoint for a token. What happens next depends entirely on how much trust you've handed that identity.

Azure Managed Identity Abuse: How Attackers Escalate Without Passwords

When an attacker obtains command execution on an Azure VM or App Service instance, they don't need passwords or secrets to escalate privileges.

They can instead use the Managed Identity that the workload is already allowed to access.

From a VM, they can query the local Instance Metadata Service (IMDS) at http://169.254.169.254/metadata/identity/oauth2/token, including a Metadata: true header and a resource parameter.

This returns an OAuth2 bearer token that can be used to authenticate to Azure Resource Manager.

If the Managed Identity is assigned high-privilege roles, such as Contributor or Owner at the subscription or resource group scope, the attacker can leverage this token to modify access control in Azure.

For example, they can create new role assignments, add new identities with broad permissions, or alter existing role definitions.

In this way, control over the Managed Identity token can translate directly into control over Azure resources, even though no traditional credentials are exposed. Left unchecked, this exact escalation path is the kind of thing a dedicated azure pen testing service is built to surface before an attacker finds it, chaining findings like an over-privileged managed identity into a demonstrated privilege escalation path rather than a theoretical checkbox.

How Azure Managed Identities Authenticate Without Credentials

Unlike traditional service principals that rely on stored client secrets or certificates, Azure Managed Identities use a platform-managed trust relationship between the compute resource (such as a virtual machine or App Service) and Microsoft Entra ID (formerly Azure AD).

When code runs on a resource with a managed identity enabled, it requests a token from a local, platform-provided endpoint. The request includes metadata (such as a secret header or token) that only the underlying Azure infrastructure can supply, demonstrating that the request originates from that specific host.

Microsoft Entra ID validates the request against the managed identity associated with the resource and, if it's valid, issues an OAuth 2.0 access token scoped to the requested resource (for example, Azure Key Vault or Azure Storage).

This process removes the need to store or manage credentials in application code or configuration. Token issuance is handled transparently by the platform, based on the established link between the Azure resource and its managed identity.

How Attackers Get Command Execution on Azure VMs

Gaining command execution on an Azure VM is the key prerequisite for abusing managed identity tokens, and attackers typically achieve this through several well-understood vectors.

Compromise of an application running on the VM, exploitation of unpatched vulnerabilities in the operating system or middleware, or the use of stolen credentials for RDP or PowerShell remoting can all provide the necessary level of access to query the Instance Metadata Service (IMDS).

In addition, adversaries may abuse Azure control-plane permissions such as Microsoft.Compute/virtualMachines/runCommand/action to run commands on a VM without needing direct interactive access.

Other techniques include injecting SSH keys or using Azure sign-in mechanisms that grant shell access to the VM.

Regardless of the specific path, once an attacker can execute commands on the VM, IMDS and its associated managed identity tokens become directly accessible from within the guest environment.

Stealing Azure Managed Identity Tokens From IMDS

Once an attacker has obtained command execution on a virtual machine, the Azure Instance Metadata Service (IMDS) at http://169.254.169.254/ becomes an important target.

IMDS can be queried using the Metadata: true header and a resource=https://management.azure.com/ parameter.

In response, it returns an access token (bearer token) associated with the VM's managed identity and scoped for Azure Resource Manager (ARM), without requiring explicit credentials such as passwords or certificates.

This token can be used immediately against ARM endpoints, for example to list resource groups or interact with resources at the subscription level, depending on the permissions assigned.

The token represents the VM's managed identity, so any actions taken with it are constrained by that identity's role-based access control (RBAC) assignments.

If the managed identity has elevated roles such as Contributor or Owner at a broad scope (for instance, the subscription level), an attacker can leverage this to perform high-impact operations without needing direct access to user accounts or long-term secrets.

What Attackers Can Do With an RBAC-Privileged Managed Identity Token

With a managed identity token scoped to Azure Resource Manager, an attacker's actions are constrained by the RBAC permissions assigned to that identity. If the identity has broad roles such as Contributor or Owner at the subscription level, an attacker can use ARM REST APIs to enumerate resource groups, storage accounts, and other resources without needing separate credentials.

Where dataplane permissions are also granted, the impact increases; for example, storage blob access may allow reading or exfiltrating sensitive data. If the identity can modify role assignments, an attacker can grant additional permissions to themselves or to another controlled principal at wider scopes, potentially turning a single compromised token into subscription-level privilege escalation.

How App Service Managed Identities Extend the Same Attack Path

Azure App Service exposes a managed identity through an in-container MSI endpoint rather than using a service principal secret. If an attacker obtains command execution within the App Service instance, for example, via Kudu, they can read the IDENTITY_ENDPOINT and IDENTITY_HEADER values from environment variables.

Using these values, they can call the local MSI endpoint, obtain a JWT access token, and authenticate to Azure Resource Manager (ARM) without needing to extract traditional credentials.

The managed identity is treated by Azure as the application's own identity. Any role-based access control (RBAC) assignments granted to that managed identity are therefore available to whoever controls the compromised app.

If the managed identity holds highly privileged roles, such as Contributor or Owner at the subscription or resource group level, compromising a single App Service instance can lead to broad privilege escalation across the affected scope.

Azure Managed Identity Abuse Paths From Real Customer Environments

Real customer environments show a recurring escalation pattern involving Azure Managed Identities. An attacker first gains command execution on an App Service or virtual machine and then reads IDENTITY_ENDPOINT and IDENTITY_HEADER from the environment.

These values are used to request an OAuth token that Azure Resource Manager accepts without requiring user credentials. The token then serves as the primary mechanism for further actions.

With this token, the attacker can enumerate Azure resources and perform management operations according to the permissions granted to that managed identity. The most significant impact arises when the identity has overly broad RBAC assignments, such as Owner or Contributor at the subscription scope.

In such cases, compromise of a single workload can lead to extensive control over the entire subscription.

Across incidents, these multi-step abuse paths often originate from insufficient adherence to least-privilege principles during the initial configuration of managed identities and their role assignments.

Which Service Principal Role Assignments to Audit First

When reviewing Service Principal role assignments, begin with the highest‑risk Azure AD administrative roles: Global Administrator, Privileged Role Administrator, Privileged Authentication Administrator, and Partner Tier2 Support.

These roles represent significant identity takeover risk because they can modify critical directory settings, role assignments, or authentication policies.

Next, examine Microsoft Graph application permissions, with particular attention to RoleManagement.ReadWrite.Directory and AppRoleAssignment.ReadWrite.All.

These permissions allow non-user principals to modify directory roles and app role assignments, which can indirectly escalate privileges across the environment.

For any Service Principal that holds these roles or permissions, review:

• How it's used operationally and whether it has been involved in expanding RBAC access or modifying privileged accounts.
• Its explicit owners and their privilege levels, as owner compromise can lead to indirect elevation via the Service Principal.
• Both active and eligible assignments, including those managed through Privileged Identity Management (PIM), as eligible assignments can usually be activated and therefore pose comparable risk to permanent assignments.

How to Lock Down Azure Managed Identity Permissions

Locking down managed identity permissions begins with systematic enumeration. Identify all system-assigned and user-assigned managed identities associated with your virtual machines, App Service instances, and other compute resources.

For each identity, review RBAC role assignments and ensure they're scoped as narrowly as possible (for example, at the resource or resource-group level rather than the subscription level, when feasible).

Avoid assigning broad roles such as Owner or Contributor. These roles typically grant far more permissions than most workloads require and increase the blast radius in the event of a compromise.

Instead, assign the minimal set of data-plane permissions necessary for the workload. For example, grant write access to a single Storage container rather than to the entire Storage account.

Remove any role assignments that include roleAssignments/write or other highly privileged ARM actions, because they allow an attacker who controls the host to escalate privileges by modifying role assignments.

For identities that occasionally require elevated permissions, use Azure AD Privileged Identity Management (PIM) to make those assignments eligible and time-bound, reducing the window during which they can be misused.

Conclusion

You've seen how a single overprivileged managed identity can hand attackers everything they need without a single stolen password. Now it's time to act. Audit your role assignments, enforce least privilege, and monitor IMDS token requests before someone else does it for you. The attack path isn't theoretical, it's already being walked in real environments. Tighten your identity permissions today, or you're leaving the door wide open.