New abuse primitives that take advantage of legitimate administrative protocols and features are wildly exciting. Why? Because no object is an island. Everything is interconnected, and that interconnectedness can have enormous impact. Thread: 🧵
You may or may not be familiar with the childrens' book, "If You Give a Mouse a Cookie:"
It's a classic children's moral illustrating the slippery slope idea:
If you give a mouse a cookie, it will ask for a glass of milk.
But it's too hard to drink the milk, so now the mouse wants a straw.
The mouse is worried it has a milk mustache, so now it wants a mirror.
etc
The mouse just keeps asking for more and more stuff which, in the context of what it already has, is reasonable:
It's reasonable to give the mouse milk to go with its cookie, a straw with the milk, etc - but the mouse can effectively horse trade up to whatever it wants.
We can understand and model this with math.
"If You Give a Mouse a Cookie" is a graph comprised of vertices and edges:
These discrete connections, when seen in isolation, are reasonable. The same is true in AD: it's reasonable for these particular connections to exist, but together they form an attack path:
Now, back to the original point. Finding new abuse primitives that abuse legit functionality can have extraordinarily high impact. For example, what if we found a new abuse that bypasses this path, connecting Domain Users to Domain Admins instantly?
Or, what if we had disparate, unconnected paths?
Whenever someone finds new abuses, that new abuse is very likely going to be the missing link between disparate paths, connecting Domain Users with Domain Admins:
Mathematically, the impact on the number of paths in a graph grows at a rate of O(n!) - factorial growth. That's a LOT more than even exponential growth:
Why do I say all this? Because when you consider the above, plus the fact that we are still in the infant days of Azure research, you should be excited at the impact your own Azure research can have - it is MUCH greater than you think!
In my @1ns0mn1h4ck talk, I'll try to give you all the context and fundamental building blocks you need to stat finding new abuse primitives. You can register for Insomni'hack here: insomnihack.ch/register/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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:
I’m a firm believer in the (cliche) adage, “Outcomes, not output.” It’s not about the number of lines of code you wrote in 2021, but the impact those lines of code had - the outcomes they created. Here’s 5 small things you can do in 2022 to create big AD security outcomes:
#1: Audit the owners of your domain controller computer objects. Update the owner of each object to the Domain Admins group for that domain.
Time required: up to 1 hour
Potential attack path impact: extremely high.
Risk of breaking something: very low
#2: Use BloodHound to find where Domain Users/Everyone/Auth Users has privileged access, and remove all such instances.
Time required: up to 1 week
Potential attack path impact: extremely high.
Risk of breaking something: low
Enough time has passed now that we are starting to see the outcomes of this methodology, which I'd like to talk to you about:
Strip away the brands, the tools, the people, and everything else, and you are left with the only thing that REALLY matters:
The problem.
The problem that APM seeks to solve is the persistent availability and reliability of attack paths.
Pentesters, red teamers, and real attackers have been abusing attack paths, specifically in Active Directory, for over 20 years. AD attack paths are INSANELY reliable. They can be abused with reliable tools, including legitimate admin tools like Powershell and PsExec.
This service is accessible to every VM in Azure. As far as I know, there's no reason to ever disable this service for a VM, so it should always be accessible to every Azure VM.
IMDS's REST API is available to each VM at the non-routable, local IP of 169.254.169.254.
Lina is writing the technical content our industry needs: deeply technical, clearly explained, and appropriate for both offense and defense audiences. See her writings here: inversecos.com