Thread by @_wald0

Three of the most common issues #BloodHoundEnterprise finds, their impacts, and how you can use FOSS #BloodHound to find and fix these issues yourself, today: 🧵

Issue #1: Domain Controller object ownership. This issue is *extremely* common and *extremely* dangerous when looking at attack path possibilities this opens up. This is also *extremely* easy to fix.

In FOSS #BloodHound, run this query using the "raw query" bar at the bottom:

MATCH (g:Group)
WHERE g.objectid ENDS WITH '-516'
MATCH p = (n:Base)-[:Owns]->(c:Computer)-[:MemberOf*1..]->(g)
RETURN p

You'll get visual results, showing you the various principals that own your Domain Controller computer objects - this is real data, so I've removed labels and annotated the image:

Remember, as @JohnLaTwC said, attackers think in graphs: all of those random users have attack paths leading to THEM, meaning those attack paths lead to your domain controllers.

Fixing this is very easy and very safe. Open ADUC, enable advanced features, locate each DC, right click, properties, security, advanced, then "Change". Change the owner of each DC to the Domain Admins group

Issue #2: Privileged kerberoastable users. @TimMedin's original research is still paying huge dividends for red teamers, but it can be tricky for a defender to tackle this because AD makes it impossible to empirically determine the privilege of any user, so you can't prioritize.

This is another *extraordinarily dangerous* configuration. Using FOSS #BloodHound, we can find the most dangerous kerberoastable users with this query:

MATCH p = shortestPath((u:User {hasspn:true})-[*1..]->(g:Group)) WHERE g.objectid ENDS WITH '-512' RETURN p LIMIT 100

Again, we get a nice visual to help us understand the attack path possibilities. Each starting user node in this visual is a kerberoastable user:

Fixing this issue for each user is more involved, but boils down to two options:

Option 1: Make sure the user has a very strong password (64 random characters)
Option 2: Remove the SPN from the user and configure the associated service to auth with a computer account instead.

Issue 3: Domain Users group and other large groups having control of other objects. Instances where the Domain Users, Everyone, and Authenticated Users principals have any kind of privilege serves as a jumping-off point for an attack path.

Needless to say, these configurations are very dangerous, and usually very easy to remediate. With FOSS #BloodHound we can find all instances of the Domain Users group having control of another principal in two ways:

We can either look up the group in the GUI and click "Outbound Object Control":

Or we can do some cypher to bring up all other instances (if you're running multiple AD domains, for example):

MATCH p = (g:Group)-[{isacl:true}]->(m)
WHERE g.objectid ENDS WITH '-513'
RETURN p

Fixing this is issue is similar to the first issue described above. Find the affected object in ADUC, bring up its security descriptor, and remove the offending ACE where the "Domain Users" group is the identity reference.

You can use FOSS #BloodHound to find these very dangerous configurations. #BloodHoundEnterprise goes further by automatically surfacing issues like these (and a lot more), and calculating the attack path impact for you so you can prioritize and track remediations

You can find out more about #BloodHoundEnterprise and request a demo and trial here: bloodhoundenterprise.io

You can learn more tips on using FOSS #BloodHound for defense here: posts.specterops.io/bloodhound/home