Let's talk about tiered administration in AzureAD:
- What it starts with
- How it can be violated
- What you can do about that
In 10 tweets or less. Go:
1/ There are three default admin roles that belong to Tier Zero in AzureAD:
Global Admin
Priv. Role Admin
Priv. Auth Admin
Everything IN tier zero is tier zero. Everything ELSE is not tier zero has has no business controlling anything IN tier zero.
2/ These admin roles aren't of much use if you don't grant them to anyone. Let's grant a service principal the Global Admin role:
3/ If we agree that this service principal needs this role assignment, then this isn't a *violation* of tiered administration -- it is an *expansion* of the definition of tier zero in our environment:
4/ You've expanded the definition of what tier zero is to now include this service principal. Cool.
But what has control of this service principal? For starters, the Cloud App Admin role:
5/ Other things control this SP, too, but let's stay focused on this admin role to illustrate the point.
We've agreed that the SP needs GA and will be part of Tier Zero. We must now also agree that the Cloud App Admin role is a tier zero role, as well:
6/ Why must Cloud App Admin be tier zero? Because the actions allowed by this role are immutable: you cannot change them. ANYONE granted this role can control your tier zero SP now, so this role must now be considered tier zero.
7/ Now let's say we grant the Cloud App Admin role to two users: a tier zero user and a tier one user:
8/ Now we have a tiered administration violation: a tier one user has control of a tier zero object.
9/ The "all or nothing" nature of Azure AD admin roles means that the most straight-forward way to deal with this is to revoke the tier one user's Cloud App Admin role assignment
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.