Azure App Service Web Apps are yet another #Azure service that supports managed identity assignments.
Here's how attackers can use #BARK to abuse those assignments:
There are at least 3 ways to achieve code execution on an Azure App Service Web App ("Azure Web App" from here on) instance:
1. The Kudu shell execution API endpoints 2. Poison deployment to include a web shell in the app 3. Find a cmd execution vulnerability in the deployed app
We'll focus on #1 - abusing the built-in Kudu shell execution endpoints.
This is the feature the Azure GUI uses as its "Debug Console" and is documented here: github.com/projectkudu/ku…
We can access this endpoint with either deployment credentials or an AzureRM-scoped JWT for a principal with Owner, Contributor, or Website Contributor role on the Web App.
You can use either with BARK's new cmdlet, Invoke-AzureRMWebAppShellCommand
Say you found clear-text application-scoped credentials for the Web App. Just base64-encode the username/password and provide that, the Kudu URI, and the command to Invoke-AzureRMWebAppShellCommand:
Or if you have an AzureRM-scoped JWT:
If the Web App has a Managed Identity assignment, we can use Invoke-AzureRMWebAppShellCommand to extract a JWT for the Managed Identity Service Principal:
As an attacker, we can now act as the service principal and gain whatever new privileges that service principal may have that we didn't have before.
Defenders and vendors have to play catch-up whenever one of these novel C2 methods becomes popular.
I believe it's possible to proactively, semi-automatically discover these methods in existing and emerging cloud services. We can assess their attractiveness to attackers, vendors can make them less attractive and prioritize their own detection efforts.
Kerberoasting is an incredibly powerful and reliable attack against Active Directory. In some situations it can result in an attacker becoming Domain Admin nearly instantaneously.
Here's how to prevent this attack: 🧵
First we need to identify Active Directory users that are "kerberoastable" - possible targets for the attacker to choose to Kerberoast.
Kerberoast relies on a user having some value in their "serviceprincipalnames" attribute.
Find all of them instantly with no 3rd party tools:
dsquery has been built in to Windows Server since Server 2008. You also get it when installing RSAT.
Take a close look at BARK's functions and you will see that most of them are simple wrappers around basic REST API calls. This means it's very easy to extend BARK.
For example, BARK is missing a function to list virtual machines. Here's how easy this is to add: 🧵
Let's look at an existing function that lists objects in AzureRM, "Get-AllAzureRMResourceGroups":
The most "difficult" line we need to change is line 24. We must ensure we are hitting the right URL.
The Microsoft documentation can help us here. We will Google "azure api list virtual machines", and the first result is this page: