Identity Crisis: The Unmanaged World of Azure Managed Identities

Identity Crisis: The Unmanaged World of Azure Managed Identities

Speakers: Alon Klayman, Security Research Tech Lead, Hunters; Eliraz Levi

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=P_QZ8noX4HY

Overview

In the rapidly evolving landscape of cloud security, Azure Managed Identities (MIs) have emerged as a cornerstone for securing inter-service communication within Microsoft Azure. This talk, "Identity Crisis: The Unmanaged World of Azure Managed Identities," delivered by Alon Klayman and Eliraz Levi from Hunters, delves deep into the security implications of these identities. While MIs significantly enhance an organization's security posture by eliminating the need for hardcoded credentials, their widespread adoption and inherent power also present a fertile ground for attackers if not properly understood and monitored.

The core focus of Klayman and Levi's research, and consequently this presentation, is to shift the narrative from purely offensive techniques to robust detection and investigation strategies. Recognizing a gap in existing public research, which predominantly highlights attack vectors, the speakers meticulously outline how defenders can identify and respond to the abuse of managed identities. Their work provides actionable insights and practical guidelines for security teams to proactively secure their Azure environments against sophisticated identity-based threats.

This article will explore the fundamental concepts of Azure Managed Identities, dissect the critical components of their JWT access tokens, and most importantly, detail the innovative detection and hunting methodologies proposed by Klayman and Levi. By examining a simulated attack scenario, the article will illuminate how defenders can leverage various Azure log sources and a novel Managed Identity Inventory to uncover malicious activities, thereby empowering organizations to maintain control in the "unmanaged world" of Azure's powerful service identities.

Background

▶ Watch: Talk goals: focusing on detection and investigation (1:00)

Before Azure Managed Identities (MIs) were introduced, Azure resources often relied on hardcoded credentials or secrets stored directly on virtual machines (VMs), application services, or other compute resources to authenticate with Azure AD (now Microsoft Entra ID) and access other Azure services like storage accounts or key vaults. This practice, while functional, presented significant security risks, including credential leakage, improper secret management, and the overhead of credential rotation.

Azure Managed Identities were developed to address this challenge. They provide an Entra ID identity for Azure resources, allowing them to authenticate to services that support Entra ID authentication without the need for developers to manage credentials. Essentially, an MI acts as a service principal that is automatically managed by Azure. When an Azure resource needs to access another service, it requests a temporary JWT access token from the Azure Instance Metadata Service (IMDS) endpoint, which is then used for authentication. This mechanism is analogous to AWS's "assume role" functionality, abstracting credential management away from the application layer.

There are two primary types of Managed Identities:

1. System-Assigned Managed Identity (SAMI): This type is directly tied to a specific Azure resource, such as a VM or an Azure Function App. Its lifecycle is intrinsically linked to the parent resource; deleting the resource automatically deletes the SAMI.
2. User-Assigned Managed Identity (UAMI): Unlike SAMIs, UAMIs are created as standalone Azure resources. They have an independent lifecycle and can be assigned to one or more Azure resources. This is particularly useful for scenarios involving multiple resources (e.g., a cluster of VMs) that require the same set of permissions, allowing for centralized management and simplified permission assignment.

The number of Azure services supporting Managed Identities is constantly growing, encompassing VMs, Function Apps, App Services, deployment scripts, and many more. While MIs significantly improve security posture by eliminating hardcoded credentials, their inherent power and the broad permissions they can be granted make them a prime target for attackers seeking to establish persistence, escalate privileges, or move laterally within an Azure environment. Understanding their operation, especially the structure of their access tokens, is crucial for both offensive and defensive security practitioners.

Key Findings

▶ Watch: Understanding Azure Managed Identities: definition and purpose (2:12)

The central contribution of Alon Klayman and Eliraz Levi's research lies in its pioneering focus on the detection and investigation of Azure Managed Identity abuse. While prior work predominantly highlighted offensive techniques, their work provides a much-needed defensive perspective, arming security teams with practical strategies. The speakers underscored that existing detections for MI abuse are often scarce and service-specific, prompting their comprehensive mapping of 12 potential detection opportunities. Notably, 11 of these proposed detections are service-agnostic, meaning they can be applied across various Azure services that utilize MIs, greatly expanding coverage for defenders.

