Azure Managed Identities: An Attacker's View of a Credential-less Design

Context: why Azure caught my attention

I've spent the last year studying Active Directory exploitation and Red Team techniques, continuously tracking new CVEs and attack vectors as Windows Server versions evolve. Microsoft's engineering is impressive; they've made corporate infrastructure management dramatically easier to scale. In recent years, Microsoft extended this to hybrid environments by enabling synchronization between on-premises Active Directory and Azure tenants through three policies: Password Hash Synchronization, Pass-through Authentication, and Federation. This lets on-prem users access cloud services like Microsoft 365 and Azure. That hybrid bridge is where things get interesting. Azure caught my attention because Entra ID resembles Active Directory so closely, yet the role model is fundamentally different. Azure RBAC roles are granular and scope-specific in ways that AD roles aren't. Digging into App Registrations, Enterprise Apps, and Managed Identities revealed an underdocumented attack surface with security defaults that seemed worth exploring.

App Registrations and service principals

App Registrations present an enormous attack surface. Misconfigurations can lead to full tenant compromise, or worse, on-premises domain takeover if the hybrid sync is in place. An App Registration is how an application identifies itself to Entra ID. It's given specific permissions and privileges over the objects and services the application needs to function. When you register an app, you assign it a unique identity, define the permission scope (what the service principal can do), decide who can authenticate to it, and attach credentials: client secrets or certificates. The App Registration is the definition; the service principal is the runtime. When an app is registered, a service principal is created in the tenant as an object that inherits the permissions defined for the app. It's essentially the cloud equivalent of a service account in Active Directory. Like AD service accounts, they can drift into being over-privileged, and they carry the same burden of credential rotation and ongoing management.

Managed identities: service accounts without the secrets

Managed Identities are closer to Group Managed Service Accounts (gMSA) in Active Directory than to traditional service principals. gMSA were introduced to solve password management at scale: the Domain Controller rotates the password automatically, so nobody has to babysit the credential. Managed Identities apply the same idea to Azure. Instead of expecting developers to rotate service-account credentials and implement all the security controls themselves, the Azure infrastructure handles it. You get a credential-less identity that applications can use to authenticate, with nothing sitting in a config file to leak.

Two flavors with different risk models

Managed Identities come in two types, and the distinction matters more for the attack surface than it first appears. A system-assigned identity is created and bound to a single resource's lifecycle. It comes into being when the resource is created and dies when the resource is deleted, taking its role assignments with it. It's a one-to-one relationship: one identity, one resource, no sharing. A user-assigned identity is a standalone Azure object with its own lifecycle, independent of any resource, and it can be attached to several resources at once. That's operationally convenient. Rather than provisioning a new identity for every VM in a fleet, you create one "deployment pipeline" identity and attach it everywhere. The convenience has a cost, because a user-assigned identity concentrates risk. If it's over-privileged, or if any one of its host resources is compromised, that same identity and every permission it holds are now exposed across all the resources it's attached to, not just the one that got popped. A system-assigned identity keeps the blast radius contained by design.

The IMDS attack path

Managed Identities improve the overall security posture, but the attack surface doesn't shrink, and implementation flaws can still lead to full tenant compromise. Every Azure resource that carries a Managed Identity, whether that's a VM, a Function App, a Logic App, or an Automation Account, can request a token for that identity from the Instance Metadata Service at 169.254.169.254. It's a link-local endpoint, in theory reachable only by the resource itself, and no credential is required to make the request. That's the whole point of the design. The problem is what happens when an attacker gets code execution, or even just request-forwarding, on that resource. At that moment they inherit the Managed Identity's permissions instantly, with no stored secret to hunt for. Someone who starts with low privileges over a resource, but where that resource runs with a Managed Identity, can turn that into tokens scoped to whatever the identity can reach: Azure Resource Manager, Storage accounts, Key Vaults. A small misconfiguration becomes a privilege-escalation or lateral-movement vector.

Why this is hard to measure by hand

Understanding the theory is one thing. Measuring the real blast radius in a live tenant is another, and that's where it gets tedious. Each resource type exposes its identity differently. A VM gives it up through RunCommand into IMDS, an App Service through Kudu execution, a Logic App through a callback, a Container Group through its exec endpoint. Each of those paths also needs a different level of privilege from the compromised user before it works at all. On top of that, knowing which RBAC roles actually enable exploitation, rather than which ones merely look interesting, takes a real understanding of Azure's privilege model. Owner and Contributor are obvious; the fact that Managed Identity Operator plus a host-write role lets you attach an identity to a box you control is not. Public research mapped a lot of this ground before I did. NetSPI's MicroBurst (Karl Fosaaen) and Team Axon's work on Managed Identity abuse were both useful in framing the problem and sanity-checking what I was seeing in the lab. Doing the assessment by hand is slow and easy to get wrong. You enumerate roles, work out which resources carry an identity, remember the extraction path for each host type, pull the token, then repeat the whole exercise as the identity you just stole. The question underneath all of it is simple to state and annoying to answer: if I have this level of access to this resource group, how far does Managed Identity abuse actually take me? The answer decides whether the attack is even worth continuing, which is exactly why it's worth answering systematically rather than by hand. That realization is what pushed me from studying the attack surface to building tooling around it.

Key takeaways

Managed Identities are a real security improvement: credential-less authentication, automatic rotation, no secrets in code. But implementation flaws and misconfiguration can still lead to catastrophic compromise, and the path from initial access to tenant-wide exposure is often shorter than organizations expect. For defenders, the shape of the risk is worth internalizing. A managed identity is only as safe as the control-plane roles that can run code on its hosts, a user-assigned identity is only as trustworthy as the least-trusted resource it has ever been attached to, and roleAssignments/write at resource-group scope is a quieter path to escalation than it looks. Understanding that path is what separates a real security assessment from surface-level testing.

§ — Also in evidenceView all →

Other exhibits

Exhibit L · 04 Sept 2026

SQL Injection

PortSwigger Web Security Academy notes on detecting and exploiting SQL injection, from UNION attacks to blind and out-of-band techniques

Read the note →

Filed

Exhibit K · 18 Aug 2026 · Azure Security

Modeling Managed-Identity Privilege Escalation as an Attack Graph

A framework for treating Azure managed-identity abuse in hybrid Entra ID environments as a graph-reachability problem. I define the node and edge types, ground each edge in Azure RBAC semantics, show how my tool Fenrir uses the model to answer one question conservatively, and work through a case study in my own lab. Framework and systematization, not an empirical study.

Read the note →

Filed

Exhibit J · 15 Aug 2026 · Azure Security

Building Fenrir: Automating the Azure Managed Identity Attack Path

A walkthrough of Fenrir, a Python CLI I built during a red-team internship that automates the Azure identity attack chain: tenant recon, an exploit-readiness verdict, managed-identity token theft through compute hosts, and tenant-wide post-exploitation.

Read the note →

Filed

§ Contents