(1/9) My first pentest job was at a company called TrustCC - little-known then and since purchased. We had a tradition whenever got DA: horrible, awful, cringe-worthy puns.
(2/9) We would send internal emails that were half celebratory, half instructive, explaining how we got DA in that particular client environment. But the email subject was REQUIRED to be a pun based on the client name.
(3/9) So if the client was "Sunny Hills Bank", the email subject might be "Walking on the Sunny (Hills Bank) Side of the Street: Path to DA #1".
(4/9) That "#1" in the subject indicated this was the FIRST path to DA you could find. Finding one path to DA was good. If you found two, even better. If you found five, you were godlike.
(5/9) That was in 2014. Now, in 2020, we are using #BloodHound to quantify how many attack paths to "DA" there are in our client environments. The *lowest* number of attack paths we've seen is 1,732,550. That's a lot of puns to write.
(6/9) 1.7 million attack paths sounds like a lot, and it is. But those attack paths didn't just appear out of thin air because we ran #BloodHound: they've been growing in number and complexity for years.
(7/9) In some organizations, attack paths have been festering for decades, waiting to be found and executed by an attacker, or cleaned up by a defender.
(8/9) You can use #BloodHound to identify, quantify, and eliminate those attack paths before a real attacker discovers and executes them. A couple resources to get started:
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.