The hardest targets I faced while pentesting/red teaming all had one thing in common: mature, funded, and empowered vuln/patch management programs.
The hardest of all combined vuln/patch management with least privilege enforcement - and inspired the creation of #BloodHound.
Are patch/vuln management and least privilege enforcement sexy? No.
Are they easy? Hell no.
Are they worth the initial and continued investment? Absolutely yes.
The best teams have processes for pretty easily dealing with things like Zerologon. They hear about the new scary vuln, understand its impact, test patch deployment to a subset of affected systems, then deploy to all affected systems, and audit patch deployment/effectiveness.
Then they get lunch.
These folks are the unsung ass kickers of our field, and we almost never talk about them or give them praise. We once saw a team of 3 people replace a *terribly insecure* local admin credential system with the *highly superior* Microsoft LAPS in just under two weeks.
Doesn’t sound that cool until you learn their enterprise had approximately 600,000 domain-joined endpoints.
That’s beyond sexy, beyond cool. That’s a fucking miracle.
It bears repeating: the basics are the basics for a reason - they work. Patch management, vuln management, least privilege, asset inventory. The funded, empowered, and mature programs an organization builds around those basics will be what saves those organizations from disaster.
• • •
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.