A significant finding is the emphasis on understanding the internal structure of JWT access tokens issued to Managed Identities. Decoding these tokens reveals crucial metadata that can be leveraged for both attack and defense, including the identity type (SAMI or UAMI), potential permissions, and unique identifiers. The speakers demonstrated how specific fields within these tokens, such as Unique Token Identifier (UTI), XMS MIDI, and XMS AR ID, are indispensable for correlating activities across disparate log sources and building robust detection logic.

Furthermore, the research introduces a novel approach to creating a Managed Identity Inventory solely from existing Azure log sources. This is a critical enabler for several advanced detections, particularly for identifying sensitive Microsoft Graph (MS Graph) role usage. By demonstrating how to construct such an inventory without requiring elevated permissions or direct access to customer infrastructure, the speakers offered a pragmatic solution for security analysts, Managed Security Service Providers (MSSPs), and incident responders. This log-based inventory, combined with the detailed analysis of token fields and activity patterns, forms the bedrock of their proposed high-fidelity detection methodologies, which were tested on dozens of real Azure tenants and proven effective in identifying sophisticated attack flows.

Technical Deep Dive

▶ Watch: System-assigned vs. User-assigned Managed Identities explained (4:06)

The technical core of securing Azure Managed Identities lies in a deep understanding of their JWT access tokens and the metadata they contain. These tokens, requested by Azure resources from the IMDS endpoint, are base64 encoded and, when decoded, reveal a wealth of information critical for both attackers and defenders.

JWT Access Token Structure

Managed Identity access tokens come in two main structures: Azure subscription-related tokens (e.g., for Azure Resource Manager, Key Vault, Storage Account) and Microsoft Graph (MS Graph) tokens. Despite their differences, they share several common fields:

• audience (AUD): This field specifies the intended recipient of the token, indicating which service or endpoint it can be used to authenticate against. For defenders, it clarifies the token's potential scope.
• expiration time: Standard JWT field indicating when the token becomes invalid.
• Unique Token Identifier (UTI): A highly critical field that uniquely identifies the specific token instance requested, not the managed identity itself. The UTI is paramount for correlating activities across various Azure log sources during investigations.

Beyond these commonalities, token types have specific fields:

• Azure Subscription-Related Tokens: These tokens include several XMS fields. A particularly important one is XMS MIDI, which indicates the managed identity's identifier. For a SAMI, it will contain the identifier of the resource it's attached to (e.g., the VM ID). For a UAMI, it will contain the identifier of the UAMI itself, reflecting its independent lifecycle. Another key field is XMS AR ID, which specifies the resource from which the token was requested. This field is vital for understanding the origin of a token request, especially for UAMIs assigned to multiple resources.
• MS Graph Tokens: These tokens include fields like app display name (the service principal name correlated to the MI), roles (listing MS Graph API permissions), and wids (listing Entra ID built-in roles). A default wids value (starting with 0997) is always present upon MI creation and does not signify special privileges.

It's crucial to understand what not to look for in MI tokens:

• RBAC permissions: Granular permissions like Contributor or Owner on the subscription level are not embedded in the token. They are evaluated dynamically during the authorization process.
• SCP field: This scope field, common in other Entra ID token types, is absent in Managed Identity tokens.

Attack Story Walkthrough (Sona Technologies)

To illustrate detection strategies, the speakers presented a simulated attack on "Sona Technologies":

1. Initial Access: An attacker compromises a VM in the customer's resource group.
2. MI Discovery: The attacker queries the IMDS identity info endpoint (169.254.169.254/metadata/identity/info) to check for attached MIs. This is a stealthy method as it generates no Azure logs.
3. Token Request & Decoding: Multiple token types (ARM, Storage Account, MS Graph) are requested and decoded. The initial MS Graph token reveals no significant permissions. The ARM token provides subscription-level visibility but no granular RBAC.
4. Enumeration: The attacker discovers a UAMI (onboarding UAMI) within the management RG and a Key Vault (confv) accessible by a service principal (conf SP).
5. Privilege Escalation (UAMI Attachment): The attacker, having appropriate permissions on the customer's resource group, attaches the onboarding UAMI to the initially compromised VM. This is a critical lateral movement/privilege escalation step, as the VM can now request tokens for the newly attached UAMI.
6. Further Token Request & Decoding: New tokens are requested using the attached UAMI. The decoded MS Graph token now reveals highly sensitive permissions like Application.Read.All and Directory.Read.All.
7. Exploitation: The attacker uses these permissions to add a new secret to the conf SP, authenticates as conf SP, reads sensitive secrets from confv, and ultimately uses a storage account access key to exfiltrate and wipe data from the target storage account.

