AZ_ASSIGNED_MANAGED_IDENTITY

Copy page

Summary


Forestall ACL Alias	AZ_ASSIGNED_MANAGED_IDENTITY
Azure Alias	Assigned Managed Identity
Affected Object Types	Azure resources with assigned managed identities -> Service Principal (Managed Identity)
Edge Direction	Azure Resource -> Managed Identity Service Principal
Exploitation Certainty	Certain
Exploitation Preconditions	Requires a separate edge that gives control of the Azure resource runtime or workflow.

Description

AZ_ASSIGNED_MANAGED_IDENTITY represents the relationship where an Azure resource has an assigned managed identity (system-assigned or user-assigned). The managed identity is backed by a Service Principal in Microsoft Entra ID, and the Azure resource authenticates as that Service Principal.

There are two types of managed identities:

System-assigned managed identity (SMI) - Created automatically when enabled on the resource. Its lifecycle is tied to the resource; deleting the resource deletes the identity. The service principal name matches the resource name.
User-assigned managed identity (UMI) - Created as a standalone Azure resource and explicitly assigned to one or more Azure resources. Its lifecycle is independent of the resources it is assigned to.

This edge is critical for attack paths because:

This edge does not grant execution by itself; it connects a controlled Azure resource to the managed identity Service Principal it can authenticate as.
If another edge gives control of the resource runtime, the resulting impact is determined by the managed identity’s downstream permissions.
Managed identities are frequently over-provisioned with permissions such as Contributor, Owner, or broad Microsoft Graph API roles.

Identification

Identify this edge by finding Azure resources with a populated identity block. System-assigned identities expose a principalId directly on the resource. User-assigned identities appear as resource IDs under userAssignedIdentities; resolve those IDs to the corresponding user-assigned managed identity resource to get its Service Principal object.

PowerShell (Az Module)

Connect-AzAccount

# List all ARM resources with an identity block
Get-AzResource -ExpandProperties |
    Where-Object { $_.Identity -and $_.Identity.Type } |
    Select-Object Name, ResourceGroupName, ResourceType, ResourceId,
        @{N='IdentityType';E={$_.Identity.Type}},
        @{N='PrincipalId';E={$_.Identity.PrincipalId}},
        @{N='UserAssignedIdentityIds';E={
            if ($_.Identity.UserAssignedIdentities) {
                ($_.Identity.UserAssignedIdentities.PSObject.Properties.Name -join ', ')
            }
        }} |
    Format-Table -AutoSize

# Resolve user-assigned managed identity resources
Get-AzUserAssignedIdentity |
    Select-Object Name, ResourceGroupName, Location, ClientId, PrincipalId, Id |
    Format-Table -AutoSize

Azure CLI

# List all ARM resources with an identity block
az resource list \
  --query "[?identity != null].{Name:name, Type:type, RG:resourceGroup, IdentityType:identity.type, PrincipalId:identity.principalId, UserAssignedIdentities:identity.userAssignedIdentities}" \
  -o table

# Resolve user-assigned managed identity resources
az identity list \
  --query "[].{Name:name, RG:resourceGroup, ClientId:clientId, PrincipalId:principalId, Id:id}" \
  -o table

Exploitation

Edge Chaining

AZ_ASSIGNED_MANAGED_IDENTITY is a bridge edge, not a standalone exploitation primitive. Read it as:

A resource-control edge reaches the Azure resource.
This edge maps that resource to its managed identity Service Principal.
Downstream permission edges determine what that Service Principal can access.

Common Inbound Edges

These edges contain the resource-side exploitation details and should reference this edge when the target resource has a managed identity:

Edge	How it connects to this edge
AZ_EXECUTE_COMMAND	Command execution on VMs, VMSS, AKS, App Services, and Function Apps can become access as the resource identity.
AZ_RDP	RDP access to Windows VMs can reach a VM’s assigned managed identity when the VM is configured for Entra login.
AZ_SSH	SSH access to Linux VMs can reach a VM’s assigned managed identity when the VM is configured for Entra login.
AZ_VM_ADMIN_LOGIN	Administrator login is the broad VM login edge that fans out to RDP or SSH and depends on the VM’s system-assigned managed identity.
AZ_SQL_ADMIN	SQL admin control can pair with a SQL Server managed identity when the server identity has useful downstream permissions.
AZ_AUTOMATION_CONTRIBUTOR	Runbooks execute as the Automation Account identity or Run As account.
AZ_LOGIC_APP_CONTRIBUTOR	Logic App workflow control can execute actions using the Logic App managed identity.
AZ_WEBSITE_CONTRIBUTOR	App Service and Function App control can reach the app’s managed identity through deployment, SSH, Kudu, or code execution paths.
AZ_LIST_CLUSTER_ADMIN_CREDENTIALS	AKS cluster-admin access can reach node or kubelet managed identity paths.

Common Outbound Edges

After the graph reaches the managed identity Service Principal, evaluate the same privilege edges used for any other Service Principal:

Edge	What to evaluate
AZ_HAS_ARM_ROLE	Whether the managed identity holds an Azure RBAC role.
AZ_ARM_ROLE_SCOPED_TO	The subscription, resource group, or resource scope where that RBAC role applies.
AZ_ARM_OWNER	Owner impact, including role assignment capability.
AZ_CONTRIBUTOR	Broad resource-management impact without role assignment capability.
AZ_VM_CONTRIBUTOR	VM-specific control that can loop back into execution paths.
AZ_KEY_VAULT_CONTRIBUTOR	Key Vault management-plane control that may enable data-plane access.
AZ_GET_SECRETS, AZ_GET_KEYS, AZ_GET_CERTIFICATES	Direct Key Vault data-plane permissions.
AZ_MG_DANGEROUS_PERMISSION	High-risk Microsoft Graph application permissions assigned to the managed identity Service Principal.
AZ_IN_GROUP	Group membership that may grant inherited ARM, directory, or application privileges.

Mitigation

Apply least-privilege to managed identities
- Audit permissions assigned to all managed identity service principals.
- Remove unnecessary Azure RBAC roles and Microsoft Graph permissions.
Use user-assigned managed identities deliberately
- UMIs can be centrally managed and audited, but shared high-privilege UMIs increase blast radius.
- Prefer workload-specific UMIs where lifecycle and auditability matter.
- Avoid assigning one broad UMI to many unrelated resources.
Restrict code execution on resources
- Limit who can run commands on VMs (restrict VM Contributor, Contributor, Owner roles).
- Limit SQL admin access to trusted principals only.
Monitor managed identity sign-in activity
- Review Microsoft Entra sign-in logs for managed identity service principals.
Disable managed identities when not needed
- If a resource does not require a managed identity, do not enable one.

Detection

Use the Azure Portal and Microsoft Entra admin center:

Open Microsoft Entra ID -> Sign-in logs.
Filter for service principal sign-ins where the service principal type is Managed Identity.
Review Service principal, Resource, IP address, Date, and Status for unexpected managed identity usage.
In Azure Portal, open Monitor -> Activity log and filter for operations initiated by the managed identity service principal.
Open the target resource and review Identity, Access control (IAM), and related access settings to confirm the managed identity is expected.

Ask AI