Independent analysis by NHI Mgmt GroupSource article: Unosecur, “IMDS Token Theft” (June 4, 2026)

TL;DR: Unosecur says attackers can abuse over-privileged Azure managed identities by gaining code execution on a single VM, then querying IMDS for a trusted OAuth token that carries the machine’s full cloud permissions without password or MFA prompts. The trust model, not a CVE, is the control failure.

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unosecur's blog post: Azure managed identity token abuse via IMDS turns one VM foothold into a trusted cloud token and broad control-plane access.

Why it matters: It matters because IAM and cloud teams need to treat workload identity trust, not just authentication flow, as a live attack surface for NHI governance.

👉 Read Unosecur's analysis of Azure managed identity token abuse and cloud trust failure

Context

Azure managed identity abuse is a cloud identity problem, not a software bug. Once an attacker gets code execution on a VM, the local Instance Metadata Service can return a trusted access token that inherits the machine’s permissions.

The governance gap is that many cloud programmes still treat managed identities as a benign automation layer rather than a high-value identity class. When those identities are broadly scoped, one compromised workload can become a control-plane bridge into storage, secrets, and additional VMs.

The article’s core claim is typical of cloud-heavy environments: the danger comes from over-privileged workload identity and weak monitoring, not from a named vulnerability.

Key questions

Q: What breaks when Azure managed identities are over-privileged?

A: Over-privileged managed identities turn a single VM compromise into trusted cloud access. Once an attacker can query IMDS, the returned token can be replayed against Azure APIs with the identity’s full RBAC scope. The break is in the entitlement model, because the token is legitimate even when the process using it is not.

Q: Why do over-scoped managed identities increase cloud blast radius?

A: Because the token inherits the identity’s permissions exactly as assigned. If the role scope includes control-plane actions or secrets access, one stolen token can change workloads, reach Key Vault, or pivot into more systems without needing another password or MFA challenge.

Q: What are the signs that IMDS-based token abuse is happening?

A: Watch for HTTP requests to 169.254.169.254 from unusual processes, managed identity sign-ins that immediately touch new resources, and API activity that follows VM execution events with no corresponding workload change. The strongest signal is correlation across host, identity, and resource logs.

Q: How should teams contain managed identity abuse after a compromise?

A: Isolate the affected VM, revoke excessive RBAC assignments tied to the managed identity, and rotate any secrets or tokens that identity could reach. Containment should focus on removing the identity’s authority, not only on cleaning the host, because the cloud token may already have been replayed elsewhere.

Technical breakdown

How IMDS turns local code execution into a trusted token

Azure Instance Metadata Service is a local endpoint that workloads on a VM can query to obtain identity metadata and tokens. If an attacker achieves code execution on that VM, IMDS does not distinguish a legitimate workload process from hostile code running in the same host context. The result is a bearer token issued under the managed identity assigned to that machine. Because bearer tokens authenticate by possession, the cloud control plane sees a trusted identity, not the attacker’s original entry vector. That is why this technique blends initial access, credential access, and legitimate-looking API use into one chain.

Practical implication: treat local metadata access as an identity boundary and restrict which processes can reach IMDS.

Why over-privileged managed identities expand the blast radius

Managed identities are only as safe as their assigned RBAC scope. If a VM identity has Contributor or broad data-plane rights, any stolen token inherits those permissions until it expires or is revoked. That makes the managed identity itself the privilege carrier, not the VM application. In practice, attackers can use the token for RunCommand on additional systems, access Key Vault secrets, or enumerate resources across subscriptions. The trust failure is structural: cloud services assume the token represents intended machine behaviour, while the machine may already be compromised.

Practical implication: map each managed identity to a minimal role set and remove convenience-based broad access assignments.

How detection has to correlate VM activity with workload identity behaviour

IMDS abuse is hard to spot if teams only watch identity sign-ins in isolation. Useful signals emerge when VM execution events, IMDS queries, and downstream Azure API activity are correlated. Unexpected requests to 169.254.169.254, unusual user agents, or a managed identity touching new resources after RunCommand are all stronger indicators than any single log line alone. This is a classic runtime identity problem: the abuse is legitimate enough at the token layer that only behavioural context reveals it. Without cross-signal monitoring, the compromise looks like ordinary workload behaviour.

Practical implication: build alerts around VM-to-IMDS-to-resource correlation rather than token issuance alone.

Threat narrative

Attacker objective: The attacker aims to turn one compromised VM into trusted cloud access that can modify workloads, extract secrets, and expand across the Azure environment.

  1. Entry begins with code execution on an Azure VM, commonly through RCE, SSRF, RunCommand abuse, or compromised admin access.
  2. Credential access occurs when the attacker queries the local IMDS endpoint and receives a managed identity OAuth token.
  3. Escalation and lateral movement follow when the attacker reuses that token for Azure API calls, RunCommand on additional VMs, or Key Vault access.
  4. Impact is cloud-wide control or data theft, with blast radius determined by how broadly the managed identity was scoped.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Azure managed identity abuse exposes a trust-model failure, not a software defect. The important question is not whether IMDS is vulnerable in the classic CVE sense, but whether cloud programmes have defined who may speak for a workload once code execution exists on the host. In this case, the managed identity becomes a standing trust grant to any process on the VM. The implication is that identity governance for workloads must be designed around host compromise, not just sign-in events.

