All right. Welcome to track one. Um, hopefully some of y'all are Windows domain admins
because this talk should be interesting to you. You should pay attention. Um, with that,
here they are. Thanks, Flukted. So I want to make sure I got the right mic.
Can the people in the back hear me okay? Awesome. Thank you. So we are talking about six degrees
of domain admin. If you're not familiar with this phrase, there's a very common, uh, game in
the, like, like film geek world called six degrees of Kevin Bacon, where you can take any
actor, any, uh, director, any movie, and just by making six connections, you can find a way to go
to Kevin Bacon. I don't know why it's Kevin Bacon. That's what it is. So we have found a way
to do that in an active directory environment.
Uh, and domain admin is the most obvious target, so that's what we selected. Is there a little
bit of feedback? Maybe we should back off a little bit. Okay. About us. My name is Andy Robbins.
I've been a professional penetration tester and red teamer for four years. I originally cut my
teeth in the financial services industry. Uh, I would really love to talk to you about ACH files
if you're interested in talking about that. Uh, all three of us work at Varus Group's Adaptive
Threat Division.
Uh, with that, I will pass it over to Rohan. Hi. I'm, uh, Rohan Vazirkar. Uh, I'm another
pres- I'm another penetration tester at Varus Group. I've been, uh, doing penetration testing for
about two and a half years. I work on a lot of, uh, open source projects, and I was responsible
for the web UI for this one. Hi. My name is Will Schrader. My handle is Harmjoy. I'm a researcher
at the Adaptive Threat Division, and I've built a, uh, a good number of our offensive kind of
tool sets that we've used over the last couple of years, most notably PowerShell Empire and also
PowerView, which kind of acts as the data collection component for Bloodhound. Any PowerView users
in the room? Lots of you. Awesome. Yeah, give Will a hand. Give Will a hand for PowerView.
Yeah. And also, this is their first time here at DEF CON, so give them a hand, too, real quick.
It's their first time speaking. All right. So, uh, I've been working on a lot of, uh, web
work for them. I've been working on a lot of, uh, web development projects, and they've been
working on another thing, uh, called Active Directory Domain Privilege Escalation. Uh, first
of all, I wanna, uh, talk about this quote a little bit. This was stated by John Lambert. He's
a general manager at Microsoft's Threat Intelligence Center. John said, defenders think in
lists, attackers think in graphs. As long as this is true, attackers will win. There's a great
blog post where John goes into some depth about what this
concept means effectively. What I hope that we can show you is
that not only are we gonna start thinking in graphs, we're gonna
start using them practically to automate a lot of our work. So
first of all, with, with Active Directory domain privilege
escalation, Active Directory is effective, effectively
ubiquitous. In Sean Metcalf's talk, he stated that the Fortune
500 in the United States, more than 90 or more than 95% of
organizations use Active Directory. To the people in this
room, that's probably a given. But what does that ubiquity
actually mean in the real world? That ubiquity means that Active
Directory is a subject of a lot of attention, not only
from defenders, but also from attackers. So that means that
there is a lot of time, energy, money, blood, sweat,
tears, going into learning how to best defend Active
Directory environments and also how to attack them.
As penetration testers and red teamers, we have the benefit of
every so often getting these nice, easy buttons that make us
look like leet hacksaws because we use the right module to
basically do like a point click escalate writes. MS 08067, MS
1468, Kitrapod, GPP, the list goes on. What's the problem with
these easy buttons? The problem is that they are ephemeral. They
have a tendency to go away.
Especially over the past four or five years, enterprises, at
least in the United States, have started paying attention to a
lot of the things that people in this room have been saying for a
long time. Do patch management. Run vulnerability scanners.
Audit the results of those vulnerability scanners. So those
vulnerability management practices are getting more
mature. That means that when you land into an environment and
they have that kind of maturity, those easy buttons may
not necessarily be available to you. So let's look at the
other side of this in a visual way. We have an example of a very
simple Active Directory environment where we have 16
computers. Now, let's say this red computer is kind of our
initial access. Maybe it's Cobalt Strike Beacon. Maybe it's
Meterpreter. Maybe we're a malicious insider and we just
have access to Active Directory. Bottom line, we have
authenticated access to AD. Now, thanks to Will's work with
Power View, it's very easy to identify systems that a domain
admin is logged on to. In fact, you can, to be honest, you can
typically find out where everybody in the environment is
logged on to, which will be very important later. So let's
say we identify this is the box where the domain admin is logged
on. Now, this client organization that you're in,
they don't have the best patch management. They don't have the
best vulnerability management. So you escalate rights on this
one initial machine. You dump the NCLM hash for the red 500
system. They've applied KB2871997, but they haven't
disabled the local admin account. What does that mean for
you? That means that all these computers all of a sudden light
up and now you have kind of notional administrator access to
them, including the box that the domain admin is logged on to. So
you use your favorite pivot method, maybe PSExec or WMI. You
pivot over to the box the domain admin is logged on to. You
run memecats. You get the password. Now you have access to
the entire environment. Awesome. Who has executed an attack path
exactly like that like a billion times? Most everybody. Let's
click, let's take a look at a, a slightly different version of
this. A different example. So in this environment, the client
actually does have proper patch management and vulnerability
management programs. So you're not gonna be able to find MS 0867.
You're not gonna find MS 1468. You're not gonna find GPP
creds. However, in our experience, 99 times out of 100,
we are able to gain some kind of initial privilege access into an
environment. Most typically, this actually happens with
clear text credentials that are in a file share that anybody
who's authenticated to AD can use, can, can, can use. So
you can view and read. Uh, log on scripts are probably the, the
most obvious example. So let's say that we find one of those
credentials and, uh, okay, so first of all, we found the DA.
He was logged on. He's in the same box. We use those
credentials and we identify systems that we now kind of have
a notional or prov, provisional administrator access to. We
find these three boxes and we find out who the three people
are who are logged on to those systems. Unfortunately for us,
none of those people are a domain admin. Additional
information, none of those users have administrator rights
to the box that the domain admin is logged on to. So we have this
kind of missing link that we have to identify. Typically what
we do is we co, go into this kind of credential dance or what
Microsoft re, referred to in 2009 as an identity snowball
attack. So what does that mean? That means that we have to
choose one of these systems to pivot to. You can use manual
analysis to try to figure out what system that is, but
eventually you're just gonna have to guess. So let's say
that we pivot to this machine up here in the top left. We get
this guy's credential, we do the same thing. We figure out what
systems does this guy have admin rights to. Okay, now we have
some new boxes. However, again, not a DA. And again, none of
those users have admin rights in the system the DA is logged on
to. So again, we have to guess. So let's take our best guess and
we say that maybe this guy is part of a help desk group. That
sounds like a pretty good group. Like, probably has some high
privilege. So we pivot to this box, run them a
cats, get his credential, and then we find out this guy doesn't
have any more rights in the environment than what we already
have. Hate that. So we have to go back. We have to go back to
the system in the top left. We have to make another guess. Let's
say we go to this system. We run them a cats again. We get
this guy's cred. And then lo and behold, who should appear but
the domain admin in the systems that we have this kind of
notional administrator privilege to now that we've gone two hops
away from where we originally started. We pivot to the DA.
We run them a cats. Now we have admin rights in the entire
environment. Who's in an attack path like this? Or who's read a
report where credential abuse is, uh, used in that kind of
attack path? A lot of you. Cool. We refer to this attack or
this methodology as derivative local administrator. Justin
Warner, uh, who on Twitter you can find at 6dub, he defines
this as the chaining or linking of administrator rights through
compromising other privileged accounts.
Uh, at MSRC in 2009, Alice Zhang and John Dunnigan put a
great white paper out, uh, about a method or a capability
that they had called heat ray that goes into very extreme
detail about how they, uh, kind of understood this process
as well. Highly recommend that you go read that white paper. So
let's look at this a little bit simpler. Let's say we have this
user Bob. Bob has admin rights to PC1. On PC1 is this user named
Mary who is logged on.
Mary has administrator rights to PC2. Bob derives administrator
privileges to PC2 via stealing Mary's credential. Make sense?
Cool. How else can this happen? This can also happen with active
directory group delegation. When you add a user to a group,
that user gets all the privileges of that group. When
you add a group to a group, that Nessa group gets all the
privileges of that group. Let's say Bob is a member of this
group called helpdesk. Bob is a member of this group called helpdesk.
Helpdesk is a member of a group called server admins. Server
admins has admin rights to PC2. See a lot of nodding heads. Like
this is, this is pretty good. This is pretty basic stuff. This
is what the entire, uh, methodology or the entire core
of Bloodhound is based on, is this concept of derivative local
admin. So derivative local admin is extremely... Sorry about that.
Derivative local admin is an extremely effective attack. But
it has some, uh, very serious, uh, setbacks and challenges that
we need to be, uh, aware of. First of all, it's extremely
time consuming and it's extremely tedious work. If
you've gone through the process of manually, uh, going through
this method, uh, you understand this very well. You have a, uh,
uh, a complexity override, essentially, of where each step
you go, the, the analysis steps that you have to do grow
exponentially. Uh, next, it's not comprehensive. So, imagine
the difference between taking a report to your client, or as a
client, getting a report from a pen test firm. Imagine the
difference between reading, this is one attack path that we
identified in your environment, versus here are all of the
attack paths in your environment. Okay? Next, you have
limited situational awareness. You may not even understand, you
may not have the ability to understand what kind of privilege
you currently have in whatever user context you're running in.
Finally, the last thing I will say is, did you even need DA? Uh,
if your target is, like, an HR system, it's gonna be simple to
escalate to DA and then go back down to the system that you
actually need. But you may not have even had to go through this
rigmarole of escalating DA in the first place. All right. We're
gonna talk about graph theory. I'm gonna take a drink of water
real quick.
Graph theory has been the missing link, uh, in this
process, uh, that has been keeping us from automating the
entire process. I highly recommend you look at the
history of graph theory with Leonard Euler using it to
disprove, or to prove that there was no solution, no
solution to the seven bridges of Konigsberg problem. Super
interesting stuff. We're also gonna look at the, uh, design of
our attack graph.
So the basic
elements of a graph. First of all, a graph is, is not
necessarily just a visual thing. A graph is a construct of a
discrete branch of mathematics called graph theory. So in a
graph, you have vertices or nodes. Vertices are used to
represent a basic individual element of the system that
you're representing. If this is Google Maps, then a vertex may
represent a city or an intersection. Edges are used to
represent relationships between these
vertices. If Seattle, Washington is a vertex and
Portland, Oregon is a vertex, then interstate five can be
thought of as an edge that connects those two cities.
Finally, paths, the most crucial part of graphs. Paths are
used to connect otherwise disparate nodes regardless of
how far away they are from each other. This is where the key
difference between a graph and a relational database comes into
play, uh, which we'll talk about later. Here's a visual way to
way to look at the same thing. So here's a very simple graph. We have two vertices and
we have an edge. This is a directed edge or it's one way. You can think of it as a one
way street. You can go from vertex 1 to vertex 2, but you can't go the other way. Paths.
Can you see a path from vertex 1 to vertex 4? Yeah. Is there a path from vertex 3 to
vertex 4? No, because you would have to go the wrong way against a directed edge. So after a
lot of false starts, we finally landed on a attack graph design that works. And here's how it
looks. The vertices are used to represent users, groups, computers, and domains in Active
Directory. The edges identify the relationships between those. So this means admin rights,
group membership, user sessions, and domain trust.
Finally, paths always lead towards escalating rights. Period. Always. This makes writing our
pathfinding queries very, very simple. Again, let's look at this visually. Like I said, users.
We have two users in this graph. Bob and Mary. Groups. We have two groups in this graph. IT
admins and domain admins. Computers. We have one computer, server 1. First, let's identify
group memberships. We find out that we have two groups in this graph. First, let's identify group
memberships. We find out that Bob is a member of this group called IT admins. And we find out that
Mary is a member of this group called domain admins. Next, we figure out privilege. Who has
admin rights where? This group called IT admins has administrator rights on this computer called
server 1. Finally, let's find out where people are logged on. We find out that Mary is logged on
to computer 1. Or put another way, computer 1 has a session for this user. Is there a path from
Bob to domain admins?
Yeah. Bob is a member of IT admins. IT admins has rights to computer server 1. Server 1 has Mary
logged on. She's a domain admin. We've got our path. This is the core fundamental concept for
Bloodhound. Let's put this very simply. In order to use a graph, you need to populate it with
data. What data do we need? Who's logged on where? Who has admin rights where? What users and
groups are part of what groups? That's it. That's all we need. Will is gonna take over now and
he's gonna talk about how we actually do this data collection. Cool. Alright, so I'm
gonna go over some stealthy data collection with Power View. I'll let you guys read this
quote. This was, uh, extremely kind of weird for me. We obviously do not advocate the
malicious usage of our tool sets, but, you know, uh, what can you do? So we have our little, uh,
puppet Phineas Fisher up there. So, Power View. We saw some Power View users in the audience.
Power View is a PowerShell 2.0 compatible domain and network situational awareness tool. I
started writing this a couple of years ago to automate a lot of the offensive and some defensive
tradecraft that we execute on engagements. It's completely self-contained. It's a single PS1
PowerShell script. It can be loaded into memory. There's no code. It's just a single, single, single,
no external dependencies. Nothing has to be added to the machine. Power View collects the
data the Bloodhound is built on. What's really cool is that in most cases you do not need any
kind of elevated domain access to gather this information. And I'll go over the different
components here in a second. So just as a domain-authenticated user, you do need a session
like that, but no privileges at all. Just in domain users, the parent group, you can collect a
huge amount of information from Active Directory through a couple of different ways.
So, Andy mentioned the three components of information we needed. The first is who's logged on
where. We refer to this as user hunting. So the main function in Power View that does this is
invoke user hunter. It was one of the first ones written. It's an extremely common one that
people tend to run. It utilizes a couple of Win32 API calls under the hood, the most useful
being net session and num, to where you can point these functions to remote systems and figure
out who has sessions established with that remote box. Again, it's a very simple process. You
don't have to have administrative rights on that remote system. So you can run this against a
domain control or a file server and get a really nice mapping about who's logged in where.
There's also a stealth option. By default, invoke user hunter will enumerate all machines in the
domain and run these enumeration actions against every single machine. This can be extremely
noisy in some contexts if anyone's doing internal network-based monitoring, but it gives us a
more complete data set. With stealth, we use a couple of tricks to where we enumerate
all user objects and we try to pull out properties that may indicate highly trafficked file
servers, something like profile path and collect all those things in and run a net session enum
against each system. So it's much faster, but we don't get quite as accurate data. Next, who can
admin what? This is the craziest thing to me. I love this. So as an unprivileged user, we can
enumerate the members of a local group on a remote machine without needing administrator
privileges on that remote machine. I didn't, there was a
couple of tools out there that did this. I weaponized it up in PowerView and we use this
function specifically on almost every single engagement. There's two ways you can do this. You
can use the WinNT service provider, which is a remnant of NT domain deployments, and you can
also use this particular net local group member's call. Just point it to remote server and it
happily gives you back who the members of local administrators are, their domain SID, whether
they're a group or user. The function in PowerView that does this is get a local group. You
just pass in an IP, a NIP IP address, and you're good to go. You can also use this function to
call a computer, a BIOS name, or a computer name. If you would like to use the API call, you can
do the dash API flag. By default it does the Win32, the Win32 provider. We also have a kind of
different new kind of method to do this, to gather the same information. So I worked last year
with Sean Metcalf about how to kind of structure this approach. Group policy objects are
just collections of settings that are applied to computers. One of, some of these settings are
who are in the local administrator's group for a particular machine. This is either the
restricted group or group policy preferences. GPOs are linked to OUs and sites. So if we
enumerate all the GPOs and we enumerate all the other domain containers and do a little bit of
correlation magic in the back end, we can get a mapping of who can administer what machines
through GPO object modification. Now, this is not going to be as accurate because you're not
touching every machine and you're not, so if somebody specifically adds a local user to a
machine, it won't show up in this method. But what's really cool about this is that you can do a
mapping of every machine. And what's really cool in this approach is that you're only
communicating with the domain controller through LDAP. You're not seeing, sending a single
packet to any other machine. The power view function for this is find GPO location. By
default it'll just give you a nice raw mapping of everyone who can administer what machines
through group policy object correlation. The last part, who's in what groups. This is the
easiest. We just enumerate all the groups through LDAP and pull out all the members of each.
Power view is just get net group, pipe to get net group member. This is the power shell
pipeline. What's really neat about this is it'll pass fully serialized objects between all the
different functions you're running. So it's super, super easy. We do some kind of variation of
this in almost every engagement as well. And that's it. So let's bring it all together. There's
a customized version of power view that is integrated with Bloodhound. It has all the stock
power view commandlets along with a couple of extra features. Get tacked Bloodhound data will
automate the gathering of power view data on a domain. By default it'll only gather the data on
the current domain. But it'll get the trust, group memberships and all these things that we
talked about. There's a lot of different targeting options. If you want to use stealth there's
dash stealth and things like that. You then take that function and you pipe it to one of two
export functions. Export Bloodhound data will export all those custom objects, um, package them
up with cypher queries for Neo4j which is what it uses on the back end. And then shuttle
everything off to the Neo4j back end. And then you can get all the data that you need from the
batch restful API ingestion interface. So if the collection machine can reach the analysis
machine whether on the same domain or through a something like a reverse port forward which we
have done in the field and it does work. Then you can just shoot this stuff straight into
Neo4j and then Bloodhound without touching disk. If you can't reach the analysis server for
some reason you can pipe that get tacked Bloodhound data to export Bloodhound CSV which will
take all those same, all those same custom objects and export them into a batch restful API ingestion
to a three or four different kind of custom CSV files. We have a particular format which we've
documented. The CSV files can then be ingested offline into the Bloodhound analysis interface.
Okay, now Rohan is going to go through a live demo of Bloodhound. Okay, so we're going to
go through a live demo of Bloodhound. Alright, so. Uh oh. I'm not, I'm not trying to hide it
from you I promise. Gonna mirror the screen. Alright, perfect. So when you first fire up the
Bloodhound UI you're presented with one of our favorite views which is what are the domain
admins inside the environment you're in and who are the members of these do, these groups?
Generally speaking when we're in, in uh assessment we tend to target domain admins a lot as we
talked about earlier. Uh they pretty much have keys to the kingdom and usually whatever target
we're going after one of them is going to be able to get to it. Any node that is in the
environment can be auto completed using the search bar up here so it'll help you find stuff you need.
We're gonna actually start with that. Okay. But first we're gonna go ahead and start with the an
with a user. Any user you click on is gonna present you with a
bunch of information about that user here. So the first thing we
can see is first degree group membership. These are all the
groups that our user is part of by default. The next thing you
can see is unrolled group membership. Now a lot of times
this is actually kind of a pain to enumerate properly. Uh
especially when groups get really really nested like the
one you see here. The next thing we can look at is group
delegated admin rights. If this user was added to the local
admins of any machine explicitly that would be here. But because
we're not we're just gonna look here. This is every single
system that this user has access to based on their group
membership. Now to keep the graph a little bit more readable
we do a lot of collapsing of nodes. So if you can see there's
an 87 next to domain admins node here. Slow down. Alright.
There are 87 other computers. I can't slow down sorry.
There are 87 computers that are folded into the domain admins
group. Now if we displayed all of these the graph as it gets
bigger and bigger takes longer and longer to lay out. So this
is more of a performance thing. Any node that is collapsed in you
can actually expand by right clicking on it and hitting
expand. Which I'm not gonna do cause it'll totally break the
graph. So in this in this uh one more thing you can look at is
derivative local admin rights which is what we were talking
about earlier. Now this graph here is showing from our user
any path that this user has access to. So this graph here is
a graph that this user can take to get to any other computer in
the environment. Whether it's through group membership,
through local admin rights or sessions of users that are
logged into computers which you have admin rights to. Now
navigating this graph can be a little difficult and there's a
lot of nodes here so we introduce a feature called spotlight.
Using spotlight you can search the graph you're currently on for
any nodes. So we're gonna look for this research group here.
Whenever you click on the spotlight it'll zoom in on the
nodes so you know where it is on the graph and it'll pull up a
lot of information on the left so you can start interacting with
it. Move it around, here we go. So there you go. It's a node,
ooh. You can ask Bloodhound to give you who the direct members
of any gr-group are. You can see there's four more that are
folded here. We can expand this and you'll see that these are
users. The next thing you can ask Bloodhound to give you is the
unrolled group members of a group. As groups start getting
nested it becomes more and more difficult to find uh who the real
members are. So you can ask Bloodhound to give you who the
direct members are. So Bloodhound makes it really easy
to do that. You can also ask Bloodhound what direct
administration rights a group has. So we expand this you can
see there's 28 different computers that this group has
direct admin to. Just like with a user you can calculate derivative
local admin rights. Uh it'll use wherever you start and it will
try any path it can find to any other node in the domain. Another
really handy feature we have is sessions. Uh using this you can
ask Bloodhound to tell you where every single user that is a part
of either the group or subgroups is logged in. A lot of times when
you're on an assessment you know that there's a specific group
that users belong to and that group is where you're targeting
your crown jewels. Let's say it's an HR group and you're
trying to access their information. With Bloodhound you
can ask where are all the HR members logged in and it'll give
give you every single computer that it has a session for. Now
on this group we're gonna find ourselves a computer uh SQL 2.
We'll pretend like this is something cool here. You can
ask Bloodhound who the explicit admins for a computer are. These
are first degree admins. So if you run net local group
administrator on a system this is the output you'd get. You can
also unroll the admins on a computer. In this particular case
there are six groups that have local admin on this system.
However once you unroll it it becomes 51 users with
administrative rights. As Active Directory domains expand the
and they keep getting more and more things inside of them.
Groups can get nested. Uh you can easily lose track of who's
admin on a system because of nested groups just continuing to
obscure what you're looking for. One thing I would add to that
is this example is showing an order of magnitude difference
between who is explicitly defined as an admin on the
system versus who gains admin rights through these nested
groups. And that kind of difference in an order of
magnitude we see is very very common on almost every
assessment that we go into.
You can ask Bloodhound to give you the sessions for
computer who's logged onto there. It's extra information that's
always handy. And just like with a group or a user you can
ask Bloodhound to calculate the derivative local admin rights
provided you started from that computer. Now getting into one
of the most powerful features of Bloodhound we're gonna talk
about pathfinding. Bloodhound provides you the ability to find
a path between any one node and any other node provided that
path exists in your database.
So just to give us give you guys an example to start we're
gonna pick a user uh Jay Druin and we're gonna ask Bloodhound to
take us to the domain admins group. Now watch go walking
through this path Jay Druin is a member of a group information
technology. Information technology has local admin
rights to all these systems here. Each one of those systems
has a user session for a domain admin. So if you jump to these
systems and Mimikatz you would have the password for a domain
admin. Now that's a that's a
cool example but let's let's amp it up a little bit. We're
gonna take this user Jay Nickel at external dot local and we're
actually gonna ask Bloodhound to take us to domain admins at
internal dot local. Now internal dot local and external
dot local are two different domains in the same forest. So
if you follow this path our user is a member of a group which is
a member of another group which gets us admin rights to several
systems. We can steal a session from one of those systems and
get access to a different group membership. That takes us to
another system with a user in external dot local. However the
next hop is in the internal dot local domain. Despite the fact
that we're jumping a trust boundary between two two
domains Bloodhound just is using the data available to it and it
has no problem enumerating these paths. No matter how
complicated the path is if the path exists Bloodhound will be
able to enumerate that path properly. So one one thing that
I would add to that a common question that we've been getting
over the past week when we're publicly demoing Bloodhound for
the first time is with regard to scalability. So we went into an
environment that had two hundred thousand computers. Windows
workstations and servers. They had about ninety thousand users.
They had about seventy five thousand groups. Tracking all
that information manually is just not possible. So they also
had more than seventy five domains I would say in a in a
forest with varying degrees of trust. With the stealth option
that Will talked about with ingestion it took us about
twenty to thirty minutes to collect all the information we
needed from these this global enterprise to identify attack
paths. Doing the query with Neo4j and a graph database is
just as fast as what you're seeing here. In that environment
I'm talking about with two hundred thousand computers more
than seventy five domains Bloodhound found us an attack
path to go from this one this tiny little domain that was
relatively insecure to this very high security domain where
our actual objective was. Crossed six domain
cross boundaries. Taking advantage of users that had
relatively low privilege. Like four machines that they were
admins on. But it just so happened that that one of those
machines had a user that gave us more more privilege in the
environment until we got to what we needed. Uh the thanks.
Thank you. Uh one additional thing that I would say is I
mentioned the stealth option took about thirty minutes. If
you're gonna do non stealth and you're actually touching each
system one time that ingestion takes between twenty four and
thirty six hours. For that level. For that level of
environment two hundred thousand systems. Alright so just
demonstrating some more stuff that we've built in to make this
even easier to use for everybody. We have several
pre-built queries that you can access through the UI. Uh there
are some really good ones here like finding the user with the
most sessions. Let's go ahead and identify which user is logging in
way way way too much. In this particular case it's antivirus.
Which is sort of okay but if I get that account I'm gonna be
pretty happy. You can also find the computer with the most
sessions. This is demonstrating things that tend to be used a
lot such as IT jump boxes or terminal servers. These are high
value targets that if you compromise them you're very
likely you're gonna get a large set of credentials. You can also
hit control here to show all the node labels. And then you can
hide them all. Or you can just show the default. Uh these are
just de- these are just display options to help you whenever
you're showing these to other people. Another thing that was
added very recently and when I say recently I mean last night.
Was the ability to query any user in a domain of your choice
and find what foreign group relationships they have in other
domains. Historically this has been a very tedious and time
consuming task. So in this particular case querying the
internal dot local domain. And then you can hide them all. Or
you can even remove them from your domain. That's because in
that's not my domain. We're given three users that are
members of groups in the external dot local domain.
Another query we can do and this is one of our favorites. Is
find shortest paths to domain admins. When you click on this
you get a selection. Which domain admin group do you want to
use? So let's say we wanted to use internal dot local. What
you're seeing here on this graph is every single possible path
that Bloodhound can find to go from any node in that domain up
to the domain admins group.
Now, when we were talking about earlier showing all the paths to your client, this is what
we're talking about here. It's really great because you can look at high value targets that
if you remediated would actually cut off a lot of points. For example, this node here, you
can see has several connections out to it. If you were to go and lock down that computer,
you'd significantly reduce the attack surface of that domain. Now, any graph that you
generate in Bloodhound can be exported either to JSON or an image. Uh, you can export it to
JSON and load that into other graph tools, or you can re-import it back into Bloodhound if you
have some particular graphs that you like saved. You can export it to an image and throw that
directly in your out brief. It's great value to show your clients. It looks really, really
cool. And everybody likes pretty pictures, so. As Will was talking about earlier, you can
export all the Bloodhound data instead of directly to the database through the CSV
ingestion here. When you click this, you can just pop, give it a file, and uh, it'll ingest
everything you want. So, uh, you can export all the data directly to the database through the
CSV ingestion. You can export everything exactly the same way as if it was from the PowerShell
script itself. This is great for a lot of situations where, for whatever reason, your host that
you're running your ingestion from can't talk back to your database. Let's say there's really
good firewall rules. Uh, you can just download the CSVs directly from the host and throw them
into the web interface and you're good to go, just like before. I think that's the whole demo.
Thank you. So, we have ten minutes left. Uh, one thing that I would like to briefly touch on that
we skipped, uh, is kind of the architecture of Bloodhound because there are some very important
other open source projects that Bloodhound relies on. Uh, first of all, Linkurious.js is the open source and
free version of Linkurious. If you are developing a web frontend like this to interface it with
Neo4j, Linkurious is where you want to go. It's built on top of Sigma, so you have all these things
kind of abstracted away from you that are otherwise very difficult if you're not a JavaScript
expert. Secondly, it's compiled with Electron, so it is cross-platform. Um, and then most
importantly, we rely on Neo4j as our graph database. Uh, and then obviously it's fed by the
PowerShell ingester. So, um, I'm going to talk a little bit more about how we're going to
do this. Uh, this is the part that Rohan's been waiting for. Alright, let's do, let's do this.
So, we have here the, uh, Bloodhound repository, which to this moment has been private. And,
uh, we're just going to go ahead and, uh, yolo this right now. Uh-oh, this is bad.
I'm going to have to login to GitHub. I just ruined everything. Andy,
why didn't you make me check this. . That's okay. This is
why I use two-factor, right? Yeah, so while Rohan is doing this, the license that we are
releasing this under is GPLv3. I'm good. I'm not afraid of these people. Once we get
done with this. Okay here we go. Alright and there we go. It's public I promise.
So we have a nice easy link. Get your phone out. Take a picture. Bit.ly forward slash get
bloodhound. Uh you can find me on Twitter. Again my name is Andy Robbins. My handle on
Twitter is at underscore Waldo with a zero. Rohan. Oh go back. Sorry. Sorry. There you go.
Alright 10, 9, 8, 7, 6, 5, 4, 3, 2, 1. Get it from your neighbor. Socialize. Professional
network.
Meet somebody. Please. My name is Andy Robbins. You can find me at underscore Waldo
with a zero. Rohan Vazirkar. You can find him on Twitter at Captain Jesus. Will Schroeder.
You're already following him on Twitter at Harmjoy with a zero. Thank you very much.
By the way we decided to be really nice to you and we have pre-compiled binaries for every OS
and architecture so.
Thank you.
So I think we have 5 minutes for questions and this gentleman is first. Can you speak into the mic? I
don't know if it's on. There you go. You're good. Oh there we go. Big one is you have Git
sessions so it's. Get like get right in there. Yeah. Big one is you have Git sessions so live
data. They have to be logged in to see the path. That okay so his his question was with user
session information. You got a second question as well. Tied into that. So you have current sessions.
To do your jump. Do we have what? You have your current session to do your jump. Logged in users.
What about past the hash of a local admin hash to jump? Does Bloodhound take that? Or local hash
match to domain. Where you can take. Okay. Matching hash and jump. Okay so his question is with
user session information. When we're collecting user session data. The user needs to have a valid
session. That is uh currently like uh with uh a domain controller or a file share. Uh so you're
you may find yourself recollecting user session information uh frequently because of the the the
nature of how that works. Your second question was with local accounts with RID 500 with past the
hash. Right now we are only tracking domain accounts. We are not tracking local accounts at
all. Uh but we may put that in in the future. Is it jump from local up to domain with matching
hash? Oh is it okay so also the question of like reuse passwords from like a local
local admin that has the same password or NTLM hash as a DA. We're also not tracking that as
well. Uh you should check out a project called Auto Dane uh from SensePost. Uh that may have
what you're looking for. Yeah. Thank you. Thank you for the question. Hi. Do you account for
stuff like uh laps being rolled out into the environment? So the the question was do we account
for laps being passed up being distributed through the environment? Uh that we also do not
account for. So any kind of
like credential uh sharing against systems or uh as a matter of fact a better answer to your
question is this was born out of a necessity to bypass laps protections because we couldn't pass
the hash of a local admin account. We had to rely on domain user level accounts. And I'll also
say that we have a couple things going forward we want to integrate. One of those will be active
directory ACL enumeration and auditing. Yeah. So it'll automatically in a few months when we
finish ex ex extending it. Yeah. So it'll automatically in a few months when we finish
extending the schema we will ingest all active directory ACLs into the graph and everything will
be integrated. So you might be able to tell who has read access to the password attribute for
laps and then integrate that into the attack graph. Yep. Awesome. Thank you. Thanks for the
question. Hey. Thanks guys. Um how are you handling how this stuff changes over time? Okay.
So the date. Yeah. So the the question is how do we handle this data as it changes over time?
Excellent question. So we treat uh local uh uh uh uh local uh uh uh uh local uh local uh local uh
local admin privileges and group memberships as relatively static information that it doesn't
change that much day to day. User session information we treat as relatively dynamic. So in
our in our wiki we provide guidance on how you can re-ingest just session information.
Additionally we're planning on adding temporal information to the user session edges. So what
that means is that if you're an incident handler and you want to go back and you say we had an
initial breach on March 16th. I can tell Bloodhound go back to your browser and look at your
browser and go back to March 16th. Tell me from this computer to every other system in the
environment based on the currently logged on users that I could get info for. Show me what from
patient zero what was possible and so that I can more clearly define my investigative scope.
That brings me to another point is that um from the offensive side this is really cool and we
like it a lot. What's really cool is the defensive applications. And so over the next six
months to the next year uh we're going to be focusing primarily almost exclusively on
defensive applications like that. Thanks. So more and more often the uh people that I'm
popping end up using Macs. So while obviously their computers aren't joined to the domain many
times they have valid LDAP credentials. Is there a way I can use those valid LDAP credentials
with Bloodhound somehow? Uh yes um so in our wiki we have a section about uh data ingestion with
other tools. So right now we're talking with uh Bytebleeder the author of CrackMap Exec uh to get
support for other tools like that. So if you're in OSX if you're in Linux you want to collect
information you don't want to be running in PowerShell or running on Windows. Uh we're planning
on getting that in there as well. We have developer notes about the CSV format and how to
actually get info into the Neo4j graph database. And we're going to have to leave in a
second. Thanks for the question. How much time do we have? Wow. One more one more question.
Great. What are the uh top three things you can use for defense to help you with everybody to do? So your
question was what are the top three things Bloodhound can do for defense? So I would say that
uh number one would be mitigating the attack paths that rely on derivative local admin. So in the
Microsoft white paper they the product that they're describing the MSRC developed is called
HeatRay. They use graph theory and they also use machine learning to give an IT admin a list of
like here are the ten changes that you can make in the environment that will most efficiently
eliminate the largest number of attack paths based on credential abuse. Uh secondly I would say that
one of the major benefits is a more uh clear and easy understanding of nested group
memberships and how those relate to local administrator privileges. Uh and then number three
let's let's talk offline. We have to go. Thank you again. Thank you. Thanks.