This narrative forms the basis for demonstrating how various detection mechanisms can intercept the attacker at different stages.

Demo / Proof of Concept

▶ Watch: Deep dive into JWT access tokens for identities (6:00)

While the talk did not feature a live, interactive demonstration of an exploit tool or a real-time defensive platform, it meticulously walked through a realistic attack scenario, framing it as a "made-up corporation named Sona Technologies." This narrative served as a conceptual proof of concept for the detection methodologies. The speakers systematically outlined the attacker's steps, from initial compromise and Managed Identity enumeration to User-Assigned Managed Identity (UAMI) attachment, privilege escalation, and data exfiltration.

Crucially, after detailing each phase of the attack, the presenters immediately transitioned to discussing how "Exona Corp was fortunate enough to have the right detections in place." This approach effectively demonstrated the efficacy of their proposed detection logics by applying them directly to the hypothetical attack flow. For instance, they showed how an explicit request for IMDS tokens from a compromised VM could be detected, how the attachment of a UAMI to an unusual resource would trigger an alert, and how the use of sensitive MS Graph roles by a managed identity could be flagged. This narrative-driven demonstration, backed by specific log sources and correlation strategies, served as a powerful conceptual proof for their defensive research.

Defensive Implications

▶ Watch: Key JWT fields: audience, unique ID, XMS_MIDI (8:00)

The core of the talk revolves around empowering defenders with actionable strategies to detect and investigate Azure Managed Identity abuse. Klayman and Levi outlined seven key detection and hunting tests, most of which are service-agnostic and designed to identify anomalies in MI behavior. These detections leverage various Azure log sources and specific fields within JWT access tokens.

1. Explicit IMDS Requests from VM with SAMI:

• Motivation: Attackers on a compromised VM will explicitly query the IMDS endpoint (e.g., 169.254.169.254) to discover attached Managed Identities and request tokens.
• Detection Logic: Correlate Managed Identity sign-in events (from Azure sign-in logs) with host-based process connection events. The correlation is based on the SAMI name (which is often the VM name for SAMIs) and the machine name. The destination IP will be the IMDS IP, and the process name will be associated with scripting tools like PowerShell, CMD, or Python.
• Log Sources: Sysmon event code 3, EDR network events, or Windows Event 5156.
• Limitations: This detection is service-specific (for VMs) and relies on host-based logging, which might not always be collected or available. It also focuses on specific processes, potentially missing others.

1. Mass Token Type Requests:

• Motivation: An attacker enumerating a compromised MI will likely request tokens for many different Azure services (e.g., ARM, Key Vault, Storage) to understand its full scope of permissions.
• Detection Logic: Identify a single Managed Identity initiating multiple token requests for diverse target endpoints (different AUD values) within a short timeframe. This behavior deviates from typical predefined and repetitive MI operations.
• Log Sources: Azure sign-in logs (specifically, Managed Identity sign-in logs).

1. Unusual Endpoint Requests:

• Motivation: A stealthier attacker might avoid mass requests but still ask for a token to an endpoint the MI has never accessed before.
• Detection Logic: Establish a baseline of (Managed Identity ID, target endpoint ID) pairs from Managed Identity sign-in logs over a learning period. Alert on any new, previously unseen pairs.
• Log Sources: Azure sign-in logs.

1. Attachment of UAMI to Compromised VM (XMS AR ID-based UIBA):

• Motivation: A common privilege escalation technique is for an attacker with sufficient permissions on a resource group to attach an existing UAMI (especially one with elevated privileges) to their compromised resource.
• Detection Logic: Leverage the XMS AR ID field within JWT access tokens, which indicates the resource from which the token was requested. Create a User and Entity Behavior Analytics (UEBA)-like baseline for each UAMI, grouping the XMS AR ID values. Look for deviations, specifically new or unusual XMS AR ID values for a given UAMI. This helps identify when a UAMI starts requesting tokens from a resource it wasn't previously associated with, particularly if the attachment is logically inconsistent (e.g., an HR UAMI attached to a public-facing VM in a different resource group).
• Log Sources: Azure Activity logs (specifically, log entries containing the XMS MIDI field, indicating MI activity).

