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

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Andrew Robbins

Andrew Robbins Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @_wald0

12 Sep
At a high level, what security-related strategies and policies should Microsoft employ over the next ten years? Here are my ideas, but I want to know what you think as well: 🧵
Number one: take radical ownership over customer security outcomes. Microsoft is already doing this with the introduction of built-in safety rails in Azure. But there’s much more opportunity here:
Historically, Microsoft has made all the tools available to admins to secure their networks: Windows firewall, device guard, application guard, etc. A well-resourced, well-financed admin can make an AD domain *amazingly secure*. But most do not.
Read 16 tweets
11 Aug
(1/6) One of the most powerful and valuable aspects of a red team assessment is its ability to cut straight through any pre-existing notions of a network's security posture. 🧵
(2/6) The facts of a devastating attack path, well-executed, cut through egos, politics, ineffective operational momentum, and spell it out very plainly for everyone to see: the red team got in, took control of everything, and you couldn't stop them.
(3/6) Getting your teeth kicked in like that hurts, but professional red teams know how to turn that pain into value for the customer, and help them see it as an opportunity to improve.
Read 6 tweets
20 Jun
It's time to stop ignoring prevention. A thread:
Point #1: Red teamers know how year after year the same tools and methodologies can be used to take over almost any organization running Active Directory. Sometimes even the same exact attack path steps find their way into reports year after year.
We shouldn't be satisfied with doing the same attacks against our clients for years (even decades) and collecting paychecks - what exactly is the point of all this tailchasing if things aren't getting better?
Read 11 tweets
13 May
(1/n) The other day, @JulioUrena asked a great question in the BloodHound Slack:

"How can I determine which Group Policies apply to members of a certain group?"

We can use #BloodHound to answer this question, but I want to explain the moving pieces here as well
(2/n) Group Policy can't be applied directly to security groups, except when using SID filtering and linking the Group Policy correctly. SID filtering on GPOs is not very common, so #BloodHound doesn't currently model that.

We can still use #BloodHound to figure this out though
(3/n) Take for example this security group -- real data so labels are hidden (left CTRL in BloodHound GUI). This group has 7 users in it, but because it has a group added to it...
Read 8 tweets
9 Mar
I am thrilled to announce #BloodHoundEnterprise, which will be released in Summer of 2021!

Learn more: specterops.io/bloodhound-ent…
View our announcement webinar: specterops.zoom.us/webinar/regist…

A thread of major points about BloodHound Enterprise: Image
Once an attacker has access to Active Directory, it's virtually guaranteed they can find an attack path resulting in the compromise of a Tier 0 asset (Domain Admin). Owning Tier 0 means owning AD. Owning AD means owning the organization, all its data, users, processes, etc.
The scale, availability, and growth of those attack paths has exposed an enormous gap in how we try to secure Active Directory today. Organizations try (and fail) to fill that gap with technologies, products, and processes.
Read 9 tweets
26 Sep 20
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.
Read 8 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(