Over-privileged workload identity is the real blast-radius control problem. When a managed identity can reach Key Vault, storage, or control-plane functions, token theft becomes environment expansion rather than isolated access. That makes the privilege model the decisive risk variable, not the token format itself. NHI governance has to account for where machine credentials can be replayed and what they can change once replayed.

IMDS abuse shows why least privilege must be enforced at issuance, not audited after the fact. The attacker receives a valid token through the same identity path that the workload uses, so post-event access review cannot explain away the compromise. This is a case where the identity is technically legitimate but operationally unsafe. Practitioners should treat this as a workload identity lifecycle issue, not just a detection gap.

Azure workload identity needs a stronger boundary between process trust and machine trust. A local process should not automatically inherit the machine’s cloud authority simply because it can reach a metadata endpoint. That assumption was tolerable when workloads were tightly controlled, but it breaks under compromised code paths and shared host conditions. The practitioner conclusion is to redesign cloud identity assumptions around runtime trust, not host possession alone.

From our research library:

What this signals

Azure workload identity governance now has to assume host compromise as a normal failure mode. The old model treated a VM as a trusted boundary and the managed identity as a convenient extension of that boundary. That assumption no longer holds once IMDS can turn local code execution into a valid cloud token, so programme owners should review where host possession still implies identity authority.

Identity blast radius is the concept that matters here. A managed identity with broad RBAC makes the token more dangerous than the original foothold because it expands the attacker’s options across control plane and data plane activity. Teams should prioritise the identities that can touch secrets, subscriptions, or additional VMs first, because those are the identities that can turn a single compromise into an estate event.

For practitioners

  • Enforce least-privilege RBAC on managed identities Remove Contributor and Owner by default and replace them with narrowly scoped Reader or data-plane roles only where the workload truly needs them.
  • Restrict and monitor IMDS access Track requests to 169.254.169.254 from unexpected processes, and alert when non-system services or unusual user agents query the metadata endpoint.
  • Correlate VM execution with identity behaviour Join Azure Activity Logs, AADManagedIdentitySignInLogs, and AzureDiagnostics so a VM execution event followed by IMDS use becomes a high-fidelity detection chain.
  • Limit privileged VM administration paths Restrict RunCommand and VM administrator access to named, audited principals so compromised access paths do not become identity acquisition paths.
  • Harden the initial foothold Patch hosted applications, reduce SSRF exposure, and use conditional access and JIT access where feasible to shrink the chance of VM compromise in the first place.

Key takeaways

  • Azure managed identity abuse shows that a trusted token can be the consequence of one compromised VM, even when no CVE exists.
  • The operational risk scales with how broadly the managed identity is scoped, not with the presence of MFA or password controls.
  • Defenders need least-privilege RBAC, IMDS monitoring, and host-to-identity correlation to limit blast radius.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-05 — Overprivileged NHIBroadly scoped managed identities are the article's core failure mode.
NHI-04 — Insecure AuthenticationIMDS turns local process reachability into authenticated cloud access.
NHI-01 — Improper OffboardingCompromised managed identities and exposed secrets must be revoked quickly after abuse.
Recommendation — Audit managed identity scopes and remove broad privileges that are not operationally required. Treat metadata-service access as an authentication boundary and restrict who can query it. Revoke and rotate managed identity access paths immediately after compromise or excessive exposure.
NIST SP 800-53 Rev 5IA-9 — Service Identification and AuthenticationManaged identities are service-to-service authenticators in Azure workloads.
Recommendation — Apply IA-9 to govern how workloads authenticate and prevent implicit trust in host-local token issuance.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about entitlements on machine identities and their blast radius.
Recommendation — Review entitlements on managed identities and reduce permissions to the minimum operational scope.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe attack chain pivots from token theft to cross-resource movement and control-plane abuse.
Recommendation — Map IMDS abuse to credential-access and lateral-movement detections in your cloud monitoring.

Key terms

  • Managed Identity: A cloud-provider-managed identity assigned to a compute resource, allowing it to authenticate to cloud services without storing credentials in application code.
  • Instance Metadata Service: Instance Metadata Service, or IMDS, is a local endpoint that exposes instance information and, in Azure, can mint tokens for attached managed identities. It is designed for trusted workloads on the host, so compromise of the machine can become compromise of the identity if access is not tightly controlled.
  • Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
  • Runtime Identity Verification: Runtime identity verification is the process of proving a workload's identity at the moment access is requested rather than trusting a pre-stored secret. It ties access decisions to the current workload instance, which is more suitable for ephemeral services and short-lived sessions.

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 attack path showing how IMDS token theft follows code execution on an Azure VM
  • Example Azure log sources and correlation points for detecting managed identity abuse
  • Immediate containment steps for revoking over-broad RBAC and rotating affected secrets
  • A deeper breakdown of how RunCommand, Key Vault access, and subscription-wide compromise connect in practice

👉 Unosecur's full post covers the Azure IMDS attack chain, detection signals, and mitigation guidance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org