Thread by @_wald0

#Azure Managed Identity assignments are "secure by default."

Dangerous attack paths can emerge around these assignments.

Here's those attack paths emerge, how attackers abuse them, and how defenders can eliminate them: 🧵

First we should understand what Managed Identities are. I think the best way is to understand the problem they are designed to solve.

We have a great recent example of this problem from the alleged Uber breach, where a PowerShell script may have been storing plain text creds:

This problem is not new and not surprising to many people:

https://twitter.com/_wald0/status/1570811911503220740

Managed Identities are an effective answer to this problem for many scenarios. For example, say we have an Azure Virtual Machine using plain text credentials to perform some privileged task in Azure.

The process will read the creds then get a token via STS:

The major risk here is that the username/password combo can be stored insecurely somewhere outside the VM, then stolen and used by an attacker for some nefarious purpose.

Managed Identities eliminate this risk while offering a familiar, low-friction authentication flow:

The Virtual Machine itself becomes the entity able to authenticate as the Service Principal, and it does this via its local Instance Metadata Service (IMDS).

This local service is not authenticated and any process on the VM can interact with it to request tokens for the SP.

This is "secure by default" and no risk exists because we haven't given the Service Principal any privileges yet.

But if you've gone through the trouble of configuring this, don't you think that Service Principal is going to need some privilege?

Let's say we give the SP "Subscription Owner", but that only a Global Admin can access the VM.

In that case, who cares? A Global Admin is already all-powerful, so no privilege escalation opportunity exists:

Dangerous attack paths emerge when the user with access to the VM has *less privilege* than the SP associated with the VM via a Managed Identity assignment:

Doubt this configuration would ever exist in the real world? We've seen it.

Don't just take my word for it. Read the replies to this to get an idea of what madness exists in the real world:

https://twitter.com/_wald0/status/1502475482004041730

How do attackers abuse Managed Identity attack paths? Let's see three quick examples based on this overall attack path that mirrors different configurations we have observed in real environments:

Step 1: compromise User A and RDP into the Virtual Machine. Use our access to request a token for Service Principal B via the IMDS:

Step 2: Use the JWT for ServicePrincipalB to add a new evil function to the Function App. Fetch the Function App master key, then use the master key to retrieve the output of that function:

Step 3: Use ServicePrincipalC's JWT to add a new evil runbook to the Automation Account, then retrieve the output of that function:

The resulting token at the end of this attack path is for ServicePrincipalE, which is a Privileged Role Admin at the tenant. This is a Tier Zero role which allows escalation to Global Admin: medium.com/p/210ae2be2a5

Admins need to audit for and eliminate these attack paths. Here's how:

Let's genericize the attack path and see it like this, where the SP has some sort of Tier Zero level of privilege:

Your first and most important step: identify any service principals with Tier Zero privileges.

You can easily discover all Service Principals with Tier Zero rights using BARK's Get-TierZeroServicePrincipals:

This function finds all service principals with the following privileges that are definitively Tier Zero:

Global Admin
Privileged Role Admin
Privileged Auth Admin
Partner Tier2 Support

RoleManagement.ReadWrite.Directory
AppRoleAssignment.ReadWrite.All

No results? Great! Keep it that way by periodically running that function and KEEPING the results empty.

If you have results, try to get rid of those privileges! This is where you will have the LARGEST positive impact on reducing attack paths with the LEAST amount of work.

Maybe you can't get rid of that privilege for that SP. That's valid.

Your next step is to enumerate all of the AzureRM resources with Managed Identity assignments.

You can do this with BARK's Get-AllAzureManagedIdentityAssignments:

Now compare the list of Tier Zero SPs to the list of Managed Identity SPs and see if there is any crossover.

There are many ways to do this, here's how to do this with PowerShell:

See results? Try to get rid of them! This will likely be more difficult than removing the SP's privileges, but is WAY easier than your next step...

Your next step is to audit who has control of the various AzureRM resources with Managed Identity assignments. This gets very complicated very quickly.

You can use #FOSS BloodHound to audit who controls any given AzureRM resource:

See results? Good luck. You need to compare the privileges held by each of those principals with the privileges held by the Tier Zero SP.

In other words, the Azure resource is now Tier Zero and must only be controllable by other Tier Zero principals.

All tools used in this thread are free and open source software:

BARK: github.com/BloodHoundAD/B…
BloodHound: github.com/BloodHoundAD/B…