There has never been a better time than right now to get involved with Azure security research.
Not convinced yet? Let's compare where we are with Azure versus where we are with on-prem AD: 🧵
Active Directory initially came out in December of 1999. Now it's 2022. What's happened between then and now?
We actually had pass-the-hash before AD came out, but it wasn't really made practical until @hernano released the PTH Toolkit in 2007, nearly 8 years after AD's release:
2011 gave us Mimikatz by Benjamin Delpy (@gentilkiwi), 2012 gave us Responder by Laurent Gaffié (@PythonResponder). Two tools that are still used every day by every pentest shop a full decade after they came out:
Tim Medin (@TimMedin) gave us Kerberoasting in 2014 - FIFTEEN YEARS after AD came out. Will Schroeder (@harmj0y) and Lee Christensen (@tifkin_) published their ADCS whitepaper and tooling just last year:
What do these tools and techniques all have in common?
✅ - They all came out several years after AD's initial release
✅ - They have all stood the test of time and are all still used on a daily basis
✅ - NONE of them are "exploits" - they are abuses and abuse tooling
What about Azure? Technically, Azure initially came out in 2008. For an apples-to-apples comparison, let's put 2022 in the middle of our Azure timeline:
In 2018, a full ten years after Azure's initial release, Karl Fosaaen (@kfosaaen) gave us Microburst:
2020 gave us PowerZure by Ryan Hausknecht (@Haus3c), Stormspotter by Leron Gray (@mcohmi), and ROADtools by Dirk-jan Mollema (@_dirkjan):
We are still in the early days of Azure security research. Compare where we are in 2022 with Azure compared to where we were in 2011 with AD:
There are OCEANS of attack research opportunity in Azure. We are not even CLOSE to done. Who knows what the next 10 years might bring?
This isn't a controversial opinion - quite the opposite, as the results of this poll show:
Third, consider watching my talk at @1ns0mn1h4ck next month, where I will try to give you my best walk-through of my own abuse research methodology that you can use and improve: insomnihack.ch/register/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
In Windows and Active Directory, there is one system responsible for making access decisions in nearly *all* cases: the Security Reference Monitor. This system makes access decisions by analyzing security descriptors on securable objects and User Rights Assignments:
In "Azure", the story is very, very different. There are multiple forms of access control, and multiple services responsible for making access decisions.
"Azure" means the 600+ distinct services that comprise Microsoft's cloud computing platform.
Understanding who has control of any given object in any given Azure service requires a complete understanding of *all* of these systems and how they cooperate with one another.
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.
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.