Notifications
Clear all
Topic starter
24/06/2026 6:50 pm
TL;DR: Azure Managed Identity abuse through IMDS lets an attacker with code execution on a single VM obtain a trusted OAuth token and move laterally with the machine’s full cloud permissions, according to Unosecur. The core failure is not a CVE but an over-privileged trust model that IAM and cloud teams must treat as an identity risk.
NHIMG editorial — based on content published by Unosecur: Managed Identity Token Abuse via Azure IMDS
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: What breaks when Azure managed identities are over-privileged?
A: Over-privileged managed identities turn a single VM compromise into trusted cloud access.
Q: Why do managed identities increase lateral movement risk in Azure?
A: Managed identities increase lateral movement risk when they are granted permissions beyond the workload’s narrow purpose.
Q: How do security teams know if IMDS abuse is happening?
A: Look for requests to the metadata endpoint from unusual processes, followed by Azure activity that does not match the workload’s normal behaviour.
Practitioner guidance
- Constrain managed identities to workload-specific RBAC Remove broad Contributor and Owner assignments from Azure managed identities and replace them with the narrowest data-plane or Reader permissions the workload actually needs.
- Correlate VM execution with IMDS token activity Alert when a VM process reaches 169.254.169.254/metadata/identity and then uses the resulting identity across new Azure resources, especially Key Vault or RunCommand.
- Restrict local code execution paths on Azure VMs Patch RCE-prone applications, reduce SSRF exposure, and tightly control RunCommand and administrator access so attackers never reach the metadata endpoint from the host.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- A step-by-step view of the Azure IMDS token abuse sequence from VM foothold to replayed bearer token
- Specific Azure log sources and correlation patterns for spotting suspicious metadata access
- Mitigation guidance for tightening RBAC, restricting RunCommand, and reducing SSRF exposure
- Examples of how the attack expands into Key Vault access and broader control-plane abuse
👉 Read Unosecur's analysis of Azure managed identity token abuse via IMDS →
Azure managed identity abuse: where do cloud controls break down?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 3:49 am
Managed identity trust was designed for a benign local process, and that assumption fails when the VM becomes attacker-controlled. IMDS treats local execution as sufficient proof of legitimacy, but that model collapses once an attacker can run code on the host. The implication is not just harder monitoring, but a rethink of what the workload boundary actually means in cloud IAM.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable when a managed identity is abused?
A: Accountability usually sits with the cloud and identity teams together. Platform owners control how the VM and metadata service are exposed, while IAM teams control RBAC scope and lifecycle review. If the identity can act beyond its workload’s purpose, the failure is governance, not just detection.
👉 Read our full editorial: Azure managed identity token abuse exposes trust-model failure
