Six Degrees of Domain Admin
Robbins, Andy
Vazarkar, Rohan
Schroeder, Will
Active Directory domain privilege escalation is a critical component of most penetration tests and red team assessments, but standard methodology dictates a manual and often tedious process – gather credentials, analyze new systems we now have admin rights on, pivot, and repeat until we reach our objective. Then — and only then — we can look back and see the path we took in its entirety. But that may not be the only, nor shortest path we could have taken. By combining our concept of derivative admin (the chaining or linking of administrative rights), existing tools, and graph theory, we can reveal the hidden and unintended relationships in Active Directory domains. Bob is an admin on Steve’s system, and Steve is an admin on Mary’s system; therefore, Bob is effectively (and perhaps unintentionally) an admin on Mary’s system. While existing tools such as Nmap, PowerView, CrackMapExec, and others can gather much of the information needed to find these paths, graph theory is the missing link that gives us the power to find hidden relationships in this offensive data. The application of graph theory to an Active Directory domain offers several advantages to attackers and defenders. Otherwise invisible, high-level organizational relationships are exposed. All possible escalation paths can be efficiently and swiftly identified. Simplified data aggregation accelerates blue and red team analysis. Graph theory has the power and the potential to dramatically change the way you think about and approach Active Directory domain security. Bio: Andy Robbins is the Offensive Network Services lead for Veris Group’s Adaptive Threat Division. He has performed penetration tests and red team assessments for a number of Fortune 500 commercial clients and major U.S. Government agencies. In addition, Andy researched and presented findings related to a business logic flaw with certain processes around handling ACH files affecting thousands of banking institutions around the country at DerbyCon. He has a passion for offensive development and red team tradecraft, and helps to develop and teach the ‘Adaptive Red Team Tactics’ course at BlackHat USA. Rohan Vazarkr is a penetration tester and red teamer for Veris Group’s Adaptive Threat Division, where he helps assess fortune 500 companies and a variety of government agencies. Rohan has a passion for offensive development and tradecraft, contributing heavily to EyeWitness and the EmPyre projects. He has presented at BSides DC, and helps to develop and teach the ‘Adaptive Penetration Testing’ course at BlackHat USA. Will Schroeder is security researcher and red teamer for Veris Group’s Adaptive Threat Division. He is a co-founder of the Veil-Framework, developed PowerView and PowerUp, is an active developer on the PowerSploit project, and is a co-founder and core developer of the PowerShell post-exploitation agent Empire. He has presented at a number of security conferences on topics spanning AV-evasion, post-exploitation, red team tradecraft, and offensive PowerShell
 Alright, 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, Flukedid. So I want to make sure I got the right mic and 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 like to talk to you about ACH files if you're interested in talking about that. Uh, all three of us work at various groups adaptive threat division. Uh, with that, I will pass it over to Rohan. Hi, I'm, uh, Rohan Vazurkar. Uh, I'm another, I'm another penetration tester at various 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. Let's talk a little bit about the current state of active directory, uh, domain privilege escalation. Uh, first of all, I want to, uh, talk about this quote a little bit. It's a statement 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 going to start thinking in graphs, we're going to 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 role, 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 lead hacksores, because we use the right module to basically do like a point click, escalate writes. MS0867, MS1468, Kitcher pod, 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 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 PowerView, it's very easy to identify systems that a domain admin is logged on to. In fact, 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 ntlm 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 of 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 memocats. You get the password. Now you have access to the entire environment. Awesome. Who's executed an attack path exactly like that? Like a billion times. Most everybody. Let's take a look at a slightly different example. So in this environment, the client actually does have proper patch management and vulnerability management programs. So you're not going to be able to find MS0867. You're not going to find MS1468. You're not going to 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 view and read. Log on scripts are probably the most obvious example. So let's say that we find one of those credentials and 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 notional or 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. Additionally, 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 go into this kind of credential and dance or what Microsoft 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 going to 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 that 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. That probably has some high privilege. So we pivot to this box, run them to 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 again and 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 cat, now we have admin rights in the entire environment. Who's in an attack path like this or who's going to report where credential abuses use 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, who on Twitter you can find at 6Dub, he defines this as the chaining or linking of administrator rights through compromising other privileged accounts. At MSRC in 2009, Alice Zhang and John Dunaghan put a great white paper out about a method or a capability that they had called HeatRay that goes into very extreme detail about how they 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 message group gets all the privileges of that group. Let's say Bob is a member of this group called Help Desk. Help Desk is a member of a group called Server Admins. Server Admins has admin rights to PC2. See a lot of nodding heads. This is pretty good. This is pretty basic stuff. This is what the entire methodology or the entire core of Bloodhound is based on. It's this concept of derivative local admin. So derivative local admin is an extremely effective attack, but it has some very serious setbacks and challenges that we need to be 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 going through this method, you understand this very well. You have a complexity override, essentially, of where each step you go, the analysis steps that you have to do grow exponentially. 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. 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? If your target is like an HR system, it's going to be simple to escalate to DA and then go back down to the system that you actually need. But you may not even have to go through this rigmarole of escalate and DA in the first place. All right. We're going to talk about graph theory. I'm going to take a drink of water real quick. Graph theory has been the missing link in this process that has been keeping us from automating the entire process. I'd highly recommend you look at the history of graph theory with using it to disprove or to prove that there was no solution to the seven bridges of Conexburg problem. Super interesting stuff. We're also going to look at the design of our attack graph. So the basic elements of a graph, first of all, a graph 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 5 could 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, which we'll talk about later. Here's a visual 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 one to vertex two, but you can't go the other way. Paths. Can you see a path from vertex one to vertex four? Yeah. Is there a path from vertex three to vertex four? 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 tack 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 trusts. Finally, paths always lead towards escalating rights. Period. Always. This makes writing our path finding 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 one. First, that'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 one. Finally, let's find out where people are logged on. We find out that Mary is logged on to computer one. Or put another way, computer one 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 one. Server one 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 going to take over now and he's going to talk about how we actually do this data collection. Cool. All right. So I'm going to go over some stealthy data collection with PowerView. I'll let you guys read this quote. This was extremely kind of weird for me. We obviously do not advocate the malicious usage of our tool sets but you know what can you do? So we have our little puppet Phineas Fisher up there. So PowerView. We saw some PowerView users in the audience. PowerView 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 external dependencies. Nothing has to be added to the machine. PowerView 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 PowerView 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 enum, to where you can point these functions to remote systems and figure out who has sessions established with that remote box. Again, not having to have administrative rights on that remote system. So you can run this against a domain controller or 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 context 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 traffic 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 administrative 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 WNT service provider which is a remnant of NT domain deployments and you can also use this particular net local group members 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 an IP, a net 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 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 administrators group for a particular machine. This is either through restricted groups 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 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 PowerView 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. PowerView is just GitNet group, pipe to GitNet group member. This is the PowerShell 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 PowerView that is integrated with BloodHound. It has all the stock PowerView commandlets along with a couple of extra features. Git tack BloodHound data will automate the gathering of PowerView 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 stash 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, package them up with cipher queries for Neo4j which is what it uses on the back end and then shuttle everything off to the Neo4j 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 Git tack BloodHound data to export BloodHound CSV which will take all those same custom objects and export them into 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's going to go through a live demo of BloodHound. Alright so uh oh. I'm not trying to hide it from you I promise. I'm going to 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 groups. Generally speaking when we're in assessment we tend to target domain admins a lot as we talked about earlier. 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 going to actually start with a user. Any user you click on is going to 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 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 going to 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 the domain admins node here. Slow down. 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 has collapsed in you can actually expand by right clicking on it and hitting expand which I'm not going to do because it'll totally break the graph. So in this in this 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 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 going to look for this research group here. Whenever you click on the spotlight it'll zoom in on the node so you know where it is on the graph and it'll pull up all the information on the left so you can start interacting with it. Move it around here you go. So there you go. It's a node ooh. You can ask Bloodhound to give you who the direct members of any 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 who the real 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. It'll use wherever you start and it will try any path you can find to any other node in the domain. Another really handy feature we have is sessions. 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 all the HR members logged in and it'll give you every single computer that it has a session for. Now on this group we're going to find ourselves a computer, 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 the system. However once you unroll it it becomes 51 users of administrative rights. As actor directory domains expand and they keep getting more and more things inside of them groups can get nested. You can easily lose track of whose 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 going to talk about path finding. 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 you guys an example to start we're going to pick a user J.Druin and we're going to ask Bloodhound to take us to the domain admins group. Now watching walking through this path J.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 Mimicats you have the password for a domain admin. Now that's a cool example but let's amp it up a little bit. We're going to take this user J.Nickel at external.local and we're actually going to ask Bloodhound to take us to domain admins at internal.local. Now internal.local and external.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 a different group membership. That takes us to another system with a user in external.local. However the next hop is in the internal.local domain. Despite the fact that we're jumping a trust boundary between 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 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 200,000 computers, Windows workstations and servers. They had about 90,000 users. They had about 75,000 groups tracking all that information manually just not possible. So they also had more than 75 domains I would say in a forest with varying degrees of trust. With the stealth option that Will talked about with ingestion it took us about 20 to 30 minutes to collect all the information we needed from 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 200,000 computers more than 75 domains, Bloodhound found us an attack path to go from this one small this tiny little domain that was relatively insecure to this very high security domain where our actual objective was cross six domain trust boundaries taking advantage of users that had relatively low privilege like four machines that they were admins on but it just so happened that one of those machines had a user that gave us more more privilege in the environment until we got to what we needed. Thanks. Thank you. One additional thing that I would say is I mentioned the stealth option took about 30 minutes. If you're going to do non-stealth and you're actually touching each system one time that ingestion takes between 24 and 36 hours. For that level of environment 200,000 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. 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 going to 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 going to get a large set of credentials. You can also hit control here to show all the node labels or you can hide them all or you can just show the default. 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.local domain we're given three users that are members of groups in the external.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.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 significantly reduce the task surface of that domain. Now any graph that you generate in Bloodhound can be exported either to JSON or an image. 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 outbrief. It's a 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 it'll ingest 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. 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 10 minutes left. One thing that I would like to briefly touch on that we skipped is kind of the architecture of Bloodhound because there are some very important other open source projects that Bloodhound relies on. First of all Linkurious.js is the open source and free version of Linkurious. If you are developing a web front end like this, an interface 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 and then most importantly we rely on Neo4j as our graph database and then obviously it's fed by the PowerShell ingester. So this is the part that Rohan's been waiting for. All right let's do this. So we have here the Bloodhound repository which to this moment has been private and we're just going to go ahead and yolo this right now. Uh oh this is bad. I'm going to have to log into GitHub. I just ruined everything. Andy why didn't you make me check this? It'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. No I'm good. I'm not afraid of these people. Uh once we get done with this. Okay here we go. All right 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. All right there you go. All right 10 9 8 7 6 5 4 3 2 1. Get out 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 Vazurker 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. So I think we have five 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. 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 question was with user session information. You got a second question as well. Tied into that. So you have current sessions to do your job. Do we have what. You have your current session to do your job. Log in users. What about. Pass the hash of a local admin hash to jump. Does blood out take that or local hash match to domain. Where you can take. Okay. Matching hashing job. 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 currently like with a domain controller or a file share. So you you may find yourself recollecting user session information frequently because of the the the nature of how that works. Your second question was with local accounts with read 500 with pass the hash. Right now we are only tracking domain accounts. We are not tracking local accounts at all. But we may put that in the future. Because it jumped from local up to domain with matching hash. Oh is it okay. So also the question of like reuse passwords from like a local admin that has a same password or ntlm hash as a da. We're also not tracking that as well. You should check out a project called auto dain from since post. That may have what you're looking for. Yeah. Thank you. Thank you for the question. Hi. Do you count for stuff like laps being rolled out into the environment. So the question was do we account for laps being passed up being distributed through the environment. That we also do not account for. So any kind of like credential sharing against systems or 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 will also say that we have a couple of things going forward. We want to integrate one of those will be active directory ACL enumeration and auditing. So it'll automatically in a few months when we finish extending the schema we will just 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 tach graph. Yeah. Awesome. Thank you. Thanks for the question. Hey. Thanks guys. How are you handling how the stuff changes over time? Okay. So the date. Yeah. So the question is how do we handle this data as it changes over time. Excellent question. So we treat 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 read just 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 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 from the offensive side this is really cool. We like it a lot. What's really cool is the defensive applications and so over the next six months to the next year we're going to be focusing primarily almost exclusively on defensive applications like that. Thanks. So more and more often the people that I'm popping end up using max. So while obviously their computers aren't joined at the domain many times they have valid LDAP credentials. Is there a way I can use those valid LDAP credentials with bloodhound somehow? Yes. So in our wiki we have a section about data ingestion with other tools. So right now we're talking with Byte Bleeder the author of Crackmap Exec 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. 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 sec. Thanks for the question. How much time do we have? Well one more question. Great. What are the top three things you can use for defense to help you tell everybody to do? So your question was what are the top three things bloodhound can do for defense? So I would say that 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 developers called HeatRay. They use graph theory and they also use machine learning to give an IT admin a list of like here are the 10 changes that you can make in the environment that will most efficiently eliminate the largest number of attack paths based on credential abuse. Secondly I would say that one of the major benefits is a more clear and easy understanding of Nesta group memberships and how those relate to local administrator privileges. And then number three let's talk offline. We have to go. Thank you again. Thanks.
 Alright, 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, Flukedid. So I want to make sure I got the right mic and 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 like to talk to you about ACH files if you're interested in talking about  that. Uh, all three of us work at various groups adaptive threat division. Uh, with that, I will  pass it over to Rohan. Hi, I'm, uh, Rohan Vazurkar. Uh, I'm another, I'm another penetration  tester at various 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. Let's talk a little bit about the current state of active directory,  uh, domain privilege escalation. Uh, first of all, I want to, uh, talk about this quote a  little bit. It's a statement 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  going to start thinking in graphs, we're going to 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 role, 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 lead hacksores,  because we use the right module to basically do like a point click, escalate writes. MS0867,  MS1468, Kitcher pod, 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 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 PowerView, it's very easy to identify systems that a domain admin is  logged on to. In fact, 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 ntlm 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  of 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  memocats. You get the password. Now you have access to the entire environment. Awesome. Who's  executed an attack path exactly like that? Like a billion times. Most everybody. Let's take a look  at a slightly different example. So in this environment, the client actually does have proper  patch management and vulnerability management programs. So you're not going to be able to find  MS0867. You're not going to find MS1468. You're not going to 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 view and read. Log on scripts are probably  the most obvious example. So let's say that we find one of those credentials and 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 notional or 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. Additionally, 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 go into this kind of credential  and dance or what Microsoft 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 going to 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 that 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.  That probably has some high privilege. So we pivot to this box, run them to 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 again and 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 cat, now we have admin rights in the entire  environment. Who's in an attack path like this or who's going to report where credential abuses  use 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, who on Twitter you can find at 6Dub,  he defines this as the chaining or linking of administrator rights through compromising other  privileged accounts. At MSRC in 2009, Alice Zhang and John Dunaghan put a great white paper out  about a method or a capability that they had called HeatRay that goes into very extreme detail  about how they 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 message group gets all the privileges of that group. Let's say  Bob is a member of this group called Help Desk. Help Desk is a member of a group called Server  Admins. Server Admins has admin rights to PC2. See a lot of nodding heads. This is pretty good.  This is pretty basic stuff. This is what the entire methodology or the entire core of Bloodhound  is based on. It's this concept of derivative local admin. So derivative local admin is an  extremely effective attack, but it has some very serious setbacks and challenges that we need to be  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 going through this method, you understand this very  well. You have a complexity override, essentially, of where each step you go, the analysis steps  that you have to do grow exponentially. 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. 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? If your target is like an HR system, it's going to be  simple to escalate to DA and then go back down to the system that you actually need. But you may  not even have to go through this rigmarole of escalate and DA in the first place. All right.  We're going to talk about graph theory. I'm going to take a drink of water real quick.  Graph theory has been the missing link in this process that has been keeping us from  automating the entire process. I'd highly recommend you look at the history of graph theory with  using it to disprove or to prove that there was no solution to the seven bridges of Conexburg  problem. Super interesting stuff. We're also going to look at the design of our attack graph.  So the basic elements of a graph, first of all, a graph 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 5 could 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,  which we'll talk about later. Here's a visual 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 one to vertex two,  but you can't go the other way. Paths. Can you see a path from vertex one to vertex four?  Yeah. Is there a path from vertex three to vertex four? 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  tack 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 trusts. Finally,  paths always lead towards escalating rights. Period. Always. This makes writing our path  finding 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 one. First, that'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 one.  Finally, let's find out where people are logged on. We find out that Mary is logged on to computer  one. Or put another way, computer one 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 one.  Server one 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 going to take over now and he's going to talk about how we actually do this data collection.  Cool. All right. So I'm going to go over some stealthy data collection with PowerView. I'll let  you guys read this quote. This was extremely kind of weird for me. We obviously do not advocate the  malicious usage of our tool sets but you know what can you do? So we have our little puppet  Phineas Fisher up there. So PowerView. We saw some PowerView users in the audience. PowerView 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 external dependencies. Nothing has to be added to the machine.  PowerView 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 PowerView 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  enum, to where you can point these functions to remote systems and figure out who has sessions  established with that remote box. Again, not having to have administrative rights on that remote  system. So you can run this against a domain controller or 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 context 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  traffic 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 administrative  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 WNT service provider which is a  remnant of NT domain deployments and you can also use this particular net local group members 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 an IP, a net 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 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 administrators group for a particular machine. This is either through  restricted groups 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 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 PowerView 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. PowerView is just GitNet  group, pipe to GitNet group member. This is the PowerShell 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 PowerView that  is integrated with BloodHound. It has all the stock PowerView commandlets along with a couple of  extra features. Git tack BloodHound data will automate the gathering of PowerView 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 stash 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, package them up with cipher  queries for Neo4j which is what it uses on the back end and then shuttle everything off to the  Neo4j 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 Git tack BloodHound data to export BloodHound CSV which will take all  those same custom objects and export them into 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's going to go through a live demo of BloodHound.  Alright so uh oh.  I'm not trying to hide it from you I promise.  I'm going to 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 groups. Generally speaking when we're in  assessment we tend to target domain admins a lot as we talked about earlier. 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 going to actually start with a user. Any user you  click on is going to 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 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 going to 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 the domain admins node here. Slow down. 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 has collapsed  in you can actually expand by right clicking on it and hitting expand which I'm not going to do  because it'll totally break the graph. So in this in this 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 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 going to look for this  research group here. Whenever you click on the spotlight it'll zoom in on the node so you know  where it is on the graph and it'll pull up all the information on the left so you can start  interacting with it. Move it around here you go. So there you go. It's a node ooh. You can ask  Bloodhound to give you who the direct members of any 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 who the real 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. It'll use wherever you start  and it will try any path you can find to any other node in the domain. Another really handy  feature we have is sessions. 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 all the HR members logged in and it'll  give you every single computer that it has a session for. Now on this group we're going to find  ourselves a computer, 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  the system. However once you unroll it it becomes 51 users of administrative rights. As actor directory  domains expand and they keep getting more and more things inside of them groups can get nested.  You can easily lose track of whose 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 going to talk about  path finding. 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 you guys an example  to start we're going to pick a user J.Druin and we're going to ask Bloodhound to take us to the  domain admins group. Now watching walking through this path J.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 Mimicats you have the password for a domain admin. Now that's a cool example but let's  amp it up a little bit. We're going to take this user J.Nickel at external.local and we're actually  going to ask Bloodhound to take us to domain admins at internal.local. Now internal.local and  external.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 a different group membership.  That takes us to another system with a user in external.local. However the next hop is in the  internal.local domain. Despite the fact that we're jumping a trust boundary between 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 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 200,000 computers, Windows workstations and  servers. They had about 90,000 users. They had about 75,000 groups tracking all that information  manually just not possible. So they also had more than 75 domains I would say in a forest with  varying degrees of trust. With the stealth option that Will talked about with ingestion it took us  about 20 to 30 minutes to collect all the information we needed from 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 200,000 computers more than 75  domains, Bloodhound found us an attack path to go from this one small this tiny little domain that  was relatively insecure to this very high security domain where our actual objective was cross six  domain trust boundaries taking advantage of users that had relatively low privilege like four  machines that they were admins on but it just so happened that one of those machines had a user  that gave us more more privilege in the environment until we got to what we needed.  Thanks.  Thank you. One additional thing that I would say is I mentioned the stealth option took about 30  minutes. If you're going to do non-stealth and you're actually touching each system  one time that ingestion takes between 24 and 36 hours. For that level of environment 200,000  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.  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 going to 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 going to get a large set of credentials. You can also hit control here to  show all the node labels or you can hide them all or you can just show the default. 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.local domain we're given three users that are members of groups in the  external.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.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 significantly  reduce the task surface of that domain. Now any graph that you generate in Bloodhound can be  exported either to JSON or an image. 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 outbrief. It's a 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 it'll  ingest 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. 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 10 minutes left. One thing  that I would like to briefly touch on that we skipped is kind of the architecture of Bloodhound  because there are some very important other open source projects that Bloodhound relies on.  First of all Linkurious.js is the open source and free version of Linkurious. If you are developing  a web front end like this, an interface 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 and then most importantly we rely on Neo4j as our graph database and then obviously  it's fed by the PowerShell ingester. So this is the part that Rohan's been waiting for.  All right let's do this. So we have here the Bloodhound repository which to this moment has been  private and we're just going to go ahead and yolo this right now. Uh oh this is bad.  I'm going to have to log into GitHub. I just ruined everything.  Andy why didn't you make me check this?  It'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.  No I'm good. I'm not afraid of these people. Uh once we get done with this.  Okay here we go. All right 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.  All right there you go. All right 10 9 8 7 6 5 4 3 2 1. Get out 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 Vazurker 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. So I think we have five 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. 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  question was with user session information. You got a second question as well. Tied into that.  So you have current sessions to do your job. Do we have what. You have your current session to  do your job. Log in users. What about. Pass the hash of a local admin hash to jump. Does  blood out take that or local hash match to domain. Where you can take. Okay. Matching hashing  job. 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 currently like with a domain controller  or a file share. So you you may find yourself recollecting user session information frequently  because of the the the nature of how that works. Your second question was with local accounts  with read 500 with pass the hash. Right now we are only tracking domain accounts. We are not  tracking local accounts at all. But we may put that in the future. Because it jumped from local  up to domain with matching hash. Oh is it okay. So also the question of like reuse passwords  from like a local admin that has a same password or ntlm hash as a da. We're also not tracking that  as well. You should check out a project called auto dain from since post. That may have what  you're looking for. Yeah. Thank you. Thank you for the question. Hi. Do you count for stuff like  laps being rolled out into the environment. So the question was do we account for laps being  passed up being distributed through the environment. That we also do not account for. So any kind of  like credential sharing against systems or 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 will also say that  we have a couple of things going forward. We want to integrate one of those will be active directory  ACL enumeration and auditing. So it'll automatically in a few months when we finish extending the  schema we will just 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 tach graph. Yeah. Awesome. Thank you. Thanks for the question. Hey. Thanks guys.  How are you handling how the stuff changes over time? Okay. So the date. Yeah. So the question is how  do we handle this data as it changes over time. Excellent question. So we treat 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 read just 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 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 from the offensive side this is really cool. We like it a  lot. What's really cool is the defensive applications and so over the next six months to the next year  we're going to be focusing primarily almost exclusively on defensive applications like that.  Thanks. So more and more often the people that I'm popping end up using max. So while obviously  their computers aren't joined at the domain many times they have valid LDAP credentials. Is there  a way I can use those valid LDAP credentials with bloodhound somehow? Yes. So in our wiki we have  a section about data ingestion with other tools. So right now we're talking with Byte Bleeder the  author of Crackmap Exec 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. 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 sec. Thanks for the question. How much time do we have? Well one more question. Great.  What are the top three things you can use for defense to help you tell everybody to do? So  your question was what are the top three things bloodhound can do for defense? So I would say that  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 developers called HeatRay.  They use graph theory and they also use machine learning to give an IT admin a list of like here  are the 10 changes that you can make in the environment that will most efficiently eliminate  the largest number of attack paths based on credential abuse. Secondly I would say that  one of the major benefits is a more clear and easy understanding of Nesta group memberships  and how those relate to local administrator privileges. And then number three let's talk  offline. We have to go. Thank you again. Thanks.
DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_0_3539.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_3540_3983.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_3984_4535.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_4536_6911.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_6912_7007.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_7008_7787.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_7788_7895.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_7896_8123.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_8124_8627.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_8628_8915.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_8916_10379.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_10380_10643.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_10644_11639.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_11640_12155.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_12156_12851.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_12852_14267.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_14268_15251.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_15252_16031.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_16032_16151.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_16152_17351.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_17352_17759.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_17760_18995.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_18996_19067.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_19068_20963.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_20964_22151.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_22152_22211.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_22212_28187.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_28188_34943.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_34944_34991.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_34992_35243.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_35244_36119.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_36120_36227.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_36228_37487.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_37488_37871.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_37872_40163.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_40164_41255.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_41256_41363.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_41364_41423.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_41424_42815.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_42816_43859.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_43860_44375.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_44376_45143.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_45144_48959.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_48960_50435.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_50436_55007.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_55008_55127.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_55128_56675.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_56676_56843.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_56844_58823.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_58824_62291.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_62292_65567.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_65568_66155.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_66156_66779.png DEF_CON_24_-_Andy_Robbins__Rohan_Vazarkar__Will_Schroeder_-_Six_Degrees_of_Domain_Admin_wP8ZCczC1OU_66780_66873.png
Alright, 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, Flukedid. So I want to make sure I got the right mic and 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 like to talk to you about ACH files if you're interested in talking about that. Uh, all three of us work at various groups adaptive threat division. Uh, with that, I will pass it over to Rohan. Hi, I'm, uh, Rohan Vazurkar. Uh, I'm another, I'm another penetration tester at various 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. Let's talk a little bit about the current state of active directory, uh, domain privilege escalation. Uh, first of all, I want to, uh, talk about this quote a little bit. It's a statement 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 going to start thinking in graphs, we're going to 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 role, 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 lead hacksores, because we use the right module to basically do like a point click, escalate writes. MS0867, MS1468, Kitcher pod, 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 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 PowerView, it's very easy to identify systems that a domain admin is logged on to. In fact, 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 ntlm 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 of 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 memocats. You get the password. Now you have access to the entire environment. Awesome. Who's executed an attack path exactly like that? Like a billion times. Most everybody. Let's take a look at a slightly different example. So in this environment, the client actually does have proper patch management and vulnerability management programs. So you're not going to be able to find MS0867. You're not going to find MS1468. You're not going to 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 view and read. Log on scripts are probably the most obvious example. So let's say that we find one of those credentials and 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 notional or 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. Additionally, 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 go into this kind of credential and dance or what Microsoft 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 going to 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 that 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. That probably has some high privilege. So we pivot to this box, run them to 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 again and 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 cat, now we have admin rights in the entire environment. Who's in an attack path like this or who's going to report where credential abuses use 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, who on Twitter you can find at 6Dub, he defines this as the chaining or linking of administrator rights through compromising other privileged accounts. At MSRC in 2009, Alice Zhang and John Dunaghan put a great white paper out about a method or a capability that they had called HeatRay that goes into very extreme detail about how they 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 message group gets all the privileges of that group. Let's say Bob is a member of this group called Help Desk. Help Desk is a member of a group called Server Admins. Server Admins has admin rights to PC2. See a lot of nodding heads. This is pretty good. This is pretty basic stuff. This is what the entire methodology or the entire core of Bloodhound is based on. It's this concept of derivative local admin. So derivative local admin is an extremely effective attack, but it has some very serious setbacks and challenges that we need to be 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 going through this method, you understand this very well. You have a complexity override, essentially, of where each step you go, the analysis steps that you have to do grow exponentially. 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. 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? If your target is like an HR system, it's going to be simple to escalate to DA and then go back down to the system that you actually need. But you may not even have to go through this rigmarole of escalate and DA in the first place. All right. We're going to talk about graph theory. I'm going to take a drink of water real quick. Graph theory has been the missing link in this process that has been keeping us from automating the entire process. I'd highly recommend you look at the history of graph theory with using it to disprove or to prove that there was no solution to the seven bridges of Conexburg problem. Super interesting stuff. We're also going to look at the design of our attack graph. So the basic elements of a graph, first of all, a graph 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 5 could 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, which we'll talk about later. Here's a visual 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 one to vertex two, but you can't go the other way. Paths. Can you see a path from vertex one to vertex four? Yeah. Is there a path from vertex three to vertex four? 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 tack 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 trusts. Finally, paths always lead towards escalating rights. Period. Always. This makes writing our path finding 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 one. First, that'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 one. Finally, let's find out where people are logged on. We find out that Mary is logged on to computer one. Or put another way, computer one 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 one. Server one 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 going to take over now and he's going to talk about how we actually do this data collection. Cool. All right. So I'm going to go over some stealthy data collection with PowerView. I'll let you guys read this quote. This was extremely kind of weird for me. We obviously do not advocate the malicious usage of our tool sets but you know what can you do? So we have our little puppet Phineas Fisher up there. So PowerView. We saw some PowerView users in the audience. PowerView 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 external dependencies. Nothing has to be added to the machine. PowerView 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 PowerView 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 enum, to where you can point these functions to remote systems and figure out who has sessions established with that remote box. Again, not having to have administrative rights on that remote system. So you can run this against a domain controller or 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 context 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 traffic 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 administrative 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 WNT service provider which is a remnant of NT domain deployments and you can also use this particular net local group members 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 an IP, a net 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 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 administrators group for a particular machine. This is either through restricted groups 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 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 PowerView 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. PowerView is just GitNet group, pipe to GitNet group member. This is the PowerShell 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 PowerView that is integrated with BloodHound. It has all the stock PowerView commandlets along with a couple of extra features. Git tack BloodHound data will automate the gathering of PowerView 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 stash 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, package them up with cipher queries for Neo4j which is what it uses on the back end and then shuttle everything off to the Neo4j 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 Git tack BloodHound data to export BloodHound CSV which will take all those same custom objects and export them into 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's going to go through a live demo of BloodHound. Alright so uh oh. I'm not trying to hide it from you I promise. I'm going to 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 groups. Generally speaking when we're in assessment we tend to target domain admins a lot as we talked about earlier. 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 going to actually start with a user. Any user you click on is going to 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 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 going to 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 the domain admins node here. Slow down. 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 has collapsed in you can actually expand by right clicking on it and hitting expand which I'm not going to do because it'll totally break the graph. So in this in this 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 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 going to look for this research group here. Whenever you click on the spotlight it'll zoom in on the node so you know where it is on the graph and it'll pull up all the information on the left so you can start interacting with it. Move it around here you go. So there you go. It's a node ooh. You can ask Bloodhound to give you who the direct members of any 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 who the real 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. It'll use wherever you start and it will try any path you can find to any other node in the domain. Another really handy feature we have is sessions. 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 all the HR members logged in and it'll give you every single computer that it has a session for. Now on this group we're going to find ourselves a computer, 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 the system. However once you unroll it it becomes 51 users of administrative rights. As actor directory domains expand and they keep getting more and more things inside of them groups can get nested. You can easily lose track of whose 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 going to talk about path finding. 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 you guys an example to start we're going to pick a user J.Druin and we're going to ask Bloodhound to take us to the domain admins group. Now watching walking through this path J.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 Mimicats you have the password for a domain admin. Now that's a cool example but let's amp it up a little bit. We're going to take this user J.Nickel at external.local and we're actually going to ask Bloodhound to take us to domain admins at internal.local. Now internal.local and external.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 a different group membership. That takes us to another system with a user in external.local. However the next hop is in the internal.local domain. Despite the fact that we're jumping a trust boundary between 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 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 200,000 computers, Windows workstations and servers. They had about 90,000 users. They had about 75,000 groups tracking all that information manually just not possible. So they also had more than 75 domains I would say in a forest with varying degrees of trust. With the stealth option that Will talked about with ingestion it took us about 20 to 30 minutes to collect all the information we needed from 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 200,000 computers more than 75 domains, Bloodhound found us an attack path to go from this one small this tiny little domain that was relatively insecure to this very high security domain where our actual objective was cross six domain trust boundaries taking advantage of users that had relatively low privilege like four machines that they were admins on but it just so happened that one of those machines had a user that gave us more more privilege in the environment until we got to what we needed. Thanks. Thank you. One additional thing that I would say is I mentioned the stealth option took about 30 minutes. If you're going to do non-stealth and you're actually touching each system one time that ingestion takes between 24 and 36 hours. For that level of environment 200,000 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. 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 going to 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 going to get a large set of credentials. You can also hit control here to show all the node labels or you can hide them all or you can just show the default. 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.local domain we're given three users that are members of groups in the external.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.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 significantly reduce the task surface of that domain. Now any graph that you generate in Bloodhound can be exported either to JSON or an image. 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 outbrief. It's a 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 it'll ingest 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. 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 10 minutes left. One thing that I would like to briefly touch on that we skipped is kind of the architecture of Bloodhound because there are some very important other open source projects that Bloodhound relies on. First of all Linkurious.js is the open source and free version of Linkurious. If you are developing a web front end like this, an interface 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 and then most importantly we rely on Neo4j as our graph database and then obviously it's fed by the PowerShell ingester. So this is the part that Rohan's been waiting for. All right let's do this. So we have here the Bloodhound repository which to this moment has been private and we're just going to go ahead and yolo this right now. Uh oh this is bad. I'm going to have to log into GitHub. I just ruined everything. Andy why didn't you make me check this? It'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. No I'm good. I'm not afraid of these people. Uh once we get done with this. Okay here we go. All right 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. All right there you go. All right 10 9 8 7 6 5 4 3 2 1. Get out 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 Vazurker 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. So I think we have five 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. 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 question was with user session information. You got a second question as well. Tied into that. So you have current sessions to do your job. Do we have what. You have your current session to do your job. Log in users. What about. Pass the hash of a local admin hash to jump. Does blood out take that or local hash match to domain. Where you can take. Okay. Matching hashing job. 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 currently like with a domain controller or a file share. So you you may find yourself recollecting user session information frequently because of the the the nature of how that works. Your second question was with local accounts with read 500 with pass the hash. Right now we are only tracking domain accounts. We are not tracking local accounts at all. But we may put that in the future. Because it jumped from local up to domain with matching hash. Oh is it okay. So also the question of like reuse passwords from like a local admin that has a same password or ntlm hash as a da. We're also not tracking that as well. You should check out a project called auto dain from since post. That may have what you're looking for. Yeah. Thank you. Thank you for the question. Hi. Do you count for stuff like laps being rolled out into the environment. So the question was do we account for laps being passed up being distributed through the environment. That we also do not account for. So any kind of like credential sharing against systems or 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 will also say that we have a couple of things going forward. We want to integrate one of those will be active directory ACL enumeration and auditing. So it'll automatically in a few months when we finish extending the schema we will just 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 tach graph. Yeah. Awesome. Thank you. Thanks for the question. Hey. Thanks guys. How are you handling how the stuff changes over time? Okay. So the date. Yeah. So the question is how do we handle this data as it changes over time. Excellent question. So we treat 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 read just 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 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 from the offensive side this is really cool. We like it a lot. What's really cool is the defensive applications and so over the next six months to the next year we're going to be focusing primarily almost exclusively on defensive applications like that. Thanks. So more and more often the people that I'm popping end up using max. So while obviously their computers aren't joined at the domain many times they have valid LDAP credentials. Is there a way I can use those valid LDAP credentials with bloodhound somehow? Yes. So in our wiki we have a section about data ingestion with other tools. So right now we're talking with Byte Bleeder the author of Crackmap Exec 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. 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 sec. Thanks for the question. How much time do we have? Well one more question. Great. What are the top three things you can use for defense to help you tell everybody to do? So your question was what are the top three things bloodhound can do for defense? So I would say that 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 developers called HeatRay. They use graph theory and they also use machine learning to give an IT admin a list of like here are the 10 changes that you can make in the environment that will most efficiently eliminate the largest number of attack paths based on credential abuse. Secondly I would say that one of the major benefits is a more clear and easy understanding of Nesta group memberships and how those relate to local administrator privileges. And then number three let's talk offline. We have to go. Thank you again. Thanks.
to do that in an active directory environment, I've been a professional penetration tester and red teamer for four years. I originally cut my would really like to talk to you about ACH files I've built a, uh, a good number of our offensive we can show you is that not only are we going to 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 defenders, but also from attackers. So that means systems that we now kind of have notional or kind of missing link that we have to identify. choose one of these systems to pivot to. You can now we have admin rights in the entire this as the chaining or linking of administrator entire methodology or the entire core of derivative local admin. So derivative local admin identified in your environment versus here are to DA and then go back down to the system that you actually need. But you may not even have to water real quick. Graph theory has been the missing link in this process that has been directed edge or it's one way. You can think of Finally, paths always lead towards escalating group memberships. We find out that Bob is a This is the core fundamental concept for audience. PowerView is a PowerShell 2.0 amount of information from Active Directory against every single machine. This can be also have a kind of different new kind of method what's really cool in this approach is that This is the PowerShell pipeline. What's really gather the data on the current domain but it'll machine can reach the analysis machine whether on BloodHound UI you're presented with one of our The next thing we can look at is group delegated users of administrative rights. As actor who is explicitly defined as an admin on the Will talked about with ingestion it took us about we needed from this global enterprise to identify security domain where our actual objective was privilege in the environment until we got to what relationships they have in other domains. Historically this has been a very tedious and and this is one of our favorites is find shortest graph is every single possible path that this node here you can see has several clients. It looks really, really cool and Rohan is doing this the license that we are please. My name is Andy Robbins. You can find me Will Schroeder you're already following him on much. By the way we decided to be really nice to information that it doesn't change that much day about data ingestion with other tools. So right that will most efficiently eliminate the largest Secondly I would say that one of the major