What do you call a scenario where nothing is broken, yet everything is exposed? A bug, an abuse, or a misconfiguration. The answer depends on perspective.
It started the way most breaches do, with an Azure VM, RDP open to the internet, and a password someone meant to change. What happened next is what makes this different. One curl command, and the attacker had
the keys to the Key Vault, the domain controller, the SIEM, and the AI infrastructure. No exploits. No
zero-days. Just the platform is working exactly as designed.
Every Azure Virtual Machine ships with a silent backdoor baked into the platform itself.
The Azure Instance Metadata Service (IMDS) is available at 169.254.169.254 on every VM and issues OAuth 2.0 bearer tokens to any process that requests them. One unauthenticated HTTP request returns a token that can rip through an entire Azure subscription, enumerate every resource, drain every secret from Key Vault, execute shell commands on remote VMs, and pull Active Directory password hashes from a domain controller disk snapshot without ever touching the live VM.
We traced the kill chain from a single curl to full domain compromise in under 40 minutes, generating exactly three detectable log entries along the way.
This paper documents distinct IMDS token audiences that attackers can weaponize from a single endpoint, the real-world blast radius of common RBAC misconfigurations, six privilege escalation paths from ARM token to Global Admin, and a novel finding that shatters assumptions both red and blue teams make about directory roles in Managed Identity tokens. Every finding is backed by live API responses. No simulations. No “in theory.” Just raw evidence from the wire.
This article blends research with a real attack scenario with an Attack Story.
It started with an exposed Azure VM with an easy foothold. After gaining access, I began exploring the system to understand what I had landed on. Pretty quickly, I noticed the Instance Metadata Service (IMDS) was accessible, and that changed everything. With the VM’s assigned permissions, I could query IMDS and start pulling credentials, turning a simple initial access into a much broader opportunity to move through the environment.
Note: The screenshots and information were taken from a demo environment, not a real one.
From the Trenches
Here is the uncomfortable truth about Azure security: the thing protecting your VMs from credential theft is itself the biggest credential you own.
Microsoft designed Managed Identities to solve a real problem. VMs need to authenticate to cloud services. Storing secrets on disk is dangerous. So Microsoft built IMDS, a metadata service that mints OAuth tokens on demand, eliminating the need for stored credentials.
The problem is not that IMDS exists. Otherwise, the problem is that IMDS hands tokens to anything running on the VM. Any foothold on the VM, at any privilege level, is an instant gateway to the cloud and the token request itself? Completely invisible.
We set out to answer a simple question: how far can one curl command take you? The answer is terrifying.
Starting from a single Azure VM in a controlled lab environment with many resource groups and dozens of resources, we demonstrate a complete exploitation chain: infrastructure-wide reconnaissance, Key Vault secret extraction, remote code execution across multiple VMs, Active Directory domain compromise via offline disk analysis, and SIEM evasion by querying the organization’s own Sentinel workspace to learn what the defenders are watching.
This research makes three contributions that matter. First, we catalog IMDS token audiences and classify each by attack potential, creating the most comprehensive public reference available. Second, we demonstrate the actual blast radius of RBAC configurations that exist in virtually every Azure subscription. Third, we expose a critical disconnect between Entra ID directory roles and Microsoft Graph API permissions that both attackers and defenders consistently get wrong, a finding that changes how you should assess Managed Identity risk.
Tip: Azure VMs should have no permissions by default, without RBAC roles, because every role is a blast radius.
From Shodan to
Before the deep-dive sections, this is the attack told as a story, with the commands, the simplicity, the output, etc. This is the narrative an attacker would follow, step by step.
We know that Azure VMs become exposed to the network due to misconfigurations or weak access controls. In many cases, this exposure is not the result of a sophisticated exploit, but rather a combination of overlooked settings, permissive rules, or assumptions about network boundaries. That’s known for years and nothing new.
No Slack account needed.
The Discovery Phase Initial Access – Brute-Forcing RDP
The attacker opens Shodan or an equivalent tool and searches for exposed VMs. In Shodan, the query will be:
shodan search ‘org:”Microsoft Corporation” port:3389 “Remote Desktop Protocol” -“nla”‘
The “Open Front Door” (Direct Vulnerability)
asn:AS8075 port:3389 has_screenshot:true screenshot.label:login
This is the gold standard for finding disabled NLA. Because NLA forces authentication before a session starts, Shodan can only snap a screenshot if the login UI is served pre-auth. If you see a Windows background or a username field here, the machine is screaming for a brute-force or a pre-auth exploit.
The Metadata Leaker
asn:AS8075 “Remote Desktop Protocol” “NTLM Info”
This targets the NTLM SSP response. Even without a full exploit, this query pulls the internal Computer Name, Domain Name, and exact OS Build from the Azure VM. It’s basically a free network map of the target’s internal naming conventions without sending a single malicious packet.
The Legacy Pivot
asn:AS8075 port:3389 “Remote Desktop Protocol” -“CredSSP”
This filters for Azure RDP instances that are not using Credential Security Support Provider. By excluding “CredSSP” from the results, you find the “Legacy” configurations that are likely falling back to the insecure RDP Security Layer, making them prime targets for MitM attacks.
Initial Access – Login
This phase can be performed using known attack tools such as Hydra and Crowbar on the local user account within the Azure VM. Often, the password is weak, and the local user is a local admin on the specific Azure VM. The most interesting part is that some of the VMs are configured with Entra ID login and without the standard security.
Well, so far, that’s known for years. Also, that is the introduction; the juicy part starts now. Before jumping to the ARM Token, we should briefly cover the IMDS.
IMDS Architecture
How IMDS Works? In a short.
The Azure Instance Metadata Service (IMDS) is a REST API that provides essential data about a running Virtual Machine (VM) or Virtual Machine Scale Set (VMSS). Its architecture is designed to be highly secure, localized, and non-routable.
IMDS organizes data into several categories, “roots,” each serving a specific architectural purpose: instance, identity, attested, loadbalancer, and much more.
The Azure Instance Metadata Service runs on every Azure VM at the link-local address 169.254.169.254. It’s implemented at the hypervisor level on the Hyper-V host and is accessible to any process within the guest operating system. The service requires no authentication. The only requirement is the HTTP header Metadata: true, which serves as a minimal SSRF protection mechanism rather than an authentication control.
The token endpoint accepts a resource parameter that specifies which Azure service the token should be scoped to. This is the audience claim (aud) in the resulting JWT. The IMDS endpoint will issue a token for any valid audience URL, regardless of whether the Managed Identity has permissions on the target service. Authorization is enforced at the target service when the token is presented, not at the point of token issuance.
The token endpoint accepts a resource parameter that specifies which Azure service the token should be scoped to. This becomes the audience claim (aud) in the resulting JWT.
Critically, IMDS will issue a token for any valid audience URL, regardless of whether the Managed Identity has permissions on the target service. Authorization is enforced at the target service when the token is presented, not at the point of token issuance. This architectural decision means an attacker can silently enumerate which services are accessible by spraying token requests for known audiences and testing each against.
Token Request and Response
The fundamental token request takes the following form:
GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01 &resource=https://management.azure.com/
Each request against the VM returned a JWT with the following decoded payload:
Security Relevant Token Properties
Several inherent characteristics of tokens issued by IMDS transform them into high-impact offensive primitives in the hands of an attacker:
- No MFA. Managed Identities authenticate through certificate-based credentials managed by the Azure fabric. There is no mechanism to require multi-factor authentication.
- No Conditional Access. As of March 2026, Conditional Access policies for workload identities are in limited preview and not widely deployed. Most Managed Identity tokens bypass all Conditional Access controls.
- 24-hour lifetime. The token issued had an exp claim granting a full 24-hour validity window. During this period, the token cannot be individually revoked. The only remediation is to disable the Managed Identity entirely or delete its service principal.
- Invisible acquisition. The HTTP request to 169.254.169.254 is handled at the hypervisor level and never traverses the network. No logging captures the token request, and the only audit signal appears when the token is subsequently used against a target service.
- Full resource path leakage. The xms_mirid claim reveals the complete Azure resource hierarchy: subscription ID, resource group name, and VM name. An attacker who intercepts the token immediately knows the organizational structure.
Token Reconnaissance
I referred to it as an “IMDS token,” but in practice, IMDS can return multiple types of access tokens, depending on the target resource, whether for Azure Resource Manager (ARM), Microsoft Graph, or other services.
Resource Enumeration
The first action using an ARM token is to map the environment. Using the token from bounty1, we queried the Azure Resource Manager API to enumerate accessible resources.
The subscription query returned a single subscription on a specific tier with spending limits disabled. The resource group enumeration revealed distinct resource groups spanning multiple Azure regions:
This command pulls a temporary OAuth 2.0 access token directly from the Azure Instance Metadata Service, leveraging the VM’s managed identity. No credentials, no secrets, no friction—just a token minted on demand that can be used to authenticate and operate against other Azure resources.
In practice, this means instant, passwordless access to the control plane, fully aligned with whatever permissions the identity holds.
curl -H “Metadata: true” “http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/”
Note: This token can be used from any location, whether internal or external to the environment.
To fully weaponize token collection on an Azure VM, you can run imds-token-collector.ps1. This script systematically harvests every accessible token and related artifact exposed via IMDS, giving you a complete set of credentials that can be chained together and abused across the environment.
The impact can be significant, as everything depends on the Azure VM’s assigned permissions—whether through RBAC roles or other access configurations. With sufficient privileges, this token can quickly translate into broad exposure across the environment.
The Crown Jewels in This Token
A single JWT stolen from the Azure Instance Metadata Service contains everything an attacker needs to map an infrastructure, identify value targets, and plan the next steps.
Who Am I? The Identity Claims
Where Am I? Infrastructure Claims
What Can I Do? Access Claims
So, what is the best claim? Which ones could be used in the next step?
- xms_mirid – The Infrastructure Blueprint
- oid – The Master Key for Authorization
- aud – The Weapon Selector
- wids – The Privilege Signal
- xms_tcdt – The Maturity Estimator
Insight: The Azure admin and SecOps who provisioned this MI made dozens of decisions over weeks: which role to assign, which scope, which Key Vault policy, and whether to enable diagnostics. The attacker who steals the token can reverse all those decisions within 60 seconds by reading a few claims. The token is a
confession, and it tells the attacker exactly how much the defender invested in security and exactly where they cut corners.
Audience Catalog
This is the point where IMDS shifts from merely concerning to truly catastrophic once you realize it can mint tokens across an entire audience catalog.
What it is
A complete reference of every OAuth2 token audience that Azure’s Instance Metadata Service will mint on demand. Resource endpoints across service categories, from infrastructure management to patient health records, are all accessible through a single unauthenticated HTTP call at 169.254.169.254.
What it proves
One compromised VM is not one compromised VM. It is a token factory with 55 production lines, each manufacturing a key to a different kingdom for infrastructure, Vault for secrets, Graph for identity, Storage for data, OpenAI for AI, and much more.
How to use it
Run each command or the spray script from any Azure VM with a Managed Identity. Every audience that returns a token is an attack surface. Every token that works against its target API is an open door. The catalog maps each door to what lies behind it, so the attacker knows which to walk through first, and the defender knows which to lock.
Audience Surface
55 audiences, one endpoint, zero authentication, and each token unlocks a different kingdom. The attacker surface can be one or more.
IMDS does not validate intent, enforce permission checks at request time, or apply any meaningful rate limiting. It will issue a token for any requested audience, on demand, as quickly and as often as your HTTP client can make the call.
An attacker can spray various service audiences in a short time. Each token unlocks a different data plane: storage, databases, AI models, messaging queues, container registries, and much more.
The Root Cause
The default configuration assumes no assigned roles. A fresh Azure VM with a system-assigned Managed
Identity starts with zero RBAC assignments. In theory, the token from IMDS is useless, and it has an identity
but no permissions. The design is secure by default.
In practice, that default lasts about five minutes. Someone needs the VM to read from Key Vault or deploy resources, and, as we know, someone runs a Terraform module that assigns permissions, since the example in the docs uses the Contributor role.
The result is what you see in this screenshot below: Reader on the subscription. Contributor to a resource
group. Two settings. Two lines in a portal table. No warnings. No alerts. No indication that anything is
wrong. Those two settings are a complete attack chain.
Whether these roles were assigned manually by an admin who needed a quick fix, via Terraform because the
module default said Contributor, or through an ARM template copied from a Microsoft quickstart guide, the
result is the same. The Managed Identity token that IMDS hands out for free, with no authentication, no
MFA and no logging now carry the permissions to compromise your domain.
From the Trenches
Microsoft Graph
The IMDS token contained a Wids claim with the APP ID value, indicating that the Managed Identity holds the Global Reader Entra ID directory role. Global Reader is a powerful role that grants read access to all directory information: users, groups, applications, service principals, Conditional Access policies, audit logs, and virtually every configuration surface in the Entra ID portal.
Don’t assume that a token carrying a directory role claim will grant corresponding access to the Microsoft Graph API. This assumption is dead wrong for Managed Identities, and the consequences of this misunderstanding flow in both directions: attackers overestimate what they can do, and defenders overestimate what they need to worry about.
For interactive users (delegated tokens), the wids directory role is evaluated by the Graph API to determine access. A user with Global Reader can call /v1.0/users because Graph recognizes the directory role in the delegated authentication context.
For application tokens (Managed Identities, service principals), Graph requires explicit appRoleAssignment entries. These are the application-level permissions (e.g., User.Read.All, Directory.Read.All) that an administrator must grant to the service principal in the Entra ID portal. The wids claim is present in the token, but the Graph API does not evaluate it for application tokens.
IMDS mints tokens for any audience without authentication. A Graph token is always issued, but
whether it works depends entirely on explicit application permission grants on the managed identity’s
service principal. Directory roles in the Wids claim that even the Global Reader doesn’t grant Graph API access
for application tokens. In short, only appRoleAssignment entries matter.
Control Plane vs Data Plane
A critical concept in Azure exploitation is the distinction between the control plane and data plane. The ARM token (management.azure.com) operates exclusively on the control plane. It can manage resources (create, delete, configure) but cannot access the data within those resources.
Each Azure service has its own data-plane API with a separate token audience. An attacker must request a second token from IMDS, scoped to the target service’s audience, to access data. This creates a two-hop attack pattern: ARM tokens for reconnaissance and resource management, followed by service-specific tokens for data access.
Key Vault Data Plane
The ARM token can reveal that x.vault.azure.net existed and that MI has access policies. To actually read secrets, a separate token scoped to vault.azure.net is required for specific commands.
This distinction matters because the ARM listKeys action was blocked on resources outside the VM, but data-plane tokens bypass the control-plane RBAC model entirely. If the MI has data-plane RBAC roles (e.g., Storage Blob Data Reader), those permissions are evaluated independently of the ARM role assignments.
Trusted Launch VMs
Azure Trusted Launch provides hardware-based security features for VMs, including virtual TPM (vTPM), Secure Boot, and integrity monitoring. These features are designed to protect the boot chain and establish a hardware root of trust. The research question is whether Trusted Launch affects the IMDS attack surface.
What vTPM Does NOT Prevent?
The critical understanding is that vTPM operates at the platform level (boot chain, disk encryption, attestation), while IMDS operates at the application level (HTTP API, OAuth tokens). These are orthogonal security layers:
vTPM prevents: Boot-level rootkits that modify the bootloader or kernel, extraction of BitLocker keys from memory without TPM authorization, and tampering with the measured boot chain (detectable via attestation)
vTPM does NOT prevent: Any user-mode process from calling IMDS at 169.254.169.254, token acquisition for any of the 47 audiences, exploitation of the acquired tokens against cloud services, WireServer access at 168.63.129.16, and RunCommand execution from a remote attacker using a stolen ARM token
Confidential VMs
Azure Confidential VMs (using AMD SEV-SNP or Intel TDX) provide a stronger hardware boundary by encrypting VM memory and preventing the hypervisor from reading guest state. However, even Confidential VMs:
- Still have IMDS access (the token endpoint runs at the host level but responds to guest requests through a secure channel)
- Still issue Managed Identity tokens through the same API
- Still expose WireServer on 168.63.129.16
The difference is that a compromised hypervisor cannot extract tokens from a Confidential VM’s memory. But if the attacker has code execution within the guest (as in this research), IMDS access remains unchanged.
Azure Attestation Integration
Azure Attestation (attest.azure.net) can verify that a VM booted with the expected configuration by validating TPM quotes. In theory, an application could:
- Request an attestation token from IMDS
- Include the attestation evidence when calling a target API
- The target API validates the attestation before granting access
In practice, this pattern is rarely implemented. No standard Azure service (ARM, Graph, Key Vault, Storage) requires attestation evidence in addition to the OAuth bearer token. The attestation token is available as one of the IMDS audiences, but it is orthogonal to the token-based attack chain. It remains a defense-in-depth mechanism for custom applications rather than a platform-level mitigation for IMDS abuse.
The Lesson
We began this research with a simple question. How far can a single curl command take you? The answer was more troubling than we anticipated.
A single unauthenticated HTTP request to a link-local address present on every Azure VM can return a token that effectively unlocks an entire subscription, making it straightforward to extract secrets from Key Vault, gain shell access to remote machines, and move laterally across the environment.
This reflects the uncomfortable reality of cloud identity security in 2026, where the primary challenge in compromising an Azure environment is gaining initial access to a VM. After that, Managed Identity enables continued escalation by allowing IMDS to issue tokens on demand for virtually any audience without authentication, meaningful logging, or rate limiting.
Permissions that appear low risk often translate into high-impact capabilities in practice, enabling reconnaissance, remote code execution, and even domain-level compromise, while overly permissive Key Vault configurations can expose all secrets, keys, and certificates including exportable private keys, and disk snapshots can represent complete copies of critical systems such as domain controllers that can be mounted silently without detection, allowing what begins as limited access to rapidly evolve into full control with far less resistance than most defenders anticipate.
Resources
Discover more Cloud Security, MSP, and AI content in Guardz Blog
Managed Identities in Azure resources
Tools, scripts, and tips in the Security Research Labs
