In the upcoming #BloodHound 4.1 release, we are introducing 3 new edges. Let me explain why this is actually more impactful than it may sound: 🧵
Let's say you have a basic graph with 3 nodes all connected to each other (this is called a Strongly Connected Graph). We'll call these nodes 1, 2 and 3:
How many possible paths are there? We can determine that by searching through non-cyclic trees originating from each node. For example, if we start at 1, we can visit 2 then 3, or 3 then 2:
We need to do this for nodes 2 and 3 as well. Then we can count up the total number of paths, which is 6:
Let's make a nice table for ourselves to keep track:
With me so far? Good. Let's add another node to our strongly connected graph, Node 4:
And let's explore the possible paths we can take from Node 1:
Here, there are 6 distinct paths (you can count this easily by counting the nodes in the bottom row). Don't forget we must repeat this for each node, so our total number of paths in this graph becomes 24 (6*4):
Let's keep going by adding Node 5 to the graph:
Here's what it looks like to explore possible paths from just one originating node:
We must repeat this for each node, so the possible number of paths grows to 120:
See the pattern yet? You can calculate the number of possible paths for an SCG of 5 nodes with:
5*4*3*2*1 = 120
This is known as the factorial of 5.
Let's keep going.
If we calculate the factorial (number of distinct paths in a strongly connected graph) for up to 10 nodes, our table looks like this:
How bad can this get? The factorial of 100 is approximately 9.3x10¹⁵⁷.
That number is so big, it's actually larger than the estimated number of particles in the observable universe.
Back to BloodHound. Adding 3 new edge types will in fact introduce an unimaginably high number of new attack paths.
In our DerbyCon talk from 2017, we explained, visually, the impact of adding ACLs into the graph here:
We're adding 3 new edges in 4.1, with several other new types planned for this year. Want to hear about it first? Register for and attend our webinar on February 9th: specterops.zoom.us/webinar/regist…
Correction: [1,3,2,3] should be [1,3,2,4]
[2,3,4] and [2,4,3] should be [2,1,3] and [2,3,1], thanks to @derekmelber for pointing this out!
• • •
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.