1. Token Usage from Multiple IPs (UTI-based):

• Motivation: After compromising an MI, an attacker might exfiltrate its token and use it from their own infrastructure, leading to the same token being used from multiple IP addresses.
• Detection Logic: Monitor Azure Activity logs for entries containing the XMS MIDI field (to filter for MI activity). Group activity by Unique Token Identifier (UTI) and identify instances where the same UTI is associated with more than one source IP address within its lifetime.
• Log Sources: Azure Activity logs.

1. Token Usage from Non-Azure IP:

• Motivation: Similar to the above, using an MI token from an IP address outside Microsoft's Azure ranges is highly suspicious, as Managed Identities are inherently tied to Azure resources.
• Detection Logic: Maintain an up-to-date inventory of Microsoft's public service tags (Azure IP ranges), which are published weekly. Compare the source IP address of Managed Identity activity against this inventory. Alert on any activity originating from a non-Azure IP.
• Log Sources: Azure Activity logs, Azure sign-in logs.
• Limitations: Acknowledge potential false positives, such as legitimate Azure Arc scenarios where MIs are created for resources outside Azure. These can be managed via exclusions.

1. Sensitive MS Graph Role Usage:

• Motivation: Attackers often target MIs with high-privilege Microsoft Graph permissions (e.g., Application.Read.All, Directory.Read.All) to enumerate or manipulate Entra ID objects.
• Detection Logic: Identify specific MS Graph activity logs where the acting identity is a Managed Identity and the permissions used are deemed highly sensitive. This requires an Managed Identity Inventory.
• Log Sources: Microsoft Graph activity logs.

Building a Managed Identity Inventory

A crucial enabler for several of these detections, especially "Sensitive MS Graph Role Usage," is a comprehensive Managed Identity Inventory. The speakers highlighted the challenges of building this, particularly for MSSPs or incident responders who might lack broad permissions. They proposed two main approaches:

1. Direct Query: Using tools like AZ CLI or PowerShell to query all MIs in an environment. This provides a complete baseline but requires specific permissions.
2. Log-Based Inventory: Constructing the inventory from Azure log sources, making it accessible even without direct query permissions.

• Azure sign-in logs: Contain MI sign-in events but might not distinguish between SAMI and UAMI, a crucial distinction for some detections.
• Azure Audit logs: Record the creation of new MIs.
• Azure Activity logs: Record activities performed by active MIs.
• Limitations: Log-based inventories might miss dormant MIs (not active in Activity logs) or only record creations (Audit logs).
• Recommendation: A hybrid approach is often best: an initial baseline via direct query (if permissions allow), then continuously updating and expanding it using Azure Audit and Azure Activity logs.

This inventory, when joined with Microsoft Graph activity logs, allows for straightforward detection of sensitive Graph role usage by Managed Identities. The speakers noted this detection was "super high fidelity" and effective in real-world environments.

Key Takeaways

• Azure Managed Identities (MIs) are critical for cloud security by eliminating hardcoded credentials, but they are also potent targets for attackers if not properly monitored.
• Understanding the structure and specific fields (UTI, XMS MIDI, XMS AR ID) within JWT access tokens issued to MIs is paramount for both offensive and defensive security.
• Defenders should prioritize service-agnostic detection strategies for MI abuse, as these provide broader coverage across diverse Azure services.
• Building a Managed Identity Inventory, even from log sources alone, is a foundational step for advanced detections, enabling the identification of sensitive Microsoft Graph role usage by MIs.
• Correlation across multiple log sources (Azure sign-in, Azure Activity, host-based logs, MS Graph activity) using unique identifiers like the UTI is essential for uncovering sophisticated MI-based attacks.
• Proactive baselining of MI behavior (e.g., typical token types requested, associated resources) is crucial for identifying anomalous and potentially malicious activity.

About the Speaker(s)

Alon Klayman is a Security Research Tech Lead at Hunters. With a decade of experience in the security and IT industry, Alon has held various roles, including DFR team leader, penetration tester, and threat researcher. He is also a self-proclaimed soccer fanatic and the "father of Panda," his dog.

Eliraz Levi is a security researcher fascinated with logs and forensics. An history geek and amateur tennis player in his free time, Eliraz began his career in information security before the term "cyber" became commonplace. His expertise lies in understanding the intricate details of logging and how they can be leveraged for security investigations.