Stealing Azure Key Vault Secrets With Azure Managed Identities

When doing Azure penetration testing, one of the prevalent ways to get initial access or escalate privilege is by finding credentials. Credentials on GitHub, in blobs, on disk, in runbooks, and even in key vaults like we discussed in the previous article.

In this article we will see how managed identities can dramatically reduce the risk of a penetration tester finding credentials lying around. At the same time the risks they carry when compromised.

TLDR;

  • For service-to-service communication, Microsoft recommends using Azure managed identities
  • AIMS allows for these IDs to retrieve tokens without authentication
  • A user can use these tokens to act on behalf of these IDs and behave maliciously
  • Depending on the RBAC assigned to the identity, the user can access resources, read secrets, etc.

When user accounts are not recommended

When resource-to-resource communication is required, in on-prem active directory, we’re used to utilizing service accounts. In Azure the alternative could be one of three:

  1. Managed identity
  2. Service principal – using app registration or enterprise apps
  3. User account

The least secure is the user account. This leaves us with two options, service principal and managed identity.

Figure 1 User accounts not recommended

Hassle of Service Principals

Although service principals are an option, they come with their own baggage. Usually, the lifecycle of a service principal goes something like this:

Create SP > Grant permissions > Set credentials > Store credentials

And if you’re vigilant, you add: Rotate credentials > Clean up credentials > Delete SP

Unfortunately, in Azure penetration testing, it’s discovered that often the cycle stops at the “Store credentials” phase. It’s rare to see SPs with rotating credentials and rarer to see SPs cleaned up or removed when they’re no longer needed.

Azure Managed Identities

This is where managed identities come in. There is no secret or certificate that we must store or worry about. Plus, we can assign RBAC to managed identities like we do with any other user or group to tightly control what they can and cannot access.

Managed identities come in two flavors.

System Assigned Managed Identity (SAMI)

  • SAMI has a lifecycle attached to the resource. If the resource is deleted, the SAMI is deleted too.
  • SAMI can be used by one resource. And a resource can have one SAMI.
Figure 2 System assigned managed ID

User Assigned Managed Identity (UAMI)

  • Created by the user, as a new resource in AAD
  • UAMI is then assigned to a resource or multiple resources
Figure 3 User assigned managed ID

ID to Key vault

In our example, we have multiple Azure VMs that need access to a key vault secret. The key vault secrets are protected by RBAC as we have seen in the previous article. Since it’s going to be multiple VMs accessing secrets, it’s best to create a user assigned managed identity like the one above.

We then assign permissions for the identity, scoped to the necessary secrets.

So far, this looks tightly secure!

  • We have one managed identity, managed by Azure.
  • The managed identity has no passwords for us to worry about.
  • The ID can only access a specific set of secrets.

Putting our Azure penetration testing hats on, we must ask ourselves, is it possible to compromise a managed identity? And if possible, can we use it to access the key vault secrets?

Figure 4 RBAC For UAMI

Azure Instance Metadata Service

Azure Instance Metadata Service (AIMS) is a service used to configure and manage Azure VMs. It is available, and accessible by all running instances of VMs. In essence, it’s a REST API accessible at 169.254.169.254. However, it’s important to note that access to the API is unauthenticated. In other words, anyone using the VM, with the manged identity, can trigger an API call to AIMS.

One of the API calls could be requesting for a token. And since the VM has a manged identity attached to it, the token will carry the identity’s context.

Here is what is looks like.

Figure 5 Getting management token from AIMS

What this will allow us to do during Azure penetration testing is to authenticate using the newly acquired token, thus impersonating the managed identity.

If you recall, the identity has been assigned permission to certain key vault secrets, which we can now list. But we still need another type of token to access the vaults.

Key vault secrets

AIMS can also be used to request tokens to access the key vault. Here is what it looks like.

Figure 6 Getting vault token from AIMS

From there on, our Azure penetration tester will proceed to list the resources the managed ID has access to, including the secret value.

Figure 7 Revealing secrets from Key vaul

Azure system assigned and user assigned managed identities are convenient replacement for traditional user accounts and service principals.

Summary

However, if the resource using the identities is compromised, the identities can be abused to request tokens. This allows the user to act on behalf of the identity.

Depending on what permissions are assigned to the identity, the penetration tester or malicious actor can access sensitive resources like vault secrets.

Resources

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-governing-azure

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-principal

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service?tabs=windows

https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-to-use-vm-token

https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/tutorial-windows-vm-access-nonaad