 My name is Andy Robbins. This is Will Schroeder. Thanks for being here for our talk. Thank you, thank you, thank you. The title of our talk, an ace up the sleeve, designing Active Directory Dackle-based Backdoors. Quick information about me. My name is Andy Robbins. My handle is Waldo. I'm a co-founder and developer on the Bloodhound project. I've spoken at places, done training. If you really want to get me excited, come up and talk to me about the ACH file format and we can talk offline about that. Hi, my name is Will Schroeder. My handle is Harmjoy. I'm an offensive engineer at SpectreOps with this guy. I'm a, I've written a lot of code. I help write a good chunk of the Veil framework, Empire, Power View and PowerUp. If any of you guys use that, Bloodhound, Key Thief, and I really love Active Directory and dive in this research and it's been a whole ton of fun. I've spoken at a few conferences. I'm a power split developer actively and I'm a Microsoft PowerShell MVP. So somehow Microsoft doesn't hate me that much I guess. Alright, so I'll give you guys a quick TLDR, where we are now, where we're going to be, and where we're going to wind up. So first we're going to talk about DACLs and ACES, what these are, how they work, why they matter. We're going to look at typical misconfigurations and how we can abuse these misconfigurations. We'll look at how we can analyze this stuff easily with Bloodhound from offensive and defensive perspective. We will look at designing Apple based back doors and then we're going to show you some demos, some examples, some case studies. And then finally at the end we're going to talk about what we can actually do about all this as defenders. So an important caveat to keep in mind, we're not talking about ODE, we're not talking about anything worthy of a CVE. Really what we're talking about is how to abuse the existing Windows security model for malicious purposes. Thank you. Secondly, so we're not dropping ODE. Secondly, we're talking about putting back doors into an environment. Most of the time you actually need to be already elevated to do that. So all the stuff that we're putting in, we're already domain admin and then we're looking at, once we lose that, how do we get that back easily? So why care about this? Some of the few things we think are really cool about this approach for persistence is one, it's often very difficult to determine if you, even if you find one of these misconfigurations, how do you tell if it's malicious? It could have been put there almost by accident from some third party tool, really old exchange install and a lot of this stuff we're going to talk about. These changes also will very often survive domain functional level upgrades and operating system upgrades. So there's remnants in a lot of domains of a lot of these misconfigurations. So a back door may have been put in 10 years ago in a really insecure environment and even though the environment is more secured now, these could have existed for years and we hope this kind of scares you. You know, we're going to go in some background and stuff but finally we bring it all together. We hope the example is really kind of hopefully terrify a few people. So I love this quote from Matt Graber who's actually up here in one of the rows. So as an offensive engineer, if you can dream it, someone has likely already done it. And that someone isn't the kind of person who comes that speaks at security cons like DEF CON. So we're not, we fully believe like we are not the first ones that come up with this idea. We think that, you know, different advanced adversaries almost certainly come to the same conclusion. So a big thing with this talk is we want to bring attention to the problem. The research isn't complete but we're excited and, you know, this may have already happened. Alright, so let's talk about some background. First of all, we need to acknowledge some existing work. First and most importantly is this French project from ANSI which is the French equivalent of the NSA. The two guys who did this work, Lucca Oyo and Emmanuel Grah, this is the Active Directory Control Pass project. If you haven't had a chance, I recommend you go take a look at it. We learned a lot about the Windows security model and DACLs and ACES from their white paper. They also served as initial inspiration for using an attack graph to model attack paths in an environment. So they served as initial inspiration for our Bloodhound project as well early on. We also had to run their white paper through Google Translate because we're stupid Americans that can't speak any of their languages. So we think we got all the details, right? We got some cool stuff but I'm sure there might have been some stuff we missed. There's also this work from Robin Granberg at Microsoft. This is the AD-ACL scanner. It lets you do things like CSV, you can do basic diffing. If you want to know more about that, look at the tech net link there. And the deck is obviously going to be online after. And then next, there's also this other project called BTA. Unfortunately, we missed this before our black hat talk. So this is from the team at Airbus for trying to get a wrangle on Active Directory ACES as well. One thing to note, like they do some really cool analysis, but you need an offline application. So this is from the team at ACTS.DIT. In our case, everything we're showing will be done remotely through LDAP. Wrapped into PowerShell, but there's other weaponization methods, obviously. So when we first started looking at this, we had the idea, how can we implement backdoor as it abuses Active Directory object control. We scoured the Internet as well as we could. This is the closest thing that we could find. It's a blog post from 2010 written in Russian, obviously. This was all we could find. And we figured if the only thing we could find was written in Russian, we were probably on the right track. They also, in this blog post, this guy also talks about hiding the existence of Active Directory principles, which we built on and I think we improved on in a couple of different ways. So yeah, check out that blog post and run that through Google Translate. Cool. So we're going to go into a little bit of technical background. I know this might not be as super interesting some of these few slides, but you really need some of the background in this stuff to understand why and how these backgrounds are going to be able to understand why and how these backdoors work. So, Securable Objects and Windows. A Securable Object is defined by pretty much as an object that has a security descriptor. This is a breakdown of the binary structure. So there's a lot of pieces to this, you know, header bits, all this kind of stuff. All this can be expressed as an SDDL, so a security descriptor definition language string. If you guys have ever seen that, we're not going to really cover that too much. The pieces we care about are the owner, instead of the owner that, you know, for a particular object and we care about the DACL, so the pointer to that DACL here at the end. So if you're not familiar with Active Directory, you're not familiar with the access control model. People throw around ACL, DACL, SACL and all these types of things. People often use them interchangeably as well. So essentially the access control list, the ACL for an object is basically shorthand for the DACL and the SACL superset. So the discretionary access control list that you saw on the last slide is the access control list, the SACL. These are ordered collections of access control entries. So it's a pointer from the binary structure in memory to an array of these access control entries. The DACL specifies what principles or trustees is another term, have what rights over the object. Nothing crazy, right? The SACL allows for auditing of access attempts to the object. We're not really going to dive into SACLs, we're going to cover a little bit at the end, but, you know, in this case the SACL. So in an access control entry there's some 32-bit fields that control, you know, kind of some auditing kind of components. There's a lot of stuff in there. What we really care about are one, it's the owner, or sorry the principal that has the rights over this object for this particular entry, and then the access mask, which is a 32-bit field that defines what those rights are. This is what it'll look like in Active Directory users and computers. You can see that the principal is, sorry, up there all the way at the top right, the object is victim. So victim user, the principal is harm joy, so harm joy has these rights. There's lots of rights in there, and the ones we care about are, you know, like modify the permissions on the object, modify the owner. So again, this is just the access mask. There's one bit in the access mask that we particularly care about. So in those kind of like the control bits in this A-C-E entry, with this access mask, there's a DS control bit. So this is interpreted in one of two ways. So if the target GUI, or the target GUID for the object ACE type for that particular ACE, is a confidential attribute. So the most common case is LAPS, right? So you don't want everyone to be able to read that LAPS password, and we'll go into LAPS in a little bit. If DS control access is flipped, then that grants access to that confidential attribute. So that's one particular way to interpret it. The second way is extended rights. So if the object ACE type GUID matches a registered extended right that is registered in the forest schema, say user force change password, or DS replication get changes and replication get changes all, so these are DC sync rights. So if those are registered in the forest schema already, and that GUID, you know, is resolved and actually points to a particular extended right, then flipping the DS control access will grant a control access right for this. So it's the way that extended rights are granted. Extended rights are just a way to, you know, like I mentioned, extend the actual generic rights that are available in that 32-bit access mask. Okay, so the part of the operating system that is actually in charge of evaluating these ACEs in what is called canonical order is the kernel mode security reference monitor. So the SRM takes an access request for a given principle against another object, and it evaluates the DACL in that canonical order to make an access decision, whether access is allowed or denied. Importantly, we can abuse this function of SRM to hide principles or to hide the existence of DACLs. The way that we do this is we abuse the fact that explicitly defined ACEs on an object are always, they always precedence over inherited ACEs. So let's look at an example here. We have this OU called IT, and on that OU I'm going to specify an explicit deny ACE. Let's say it's just for full control. That's going to inherit down to the OU that is contained there called help desk, and then the Robbie Winchester user at the bottom of this OU tree also gets this ACE inherited down to it. Well, what if I put a conflicting ACE in the intermediary OU? So at help desk I say, well, wait a minute, I want to have an explicit allow. The explicit allow takes precedence over the inherited deny, even though typically denies are given precedence over allows. Finally, on the Robbie Winchester user I specify two explicit ACEs on there, an explicit allow and an explicit deny. So the order that you see on here is what is called the canonical order and is based on inheritance from parent and grandparent OUs. So the explicit deny will be evaluated first, then the explicit allow, then the inherited allow and then finally the inherited deny. The green inherited allow on Robbie Winchester is given precedence over the other inherited ACE because generationally that OU that it inherits an ACE from is closer. So let's look at some typical DACBOMS configurations for how we can do object takeover and how we can abuse these. Another caveat that I'll remind you of is that we're talking during this talk primarily about persistence. We're not looking at privilege escalation for this talk. We do have content on my blog if you want to read about that, but the primitives for object takeover are going to be the same. Additionally, we're looking at chaining together multiple different control relationships between different principles to make this very, very difficult for a defender to find. So you have user objects that take over a user object by abusing these access control entries. There are two primitives that we have for you. One, we can do a targeted Kerberoasting attack by a show of hands who knows what Kerberoasting is. After our talk is done, go read Sean Metcalf's blog about Kerberoasting. It's going to change your life. So basically we can set a value on a service principal name for a user and then we can request a Kerberoast ticket back from the domain controller as any other user and then we can crack that ticket and recover that user's clear text password. Anybody in the domain can do this. Secondly, we can change the user's password without knowing its current value. This is with a privilege that you give your help desk so that they can change people's passwords after they fat finger and lock themselves out. At the bottom here, we have two PowerView commandlets that can abuse these, set domain object owner password. There's also one for setting a user SPM. How can we take over a group object? Well, what we're interested in is not necessarily the group but we're interested in the privileges that the group has. So if we have the ability to add an arbitrary user to that group, we can give ourselves the same rights that that user has and write that existing privilege forward. We can write property to all properties to do this or we can have write access only to the member property and we can add a user to that group. In PowerView, you do this with add-domain group member. For computer objects, this gets a little bit tricky because the only thing that we know of right now is being able to abuse a lapse installation. And so if our user has the ability to read a local admin password attribute on the computer object, obviously we can pivot to that system and we can be a local admin. If you have other ideas about this, we are very, very excited to hear it. We are all ears. One thing to note as well is we are not claiming that this kind of taxonomy is complete. These are some of the primitives that we found that we've used operationally but we know for sure there are other types of object takeover relationships. So the point of this talk is not to show you every way to take over any object, it's to show you chains of these kind of interesting backdoors. Next, domain objects. So even though I'm not a local admin on a domain controller, even though I'm a local admin, if I have full control over the domain object, which represents the Active Directory domain, I can DC sync. DC sync, if you're not familiar, allows me to remotely request an NT hash for any other user in the domain if I have that privilege. Thank you, Benjamin Dalby and Vincent Latu for DC sync. Yes. So the two explicit privileges that we actually need for this, we don't need full control of the domain object, we need DS replication get changes and DS replication get changes all. Then we can request NT hashes for any user including the curb TGT, which is interesting and we'll show you why later. So, group policy objects. This is one of the few relationships that we don't have incorporated into the Bloodhound schema yet. These are going to have to write a custom path finding algorithm to handle all the weird inheritance issues. What the main takeover primitive is can you modify the GPO? You can modify the GPO. These GPOs are linked to OUs, sites and domains and there are users that can modify the GPO within these. So if you can modify the GPO, there's a million and one ways that you can get code execution on a computer it's applied to or you can get essentially code execution in the context of the user that the GPO is applied to. So the right to care about here are right property to all properties like some of the other examples and right property specifically to the GPC file sys path. This represents the rights to actually modify the GPO and if you modify the GPO, you can actually clone down to the file system in sysfall. So if you have the rights or modify the rights, then you can just go straight to sysfall and modify any of the GPO settings. There's a set of a few rights that apply to pretty much all the objects. So generic all, this will grant you all generic rights like we mentioned. It also covers some of the control or object takeover rights that we're going to cover in the next slide. Generic right allows for the modification of almost all properties in the GPC file sys path. These are abusable power view set domain object. Again, this is how you could do that targeted Kerberoosting. And again, these rights normally apply to most objects for takeover. So control rights. These are rights that allow principal or trustee to take control of a particular object. So if you have right dackel, you have the ability to modify the security information for an object. You can add whatever new ace entries you want. So if you have right dackel in the domain, you can grant yourself DC sync rights. And again, that's abusable with add domain ackel. With right owner, owners have implicit full control of the object despite any existing deny aces or anything like that. This will come into play when we actually want to hide the dackel in things here in a little bit. So this is also available with power view with set domain object owner. Okay, so let's slow down for a second. Let's do some visuals to kind of make sense of what we're talking about. We're going to look at some analysis that we can do with the bloodhound interface. We added several of these ace edges into the bloodhound database so that you can hopefully easily map out what these existing control relationships look like. That's the 1.3 update that happened just about a month or two ago. So for defenders, we hope that you guys can use this for enforcing your least privilege policies. For identifying what ACLs may be misconfigured and giving people more privilege than they actually need. And then detecting some of the more non-stealthy dackel-based backdoors. As an attacker, we can use this to find ackel-based escalation paths. We can also look for principles that are interesting for us a backdoor based on the existing privilege that they have. And then we can also kind of understand the existing situation there is with ACLs and how do we really care about being sneaking in the first place. So this is the bloodhound interface. The default view, we see the domain admins. We'll click on the domain admins group and we'll look at inbound object control. So who has control of this group? From the first-degree perspective, we see there are six groups that have control over the domain admins. Several of them are generic all privilege and then one of them is right dackel privilege. You may notice that a lot of these groups. These groups also include other groups and computers and users. So if we unroll this out, we can see that there are actually in fact 29 principles at how full control of the domain admins group because of security group delegation. Now what if I want to unwind this out and say who can take control over all these principles? What we call this is transitive object control or an ackel-only attack path. I'm going to put hound after I finish doing this right here and showing you the group delegation. So let's go back into inbound object control. Transitive object controllers, there are actually 50 of them. So there are 50 objects that have an ackel-only attack path to be able to take control of the domain admins group. These users here all belong to a group called identity administrators, which is a member of this group called account operators that has force change password over this user group. So let's look at something a little more interesting and complex. This user here belongs to a group which also belongs to a group that can change this user's password who can change this user's password who's a member of this group who has full control of the domain admins group. So that's inbound object control. What we can also easily audit is outbound access control. What privileges do they have against other objects? So I'll find this user here called rTaylor and go to outbound object control. First degree object control is zero because that user itself is not specified as a principle having privilege against another object. For group delegated control there are four users that he has the ability to take control of because of security group delegation. What I can also say is transitive outbound object control. If I go over any of these four users then what? What can I do? Bloodhound finds this easily and I see that for transitive object control I have control over all these principles here by accol-only attack path. So this user belongs to this group belongs to that group who can change that user's password who's a member of that group who has control over all these other users here. All right. Thanks. So we can actually design backdoors based on these principles. So what our objective is we want to be able to get back into an active directory environment on any computer and be able to instantaneously escalate our privileges back up to whatever we want. Maybe that's enterprise admin, maybe it's domain admin, maybe it's local admin on a system. We want to be able to blend in with normal ACLs that already exist in the environment. So let's see what we can come up with. So how can we hide the DACL? I just showed you with Bloodhound how we can audit the DACLs, but what if I don't want you to be able to audit the DACL as a defender? This requires two steps. I change the object owner for the object I'm backdooring away from the domain admins to another principle that I control or the principle itself. And remember that's because object owners have implicit full rights despite any explicit denies that might exist in the chain. Secondly, I will add a new explicit deny ace which recall will take precedence over anything else in the DACL. And I say the everyone principle is denied the read permission privilege. Then I can't audit the DACL from any other principle except for the one that's backdoored. Here's what it looks like in ADUC Goey for setting this. So I'm saying the principle everyone is denied read permissions. It's that simple. I can also hide the existence of a principle that I'm backdooring. It requires three steps. First of all, I need to change the object owner because owners always have full control. Then I'll grant explicit control either to the object itself or another object that I control. And then on the OU that contains this user or group or computer or whatever it is that I'm backdooring I'm going to say that everyone is denied the list contents privilege. Then when they try to look up that user in ADUC or by LDAP or with a net executable they can't see it. Here's what it looks like in ADUC I assure you there is a user in this OU you cannot see it. These stealth primitives we're going to factor into some of the case study demos at the end of the presentation. So to summarize we know how we can abuse ACES to take over other objects. We know that we can control who has the ability to audit the DACLs. And we know that we can hide the principles and the trustees from easy identification. Cool. So remember that quote. If you can dream it, if you can imagine it it's probably already been done. We're going to go over five case studies that we were able to come up with in the course of this research. We're two guys in a basement just figuring this out for the first time and thought for about a week what some cool stuff we can do. If you actually had people much smarter than us with a lot more money and time to do that. So the first one, like we mentioned you don't need to be domain admin to DCSYNC. DCSYNC is entirely dependent on two ACES on the principle domain object. And again, all domains are a domain is actually represented as a domain object in Active Directory. So if we to implement the backdoor and these will all kind of follow the standard of we'll show how to implement the backdoor and then we'll show how to execute the backdoor. So the DCS replication get changes and replication get changes all rights to the domain object. Then this user who's at the attacker controlled user who's not in any privileged groups to stop just created user has the ability to DCSYNC any users account forever unless defenders actually figure out these rights in the domain object and actually remove them. So one thing to add to that is you can do DCSYNC remotely. So you can do this from any domain joint system. Here's a video. I'm going to import PowerView and then the bad guy user is going to be our attacker kind of control principle. I'm just going to show that the bad guy user is not in any privileged groups. It's brand new. We're going to save the SID for the bad guy user off and then next we're going to use and again all this PowerView stuff we're going to use an ACL enumeration there are no explicit aces on the object where the bad guy is the principle. Then we're going to use add domain object ACL and we're going to grant DCSYNC rights. You can do this in your lab tomorrow. We're going to add those and then we're going to enumerate those rights again and just show you that these new explicit aces have been added. You see? Okay. There's a SID for that bad guy user and he now has these DCSYNC replication rights. Cool, cool. Now we're going to pop up a window that we had a window running as bad guy. We tried to DCSYNC previously. We're going to try it again and now we have DCSYNC rights despite them not being in any any privileged group. So starting simple, nothing to you know, alright. Thank you. You know, this is a pretty simple example of an ACL base back door and we're going to get a lot more complicated. So I'm a nasty holder. I don't have time to completely go into this. There's also a good time to note that for example, we wrote a 64 page white paper that goes into excruciating detail for all these things. That will be released through Black Hat and also through our website at spectrobsite.io. We're going to release it probably next week. So if you are interested in this stuff, there's going to be tons more background and examples and mitigations and all that fun stuff. So 30 second summary, MNSD holder essentially acts like a permission template for highly privileged groups. They grant themselves force change password or generic all, writes to this CN MNSD holder system, this object exists in every single domain. So they add it to the object itself. Then every 60 minutes, a special process called the security descriptor propagator process or SD prop will run. It will enumerate all the privileged groups like enterprise admins, account operators, domain admins and if the permissions on those objects differ than the template in MNSD holder, it takes the permissions from MNSD holder and then imprints them onto the secured, highly privileged groups. Then the attacker hides their principle using the methods described. We don't want to hide the dackel here because this is going to be cloned off into every domain admin and enterprise admin and all that kind of stuff. But we can complicate it and we can make it kind of look like an orphaned object. Then to execute, the attacker force will run. Now we have a demo for this too. I'm going to load up PowerView again. Again, I'm not on a DC. I do have domain admin rights. I'm going to show the bad guy user's OU location. He's in the OU totes not evil because that's a good way to hide, totes not evil. Then we're going to add all rights for this bad guy 2 principle to the admin SD holder object in the current domain. Now, that was the actual backdoor. Now we're going to hide the principle. We're going to change that object, that bad guy 2. We're going to change the owner of that to himself. Then we're going to deny, one second, we're going to get some of the raw objects we need to do some of this manipulation. We're going to deny everyone the ability to read the permissions on the object. We're going to do a complete generic all deny so no one can actually do anything on the object. Then we're going to deny everyone the right to list the children of that totes not evil. So this is completely hiding the principle. Commit that all off. And we could have run all these commands in one three seconds. Then we're going to wait 60 minutes for SD prop to run. We're back. We're going to show, we're going to check if the rights propagated. So we're going to enumerate the rights for a particular domain admin. And we see this SID, that bad guy SID shows up for a generic all. But if we try to actually enumerate the bad guy 2 user, we can't find it here. Now this, we're going to refresh. And that guy disappeared. Even though he's still there. So, you know, there's ways that you could eventually, you know, take these things back over, but it's hard to find. And now we're going to use that account to show force resetting that domain admins password. Then we're going to do run as with CMD. And now we have codex as a DA again. Cool stuff, hopefully. I promise I'm not begging for applause. So lapse, we don't have a demo video for this one, but we're going to talk through it. So lapse is Microsoft's local administrator password solution. It's an awesome, awesome free thing that Microsoft released. It's a series of client side and schema extensions that every 30 days, the computer will randomly rotate its local administrator password and then store it in this protected attribute, this confidential attribute called MSMCS admin password. So the lapse also includes a series of commandlets released by Microsoft. So it's the adminpassword.ps commandlets. There's one particular commandlet called find admin password extended rights that audits who can read, who has the rights to read this particular attribute. We're going to show some issues with it, but I want to emphasize up front that these commandlets were not built as a security protection type thing. It was meant to find the results of who can actually audit these things based on the normal process that lapse rights were delegated. But there's a few edge cases. So here's who can actually read admin password. We have some DS control and a whole bunch of like inheritance kind of issues. The above checks, also generic all because that will imply that DS control access. Also that object control stuff that we talked about. So are you the owner? Can you modify the DACL or can you modify the owner? This list is updated. There are several more flaws we discovered just a few days before given the presentation. These are the flaws. So DS control, if DS control access is flipped, but the ace applies to all descendant objects and to set a computer descendant object, that's an edge case. Also it doesn't check if you're the owner. If you can write the DACL, write the owner and it only analyzes OUs and optionally specific computers, it doesn't check for things in the default computer container. So here's a normal case. We have this John Smith user and he is not able to read that lapsed password down there at the bottom. But if you run these in fine admin password writes, you can see he's not listed, so it makes sense. So we're showing that this user is not part of the server admins that pops up for this audit. Now we're going to craft a very specific ace that exploits the flaw with inheritance. So when we add this ace, that particular John Smith principle will have the right to read the lapsed password forever whenever it's changed, but the default auditing components released with laps will not find it. So this is a lapsed based backdoor. Here you see it actually executed. So John Smith, he's not in server admins but he's able to read the lapsed backdoor despite not actually showing up in the default auditing commandlet. So cool. We think these issues pretty soon, we dove pretty deep into some of the lapsed information and again, I'll taunt more on the white paper. This is my favorite. It's mine too, I'm a little bit biased though. So we mentioned how third party applications can extend Active Directory schema, they can add security groups, they can add control from groups to other principles in Active Directory. By far the biggest offender of this is Microsoft Exchange. So with Microsoft Exchange Server 2016, 2013 and 2007 SP1 and forward, Exchange Server will create a group called Exchange Trusted Subsystem and add all of the Exchange Servers into that group. Then it will grant that group full control over every other object in the domain with the exception of accounts that whose DACA is protected by the Admin SE holder object. Before 2007 SP1 this also included full control over everything. So essentially an Exchange Server had the same privilege that a domain controller did. So if you're ever on a pentest or red teamers, if you ever end up popping an Exchange box you are probably one or two hops away from compromising the entire domain. There are several real environments that we've gone into where what we have seen is reality is that the Exchange Trusted Subsystem does have full control of everything. The domain object, domain admins, domain controllers, enterprise admins, you name it Exchange owns it. So for this we're going to go through a couple of steps to implement our backdoor. First of all we want to find an object that we can backdoor that is not going to be very obvious for an auditor to find. So we're going to ride existing privilege by finding a group that already has admin rights against one Exchange Server through group's delegation. So not just one that is like if you did NetLocalGroupAdministrators and you found that group, we're going to go further back. Then we're going to grant authenticated users full control over that security group. We're going to change the group that we're backdooring to the Exchange Server. And then we're going to deny read permissions on that group to the everyone principal. How do we execute this? We're going to regain access to Active Directory as any user on any computer. We're going to add our current user because they are an authenticated user to the domain, they have full control over the security group like everybody else. We're going to add ourselves to that group and we're going to add our new found local admin rights on an Exchange Server. We're going to use PSExec to execute Mimicats as the system user on that computer. When you execute as a system user on a computer, you have the same privileges that the computer object in Active Directory has. So a lot of times this means DC sync. So we're going to go into Bloodhound and we're going to find the group that we're going to backdoor. So we'll go to domain admins and look at what other principals have control over the domain admins group. We can see that the Exchange trusted subsystem has full control over the domain admins group. And there are several computers that are added to the security group. We're going to select one of those, we're going to select Exchange 001 and we're going to see who the existing admins are on that box. Through Bloodhound we can automatically unroll out who all the effective admins of a system are by group delegation and we can see there are seven users that have local admin rights on the system. There's a system on the right, that group is explicitly an admin, that group has a group there and then this intermediary group also has a group called server backup tier two. This group even though it would never show up in the local admins group on that system is a local admin. So we're going to backdoor that group. First we're going to import power view. Then we're going to get the raw directory of the object. So server backup tier two, the group. We're going to grant authenticated users full control over that security group. It's done. Then we're going to change the owner of the group to an exchange server. Just for anti-audit reasons. That's done. Then we're going to deny read permissions on that group to the everyone principals so you can't easily audit this backdoor. The backdoor is in. How do we execute this? We re-engain access to the environment as any user, domain user, you're not an admin anywhere. Again, we're going to import power view and then we're going to add ourselves to that security group, server backup tier two, which is now done. Then we're going to use psexec to remotely run memocats as a system user on that exchange server. And then we're going to DC sync the curb tgt user and then use a created golden ticket and then we effectively then own the domain. And it's done. Love those curb hashes. So, this last one we don't have a video for, it's also the most complicated. But again, it's specced out in even more detail in the white paper. So the entire backdoor consists of an attacker grants him or herself generic all to any user object with the attacker as the trustee. And then you kind of grant that Patsy or proxy user the right dackel privilege to the default domain controller's GPO as the entire backdoor. And this is kind of a separate approach that we talked about in the paper of using a proxy or Patsy type user instead of the actual attacker principal. So to execute it, get codecs in the system again, you force reset the proxy user's password. You use that authentication context to add a dackel to that default domain controller's GPO that grants, oh, that you're adding a dackel to the GPO that allows right access to that GPC files this path. So we are granting ourselves the right to edit the GPO itself. Then we're going to grant through modifying the GPO the SCEnableDelegationPrivilege. This is going to be pushed down to the domain controllers. And what this does is it allows us to modify the MSDS allowed to delegate to super protected property on user accounts. And the reason it's protected is that if you're able to modify that, you can re-compromise the entire domain at will by executing essentially a constrained delegation attack through using Mimikatz and Kikyo. This is pretty complicated. I have some stuff in my blog in the earlier in January that goes into this more detail. But cool stuff. Pretty subtle though, right? It's just one user that's not the actual attacker. Then you have generical on that and you use that user as a proxy so what we can do in the future is actually do really kind of crazy chains of this going all the way back. So not only if they find the backdoor they have to walk back every possibility of someone that might have had access or could gain access to that object. This is again kind of an anti-incident response measure. Alright, so defenses, all is not lost. We promise. The problem with these backdoors is you have to have event log auditing turned on at the moment that the misconfiguration is introduced. So if this is introduced 10 years ago and you didn't have this stuff tuned up or you don't have 10 years of event log data, which I don't think many people have then you're not going to figure out who actually put this stuff in assuming you can find it and assuming you believe it's actually malicious. This is why we think this is a pretty cool persistent strategy. But for example if you want to stop these from being put in in the future there's different event log IDs like 4738 changed and you can filter these by the particular property modified and you don't have to monitor for every single possible change you just need to start monitoring piecemeal by all these kind of object takeover primitives that we talked about. And I'm also going to be putting out a blog and hopefully in the next few months that gives complete defensive guidance for every single ACL based takeover primitive that we covered. So replication metadata. Metadata remnants from a domain controller actually preserved in these particular properties in Active Directory. So in the DC you synchronize everything there's this XML based metadata that you can pull out. So you can figure out when a given attribute was modified and from what domain controller the modification originated from. So this kind of points you in the right direction but you have to go to that DC and parse those event logs to actually figure out who actually made the change. I have a draft post that I'm going to drop that goes into the next slide. Also Sackles. So those system access control lists that specify the types of access attempts to generate audit records in the security event log of a domain controller. Sackles have been around forever. People don't really use them because if you turn them on they're going to be tons and tons and tons of events but we really think that if you implement Sackles again just for the object takeover primitives that we talked about you can cut down a couple orders of magnitude in the amount of noise and actually just there's a bitly link that has some more information on there. Future work we worked really heavily with Lee Christensen and Tiffkin on some of this stuff and we tried really hard to set a null DACL for or otherwise manipulate the header control bits like SE DACL presence so the idea being like you can do on a host setting a null DACL so anyone in you know anybody authenticated users could have access but any attempts to set the entity security descriptor remotely on an object were ignored but this warrants another look we weren't able to get it working the documentation said why but there might be a way to do it. We also want to research additional control relationships particular those takeover primitives for computers as well as Sackle type auditing. So credits we want to special thanks all the people who helped us with the slide deck and research definitely Lee Christensen and Tiffkin he really really helped us. Jeff Demek for content review everyone else Matt Raeber who used to work with us gave us some really good feedback and some really you know he really really good feedback and kind of content review so with that we're pretty much done we can have a few questions and if we run out of time for that we'll be outside.