Where do #Azure attack paths come from? Attack paths that abuse (mis)configurations generally emerge from two types of control in Azure: explicit control and implicit control.
Let's see what that means and how you as a defender can eliminate the most dangerous paths:🧵
Explicit control means there is a one-to-one control relationship clearly defined on the controlled object. For example, Azure Users can be made explicit owners of Azure Service Principals:
David owns MyCoolAzureApp, meaning David can add a new credential to that Service Principal and authenticate as it, taking over the identity.
But this explicit configuration does not exist in isolation: there are paths INTO the user OUT of the SP:
For example, let's say the SP has been granted an AzureAD admin role:
Because of the *explicit* control relationship between David and the SP, an attack path has emerged connecting David to the Cloud App Admin role:
That's explicit control. Implicit control is one-to-many control that's implied through, for example, AzureAD admin roles.
Let's look at Cloud App Admin as an example. The "MyCoolAzureApp" SP has that role. But there are other SPs in the tenant as well:
When this role assignment is scoped to the tenant (as opposed to a specific SP or app), the assignee gains control of ALL apps and SPs in the tenant. "MyCoolAzureApp" can add new secrets to these other SPs:
This combination of explicit and implicit control makes no difference to the adversary, who sees attack paths, not individual lists of configurations:
As a defender, you will get the biggest bang for your buck in eliminating such attack paths by taking the following steps:
1. Remove any AzureAD admin role assignments where an SP has been granted Global Admin, Privileged Role Admin, or Privileged Auth Admin
2. Remove any MS Graph app role assignment where an SP has been granted AppRoleAssignment[.]ReadWrite[.]All or RoleManagement[.]ReadWrite[.]Directory
3. Alert on any SP being granted one of the above AzureAD admin roles or MS Graph app roles.
Doing those 3 things will dramatically reduce your attack path risks in Azure.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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…
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.