Entra ID: Stealth Persistence via Managed Identities

2026.03.15 SUBJECT: POST_COMPROMISE Persistence

Strategic Briefing

Managed Identities (MIs) are designed to solve the "secret zero" problem in Azure by providing Azure resources with an automatically managed identity in Entra ID. However, from an adversarial perspective, they are the ultimate stealth persistence mechanism. Why? Because Managed Identities authenticate via the Azure Instance Metadata Service (IMDS) token endpoint from within the resource itself. This means they bypass all Conditional Access policies requiring MFA, they never trigger interactive sign-in logs, and they don't have a password that can be reset or expired. If a threat actor compromises a resource and grants its Managed Identity high-level Graph API permissions, they secure a silent, unexpiring backdoor into the tenant.

0x01: Creating the Identity

The first step in establishing this persistence is assigning a System-Assigned Managed Identity to a resource the attacker controls or has compromised—like a forgotten Dev VM or an Azure Function. By doing this via the Azure CLI or ARM REST API, the identity is created silently in the background, blending in seamlessly with legitimate infrastructure.

CREATE_IDENTITY.SH
# Assigning a System-Assigned identity to a compromised VM # This registers the VM as an enterprise application in Entra ID without triggering standard user alerts. az vm identity assign --resource-group "RG-CORE-PROD" --name "SRV-WEB-01"

0x02: Escalating Permissions

This is the "Silent Escalation." Once the identity exists, the attacker uses their current high-privilege access (e.g., Global Admin or Privileged Role Admin) to grant the Managed Identity dangerous roles. Because the identity is tied to the VM, any code executed on that VM can now request a token and act as a `User Administrator`, allowing the attacker to manipulate the entire tenant hierarchy long after their original admin session has been revoked.

ESCALATE_IDENTITY.SH
# Assigning User Administrator role to the identity's Service Principal # The Object ID is the principal ID generated in the previous step. az role assignment create --assignee [OBJECT_ID] --role "User Administrator" --scope "/"