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