 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 Phuket. 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'd really love 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 Vazirkar. Uh I'm another penetration tester at Varus Group. I've been uh doing penetration testing for about two and a half years. I work on a lot of uh open source projects and I was responsible for the web UI for this one. Hi, my name is Will Schrader. My handle is Harmjoy. I'm a researcher at the adaptive threat division and I've built a uh a good number of our offensive kind of tool sets that we've used over the last couple of years. Most notably PowerShell Empire and also PowerView which kind of acts as the data collection component for BloodHound. Any PowerView users in the room? Lots of you. Awesome. Yeah, give Will a hand. Give Will a hand for PowerView. Yeah. And also this is their first time here at DEF CON. So give them a hand too real quick. It's their first time speaking. Alright. 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 just stated by John Lambert. He's a general manager at Microsoft's threat intelligence center. John said defenders think in lists, attackers think in graphs. As long as this is true, attackers will win. There's a great blog post where John goes into some depth about what this concept means effectively. What I hope that we can show you is that not only are we 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 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 percent 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 leap hack sores because we use the right module to basically do like a point click escalate rights. 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 writes on this one initial machine. You dump the NCLM hash for the red 500 system. They've applied kb2871997, but they haven't disabled the local admin account. What does that mean for you? That means that all of these computers all of a sudden light up and now you have kind of notional administrator access to them, including the box of the domain admin is logged on to. So you use your favorite pivot method, maybe PS exec 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 MSO 8 is 67. You're not going to find MS 1468. 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 or 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 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 on 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 the 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 the cats 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 the cats. Now we have admin rights in the entire environment. Who's in an attack path like this or who's read a report where credential abuses uh used in that kind of attack path. A lot of you. Cool. We refer to this attack or this methodology as derivative local administrator. Justin Warner uh who on Twitter you can find at six dub. He defines this as the chaining or linking of administrator rights through compromising other privileged accounts. Uh at MSRC in 2009 Alice Zhang and John Dunigan put a great white paper out uh about a method or a capability that they had called heat ray that goes into very extreme detail about how they uh kind of understood this process as well. Highly recommend that you go read that white paper. So let's look at this a little bit simpler. Let's say we have this user Bob. Bob has admin rights to PC one. On PC one is this user named Mary who is logged on. Mary has administrator rights to PC two. Bob derives administrator privileges to PC two 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 helpdesk. Helpdesk is a member of a group called server admins. Server admins has admin rights to PC two. See a lot of nodding heads. Like this is this is pretty good. This is pretty basic stuff. This is what the entire uh methodology or the entire core of Bloodhound is based on is this concept of derivative local admin. So derivative local admin is an extremely effective attack but it has some very serious uh setbacks and challenges that we need to be uh aware of. First of all it's extremely time consuming and it's extremely tedious work. If you've gone through the process of manually uh going through this method uh you understand this very well. You have a uh uh a complexity override essentially of where each step you go the the analysis steps that you have to do grow uh exponentially. Uh next it's not comprehensive. So imagine the difference between taking a report to your client or as a client getting a report from a pen test firm. Imagine the difference between reading this is one attack path that we identified in your environment versus here are all of the attack paths in your environment. Okay. Next you have limited situational awareness. You may not even understand you may not have the ability to understand what kind of privilege you currently have in whatever user context you're running in. Finally the last thing I will say is did you even need DA? Uh if your target is like an HR system it's 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 had to go through this rigmarole of escalate and DA in the first place. Alright 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 uh in this process uh that has been keeping us from automating the entire process. I'd highly recommend you look at the history of graph theory with Leonard Oiler using it to disprove or to prove that there was no solution 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 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 uh 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 to vertex 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 attack graph design that works. And here's how it looks. The vertices are used to represent users, groups, computers and domains in Active Directory. The edges identify the relationships between those. So this means admin rights, group membership, user sessions and domain trusts. Finally, paths always lead towards escalating rights. Period always. This makes writing our pathfinding queries very very simple. Again let's look at this visually. Like I said users we have two users in this graph. Bob and Mary. Groups we have two groups in this graph. IT admins and domain admins. Computers. We have one computer, server one. First let's identify group memberships. We find out that Bob is a member of this group called IT admins and we find out that Mary is a member of this group called domain admins. Next we figure out privilege. Who has admin rights where? This group called IT admins has administrator rights on this computer called server 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. All right so I'm going to go over some stealthy data collection with power view. I'll let you guys read this quote. This was uh extremely kind of weird for me. We obviously do not advocate the malicious usage of our tool sets but you know uh what can you do so we have our little uh puppet Phineas Fisher up there. So power view. We saw some power view users in the audience. Power view is a PowerShell 2.0 compatible domain and network situational awareness tool. I started writing this a couple of years ago to automate a lot of the offensive and some defensive tradecraft that we execute on engagements. It's completely self-contained. It's a single PS1 PowerShell script. It can be loaded into memory. There's no external dependencies. Nothing has to be added to the machine. Power view collects the data the bloodhound is built on. What's really cool is that in most cases you do not need any kind of elevated domain access to gather this information and I'll go over the different components here in a second. So just as a domain authenticated user you do need a session like that but no privileges at all just in domain users, the parent group, you can collect a huge amount of information from Active Directory through a couple of different ways. So, Andy mentioned the three components of information we needed. The first is who's logged on where. We refer to this as user hunting. So the main function in 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 in num, 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 in num against each system. So it's much faster but we don't get quite as accurate data. Next, who can admin what? This is the craziest thing to me. I love this. So as an unprivileged user we can enumerate the members of a local group on a remote machine without needing administrator privileges on that remote machine. I didn't there was a couple of tools out there that did this. I weaponized it up in PowerView and we use this function specifically on almost every single engagement. There's two ways you can do this. You can use the 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 132 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 sending a single packet to any other machine. The PowerView function for this is fine 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 git net group pipe to git net 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 or 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 Cypher 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 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 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 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 more readable we do a lot of collapsing of nodes. So you can see there's an 87 next to the domain admins node here. Slow down. Alright. There are 87 other computers. I can't slow down sorry. There are 87 computers that are folded into the domain admins group. Now if we displayed all of these the graph as it gets bigger and bigger takes longer and longer to lay out. So this is more of a performance thing. Any node that is collapsed in you can actually expand by right clicking on it and hitting expand which I'm not going to do because it will totally break the graph. So 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 introduced 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 will zoom in on the nodes so you know where it is on the graph and it will pull up all the information on the left so you can start interacting with it. Move it around. There you go. There you go. It's a node. 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 pathing and fine 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 just 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 who's admin on a system because of nested groups just continuing to obscure what you're looking for. One thing I would add to that is this example is showing an order of magnitude difference between who is explicitly defined as an admin on the system versus who gains admin rights through these nested groups. And that kind of difference in an order of magnitude we see is very very common on almost every assessment that we go into. You can ask Bloodhound to give you the sessions for computer who's logged on to 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 MemeCats you have the password for a domain admin. Now that's a that's a cool example but let's let's amp it up a little bit. We're going to take this user Jnickel 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 two domains Bloodhound just is using the data available to it and has no problem enumerating these paths. No matter how complicated the path is if the path exists Bloodhound will be able to enumerate that path properly. So one one thing that I would add to that a common question that we've been getting over the past week when we're publicly demoing Bloodhound for the first time is with regard to scalability. So we went into an environment that had 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 at 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 these this global enterprise to identify attack paths. Doing the query with Neo4j and a graph database is just as fast as what you're seeing here. In that environment I'm talking about with 200,000 computers more than 75 domains Bloodhound found us an attack path to go from this one smart 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 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're 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 out brief. It's great value to show your clients. It looks really, really cool and everybody likes pretty pictures so. As Will was talking about earlier you can export all the Bloodhound data instead of directly to the database through the CSV ingestion here. When you click this you can just pop give it a file and 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 to interface it with Neo4j Linkurious is where you want to go. It's built on top of Sigma so you have all these things kind of abstracted away from you that are otherwise very difficult if you're not a JavaScript expert. Secondly it's compiled with Electron so it is cross-platform 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 are 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 GPL v3. 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. You can find me on Twitter again my name is Andy Robbins my handle on Twitter is at underscore Waldo with a zero Rohan. Oh go back sorry sorry. There you go. All right 10 9 8 7 6 5 4 3 2 1 get it from your neighbor socialize professional network. Me somebody please. My name is Andy Robbins you can find me at underscore Waldo with a zero Rohan Berserker you can find him on Twitter at Captain Jesus Will Schroeder you're already following him on Twitter at harm joy 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. Big one is you have get sessions so it's. Get like get right in there yeah big one is you have get 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 logged in users. What about past the hash of the local admin hash to jump does blood out take that or local hash match to domain. Where you can take. Okay matching hash and jump okay so his question is with user session information. When we're collecting user session data the user needs to have a valid session. That is 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 nature of how that works your second question was with local accounts with read 500 with past 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. Oh is it okay so also the question of like reuse passwords from like a local admin that has the same password or ntlm hash as a d a 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 question is this was born out of a necessity to bypass laps protections because we couldn't pass the hash of a local admin account we had to rely on domain user level accounts. And I'll also say that we have a couple things going forward we want to integrate one of those will be active directory ACL enumeration and auditing. 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 tack graph. Awesome thank you. Thanks for the question. Hey. Thanks guys. How are you handling how this 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 and we like 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 Macs. So obviously their computers aren't joined in 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 OSSX 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 second. Thanks for the questions. How much time do we have? One more question. Great. What are the top three things you can use for defense to help 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 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.