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:🧵
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:
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:
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
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.
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
