Azure Managed Identity Security: Attack Paths, IMDS Abuse, and How to Harden Your Configuration

The IMDS token request is a simple HTTP GET from within the Azure resource: curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/' -H 'Metadata: true'. This returns a JSON object containing an access_token valid for 1 hour and a refresh_token that can be used to obtain new access tokens. The resource parameter specifies which Azure service the token is for -- common targets: Azure Resource Manager (management.azure.com), Azure Key Vault (vault.azure.net), Microsoft Graph (graph.microsoft.com), Azure Storage (storage.azure.com). An attacker with code execution on the VM runs this curl command (or equivalent Python/PowerShell), obtains a token, and uses it to: list all resources in the subscription (az resource list), access Key Vault secrets (az keyvault secret list), read Storage account data, or modify Azure resources if the managed identity has Contributor or above. Server-Side Request Forgery (SSRF) vulnerabilities in web applications are particularly dangerous on Azure VMs with managed identities -- the SSRF can be used to exfiltrate IMDS tokens without requiring OS-level code execution.

Audit all managed identity role assignments for excessive permissions. PowerShell / Azure CLI: Get-AzRoleAssignment | Where-Object { $.ObjectType -eq 'ServicePrincipal' } | Where-Object { $.RoleDefinitionName -in ('Owner', 'Contributor', 'User Access Administrator') } | Select-Object DisplayName, RoleDefinitionName, Scope. Review each result: is the managed identity justified in having Contributor on a subscription (rather than Contributor on a specific resource group)? Does a web application's managed identity need to write to Azure Resource Manager, or only read from a specific Storage account? Common overprivileged findings: App Service managed identities with Key Vault access set to subscription-wide instead of the specific Key Vault. VM managed identities assigned Contributor at the subscription level for a single-purpose automation task. Azure Functions with Reader access to all resources when they only need to read from specific tables. Use Microsoft Defender for Cloud's identity recommendations to surface managed identities with excessive permissions.

Replace broad role assignments with narrow, scoped ones. Guiding principles: scope at the resource level, not the subscription level (assign Key Vault Secrets User on the specific Key Vault, not Contributor on the subscription). Use built-in roles with minimum permissions rather than Contributor: Storage Blob Data Reader instead of Storage Account Contributor, Key Vault Secrets User instead of Key Vault Contributor, Cosmos DB Account Reader instead of Contributor. For custom permissions: create custom RBAC roles that include only the specific actions required. Example: if the managed identity only needs to read blobs from one container, create a custom role with Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read on that specific container path. Remediate overprivileged assignments: remove the overprivileged role assignment and add the narrowly scoped one. Test the application or service after the change to confirm it still functions with the reduced permissions.

On VMs that run workloads from multiple tenants or multiple trust levels (shared development environments, multi-application VMs), restrict access to the IMDS endpoint via local firewall rules. The IMDS endpoint 169.254.169.254 is accessible to all processes running on the VM by default. Use Windows Firewall or Linux iptables to restrict IMDS access to specific processes or users if you cannot isolate workloads to separate VMs. For VMs running containerized workloads: in Kubernetes (AKS), use pod identity or Workload Identity (Microsoft Entra Workload Identity) which assigns managed identities at the pod level rather than the node level -- this prevents a compromised pod from accessing the node-level managed identity. For VMs where all workloads are trusted: use IMDSv2 by enforcing that all IMDS requests include a session header (Azure IMDS API version 2019-08-01 and later supports session tokens) to prevent simple SSRF-based token theft -- IMDSv2 requires a PUT request to get a session token before making GET requests, which SSRF attacks typically cannot perform.

Managed identity token usage appears in Azure Activity Logs and Microsoft Entra ID sign-in logs (under Managed Identity sign-ins). Suspicious patterns: a managed identity accessing resources it has never accessed before (new resource type in audit logs -- Key Vault access by a VM identity that previously only accessed Storage). Managed identity tokens used from IP addresses outside the Azure IP range (169.254.x.x is local; external IP address using a managed identity token indicates the token was exfiltrated). Unusually high volume of Key Vault secret reads from a managed identity. Lateral movement pattern: a sequence of Resource Manager list operations followed by new resource access (reconnaissance followed by exploitation). KQL in Sentinel: MicrosoftAzureActivity | where CategoryValue == 'Administrative' and Caller endswith '@managedidentity' and OperationNameValue contains 'secret' | project TimeGenerated, Caller, OperationNameValue, ResourceGroup, Resource. Alert on unusual Resource Manager API calls from managed identities -- specifically CreateOrUpdate, Delete, and roleAssignments/write from managed identities that do not normally perform these operations.