>> My name is Andy Robbins, this is Will Schroeder. Uh thanks for being here for our talk. Thank you, thank you, thank you. [Applause] The title of our talk An ACE Ip the Sleeve- Feigning Active Directory DACL base Backdoors. Uh quick information about me, my name is Andy Robbins, my handle is Waldo. Uh I’m a cofounder and founder on the Bloodhound project. [Cheers] I’ve spoken at places, done training. Um, if you really wanna get me excited come up and talk to me about the ACH file format and uh we can talk offline about that. [Laughs] >> Hi, my name is Will Schroeder, my handle is Harm Joy. I’m an offensive engineer at SpecterOps, with this guy. I’m a I’ve run a lot of code, I’ve helped write a good chunk of Veil-Framework, Empire/EmPyre, PowerView and PowerUp if any of you guys use that. Bloodhound, uh KeeThief. I really love active directory and dived into this research and it’s been a whole ton of fun. I’ve spoken at a few conferences. I’m a PowerSploit developer actively and I’m a Microsoft PowerShell MVP. SO somehow Microsoft doesn’t hate me that much I guess. >> Alright, so give you guys a quick TLDR. Where we are now, where were gonna be and where were gonna wind up. So first were gonna talk about DACLs and ACEs, what these are, how they work, why they matter. We’re gonna 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 designed ACL Based Backdoors. And then we’re gonna show you some demos, some examples and case studies, and then finally at the end we’re gonna talk about like what we can actually do with all of this as as defenders. So an important caveat to keep in mind uh we’re not talking about 0-Day, we’re not talking about anything worthy of a CVE, really what we’re talking about is how to abuse the existing Windows uh security model uh for malicious purposes. UH. [Cheers] Thank you. [Laughs] Secondly, so we’re not dropping 0-Day, secondly, uh we’re talking about putting backdoors into an environment, most of the time you actually need to be already elevated to do that. So uh all of the stuff that we’re putting in we’re already domain admin, and then were looking at you know once we lose that, how do we get that back easily. >>So why care about this? Some of the few things hat we think are really cool about this approach or persistence is one, it’;s often very difficult to determine, if even if you find one of these misconfigurations, how do you tell if it’s malicious? It could have been put there you know almost by accident from some third party tool. Really old exchange install in a lot of the stuff we’re gonna talk about. These changes also will very often survive domain functional level upgrades and operating systems upgrades. So there’s remnants in a lot of domains in a lot of these misconfigurations. So a backdoor may have been put in ten years ago in a really insecure environment and even though the environments more secured now, these could have existed for years. And we hope this kind of scares you. And you know we’re gonna into some background and some stuff but finally bring it all together, we hope the examples really kinda hopefully terrify a few people. So I love this quote from Matt Graeber, he’s actually up here in uh 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 speaks at security cons like DefCon so, we’re not we fully believe like we are not the first ones to come up with this idea. We think that you know difference advanced adversaries have probably almost certainly come to the same conclusions. So a big thing to 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 uh first and most importantly is this uh French project from ANSSI which is the French equivalent of the NSA. Uh the two guys who did this work, uh Lucas Bouillot and Emmanuel Gras. Uh this is the active directory control paths project. If you hadn’t had a chance, I recon recommend you go and take a look at it. We learned a lot about the uh Windows Security Model and DACLs and ACEs from their White Paper. They also serve as initial inspiration for using a an attack graph to model an attack paths in an environment. So they served as initial inspiration for our Bloodhound project as well, early on. >> We also had to run the White Paper through Google Translate because we’re stupid Americans and can’t speak any other languages so we think we got all the details right. We think we got some cool stuff but I’m sure there might have been some stuff that we we missed. >> There’s also this work from Robin Brandgard at Microsoft. This is the AD ACL Scanner. uh let’s you do things like export ASUS to CSV you can do basic diffing. Uh if you want to know more about that, look at the uh tech net link there. And the deck is obviously going to be online after. Uh and then next, there’s also this other project called BTA. Uh unfortunately we missed this before our Black Hat talk so uh this is from he team at Air Bus for trying to get a wrangle on Active Directory ASUS as well. >> One, one thing to note like they do some really cool analysis but you need an offline NTDS dot DAT. In our case everything were showing will be done remotely through LDAP wrapped into Power Shell but there’s other weaponization methods obviously. >> So when we first starting looking at this we had the idea like how could we implement backdoors that abuse uh active directory uh object control. We scoured the internet as well as we could. This is the closest thing that we could find. Uh it’s a blog post from twenty ten written in Russian obviously. This was all we could find. And we figured like if the only thing we could find was written in Russian, we were probably on the right track. Uh [Laughter] They also in in in this blog post this guy also talked about uh hiding the existence of Active Directory of Principles which would uh we built on and I think we improved on in a couple different ways. Uh so yeah, check out that blogpost and run that through Google Translate. Cool so, we’re gonna 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 of this stuff to understand why and how these backdoors work. So securable objects and Windows. A securable object is defined by as pretty much as an object that has a security descriptor. This is a breakdown of the binary structure. So there there’s a lot of pieces to this, you know header, bits all this kind of stuff. That all this can be expressed as a SDDL. So uh a Security Descriptor Definition Language string. If you guys have ever seen that. We’re not gonna really kinda cover that too much. The pieces that we care about are the owner. So the SID of the owner, you know for our 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 uh the DACL and SACL super set. So the Discretionary Access Control List that you saw on the last slide and the System Access Control List, the SACL. These are ordered collections of Access Control Entries. So it’s a pointer from the binary structure and memory to an array of these Access Control Entires. 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 gonna dive into SACLs we’re gonna cover a little bit at the end but you know in this in this case we’re just mostly going to cover the DACL. So the in an Access Control Entry, there’s some bits, there’s some 32 bit fields that control kind of some auditing kind of components. There’s a there’s a lot of stuff in there. What we really care about for one, it’s the the owner or sorry the principle that has the rights over the object for this particular entry and then the access mass. Which is a 32 bit field that what those rights are. This is what it will look like in ADUC, in Active Directory Users and Computers. So you can see that the principle is sorry up there all the way up at the top right the object is victim so victim user their principle is harm joy so 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 we particularly care about. So in those headers kind of like the control bits in this ACE Entry uh 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 control DS Control Access is flipped then that grants read access to that confidential attribute so that’s one particular way to interpret it. The second way is extended rights. So if the ObjectAceType GUID matches a registered extended right that is registered in the forced Schema, say User-Force-Change-Password or DS-Replication-Get-Changes and Replication-Get-Changes-All. So these are DC synch rights. So those are registered in the forced schema already and that GUID uh 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 a 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 uh and what is called Canonical Order is the Colonel Mode Security Reference Monitor. So the SRM takes an access request for a given principle against another object and evaluates the DACL in that Canonical Order to make an access decision whether access is allowed or denied. Importantly, we can use we can abuse this function of SRM to hide pri uh principles or to hide the existence of DACLs. The way that we do this is we abuse the fact that ex explicitly defined ACEs on an object are always they always take precedence over inherited uh ACEs. So let’s look at an example here. We have this OU called IT. And on that OU, I’m gonna specify an Explicit Deny ACE. Let’s say it’s just for full control. That’s gonna inherit down to the OU that can is contained there called help desk. And then the Robby 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 inter 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 Robby 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 grand parent 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 Robby Winchester is given precedence over the other inherited ACE. Because generationally that OU that inherits that ACE from is closer. So let’s look at some typical DACL misconfigurations for how we can do object takeover and how we can abuse these. Under that caveat that I remind you of, uh 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. Uh but the primitives for object takeover are gonna be the same. Additionally we’re looking at chaining together multiple different control relationships between different principles to make this very very difficult for defender to find. So you have User Objects and Active Directory, how can we take over a User Object by by abusing these Access Control Entries? There are two primitives that we have for you. One we could 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 gonna change your life. So basically we can set a value on a service principle name for a user and then we can request a Kerberoast ticket back from the domain controller for that user as any other user. And then we can crack that ticket and recover that user’s clear text password. Anybody in that domain can do this. Secondly we can change the user’s password without knowing its’ current value. This is with the 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 cmdlets that can abuse these. Set-DomainObjectOwner and Set-DomainUserPassword. There’s also one for setting a user SPO. 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 ride that existing privilege forward. We can WriteProperty to all properties that 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 dash Domain Group Member. For Computer Objects this gets a little bit tricky because the only thing we know of right now is being able to abuse a LAPS installation. And so if our user has the ability to read the local Admin Password attribute on the computer object. Obviously we can pivot to that system and 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 complete. These are some of the primitives that we’ve found that we’ve used to you know 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. >> Uh next, Domain Objects. So even though I’m not a local admin on a domain controller. Even though Im not a domain admin, if I have full control over the Domain Object, which represents the active Directory Domain, I can DCSync. DCSync if you’re familiar allows me to remotely request an NT Hash for any other user in the Domain if I have that privilege. >> Thank you Benjamin Dailey and Vincent Latour for DCSync. >> Yes. Yes. Uh 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 Curve 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 because we’re gonna have to write a custom path finding algorithm that can 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 OU, sites, and domains. And there are users, groups and computers contain 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 to supply it to. Or you can get essentially code execution the context of the user that the GPO is applied to. So the rights to care about here are Write Property and to all properties like some of the other examples. And Write Property specifically to the GPC-File-Sys-Path. This represents the right to actually modify the GPO. And if you modify the permissions on this, those permissions will actually clone down to the file system in SYSVOL. So if you have the rights or modify the rights, then you can just go straight to SYSVOL 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, so connect to all generic rights like we mentioned. It also covers some of the controller object takeover rights that we’re gonna cover in the next slide. Generic Write allows for the modification to almost all properties except for those confidential properties uh handled by that DS control access bit. These are abusable by PowerView’s set the domain object. Again this is how you can do that targeted Kerberoasting. And again these rights normally apply to most objects for take over. So Control Rights. These are rights that allow principle or trustee to take control of the particular object. So if you have Write DACL, you have the ability to modify the security information for an Object. You can add whatever new ACE entries you want. So you can grant yourself whatever rights. So if you WriteDACL in the domain then you can grant yourself DCSync rights. And again that’s abusable with Add Domain ACL. With Write Owner. Owners have implicit full control of the object despite any existing you know deny ACEs or anything like that. This will come into play when we actually wanna hide the DACL and things here in a little bit. So this is also available PowerView with set Domain Object Owner. >> Okay, so , let’s slow down for a second. let’s do some visuals uh to kinda make sense of what all we’re talking about. We’re gonna look at some like analysis that we can do with the bloodhound interface. We added several of these ACEd edges into the Bloodhound database so that you can hopefully, easily map out what these existing control relationship looks like. >> That’s uh the one point three update that happened just about a month or two ago. >> So for defenders we hope that you guys can use this for uh enforcing your lease privilege uh policies uh for identify what ACLs may be misconfigured and giving people more privilege than they actually need. Uh and then detecting some of the more non stealthy uh DACL based backdoors. As an attacker we can use this to find uh ACL based escalation paths. Uh we can also look for principles that are interesting for us, a back door based on the existing privilege that they have. And we can also understand the existing uh you know situation there is with ACLs and you know do we really care about being sneaky 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 controls. So who has control of this group? From the first degree perspective we see that 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 DACL privilege. You may notice that a lot of these are exchange groups. These groups also include other groups, and computers and users. So if you unrule this out you can see that there are actually in fact twenty nine principles that have full control of the Domain MS Group, because of security group delegation. Well 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 ACL only Attack Path. I can do that with Bloodhound, after I finish doing this right here. It's showing you the group delegation. So let's go back into Inbound Object Control. Transitive Object Controllers, there are actually fifty of them. So there are fifty objects that have a ACL 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 which is a member of the domain admins 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 Admin's Group. So that's Inbound Object Control. What we can also easily audit is outbound Access Control. So for a given principle, what privileges do they have against other objects? So I'll find this user here called R-taylor and go to outbound object control. First degree object control, it's 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. So if I can take 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 ACL 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 over here. That's it. Alright, thanks. [Applause] Pretty good on time. So let's look at how we can actually design backdoors based on these uh 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 that's Domain Admin, maybe it's local admin on a system. We want to be able to blend in with normal ACL's 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 on how we can audit the DACL's. 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 am backdooring away from domain admins to another principle I control or the principle itself. >> And remember that's because object owners have implicit full rights despite any explicit denies than what exists 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 of the principle except for the one that's backdoored. Here's what it looks like in ADUC GUEY 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. And this 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, whatever it is that I am backdooring, I'm gonna say that everyone is denied, the list contents privilege. And then when they try to look up that user in ADUC or LDAP or with a Net Executable, they can't see it. Here's it looks like an ADUC. I assure you there is a user in this OU. You cannot see it. >> Well these uh, these uh, these stealth primitives that we're gonna 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 trustees from easy identification. >> Cool, so remember that quote. Uh you know, if you can dream it, if you can imagine it, it's probably already been done. We're gonna go over five case studies that we were able to come up with in the course of this research. You know we're two guys in a basement just figuring this out for the first time, and thought for about a week what's some cool stuff we could do. If you actually had people much smarter than us with with a lot more money and time and you know funding, I'm sure it could be even you know more subtle on kind of crazy things you could do with this. 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 and active directory. So if we do implement the backdoor then these will all kind of follow the standard we'll show how to implement the backdoor and then we'll show how to execute the backdoor. So if we add manually DCC DS Replication Get Changes and Replication Get Changes All Rights to the Domain Object, then this user who's the attacker controlled user, who's not in any privileged groups, you know just stock just created user has the ability to DCSync any user's account forever. Unless defenders actually figure out these rights to the domain object and actually remove them. >> So uh one thing to add to that is you can do DCSync remotely, you don't code execution on a domain controller. So you can do this from any domain joint system. >> Here's a video, so okay I'm going to go ahead and import PowerView and then the bad guy user is going to be our attacker kind of controlled principle. I'm just gonna show that the bad guy user is not in any privileged groups. This is brand new. We're gonna save the Sid for the bad guy user off and then next we're gonna use and again all this PowerView stuff, we're gonna use uh an ACL enumeration cmdlet and show you that there are no explicit ACEs on the object where the bad guy is the principle. Then we're gonna use add domain object ACL and we're gonna grant DCSync rights. You can do this in your lab tomorrow. We're gonna add those then we're gonna 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 has now has these DCSync Replication Rights. Cool, cool. Now we're gonna pop up a window that had you know it'a a little small, but when we're running this bad guy, we tried to DCSync previously. We're gonna try it again and now we have DCSync Rights despite them not being in any any privilege group. So starting simple, nothing too you know. [Applause] Thank you. You know this this is a pretty simple example of an ACL based backdoor, and we're gonna get a lot more complicated. So Admin SD Holder, I don't have time to completely go into this. This is also a good time to note that for we gave this presentation at Black Hat and we wrote a sixty four page white paper that goes into excruciating details for all these things. That will be released through Black Hat and also through our website at SpecterOps dot I O. Uh we're gonna release release it probably next week, so if you are interested in this stuff there's gonna be tons more background and examples, and mitigation and all that fun stuff. So thirty second summary. Admin SD Holder essentially acts like a permission template for highly privilege groups. So to implement the backdoor they tacker grants themselves force change password or generic all rights to this CN Admin SD Holder System this. this object exists in every single domain. So they add it to the object itself. Then every sixty 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 Admin SD Holder, it takes the permissions from AdminSD Holder and then imprints on to on to the secured, you know highly privileged groups. Then the attacker hides the principle using the methods described. We don't wanna hide the DACL here because this is gonna be cloned off into every domain admin and enterprise admin and all that kinda stuff. But we complicate it and make it kinda look like an orphaned object. Then to execute, the attacker force resets the password for any account that has admin count equals one, any privileged account. And we have a demo for this too. Okay. I'm gonna load up PowerView again, again I'm not on a DC I just have I do have domain admin rights. Oh, I'm gonna show the bad guy's user OU location, he's in the OU Totes Not Evil, 'cuz that's a good way to hide. Totes Not Evil. Then we're gonna add all rights for this bad guy to principle to the Admin SD Holder Object in the current domain. Now, that was- that was the actual backdoor. Now we are we're gonna hide the principle, we're gonna change that object, that bad guy to, we're gonna change the owner of that to himself then we're gonna deny, hold on one second. We're gonna some of the raw some of the raw objects we need to do some of this manipulation. We're gonna deny everyone the ability to read the permissions on the object. Alright we're gonna do a complete generic all deny so no one can actually do anything on the object. And then we're gonna deny everyone the right to list the children of that Totes Not Evil OU. So this is completely hiding the principle. Commit that all off. And we could have run all these commands you know in three seconds. And we're gonna wait sixty minutes for SD Prop to run, we're back. We're gonna show we're gonna check if the rights propagated, so we're gonna enumerate the rights for a particular domain admin and we see the SID. You know that bad guy SID, shows up for generic all. But if we try to actually enumerate the bad guy to user, we can't find it through LDAP or DS Queried. Now this we're gonna refresh and that guy disappeared even though he's still there. So you know there's there's way that you could eventually you know take these things back over but it's hard to find. And now we're gonna use that, that account to show force resetting that domain admin's password. Then we're gonna do run as a CMV and now we have codex as a DA again. Cool stuff, hopefully. [Applause] I promise I'm not begging for an applause. Uh So LAPS, we don't have a demo video but we're gonna talk through it. So LAPS 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 ex extensions. That every thirty days the computer will randomly rotate its' Local Administrator Password and then store it in this protected attribute or this confidential attribute called MSMCSMN Password. So, the LAPS also includes a series of cmdlets released by Microsoft. So it's the uh the admin password dot PS cmdlets. There's one particular cmdlet called Find Admin Password Extended Rights that audits who can read, who has the rights to read this particular attribute. We're gonna show some issues with it but I want to emphasize up front that these cmdlets were not built as a security protection type thing, it was meant to find it was meant to find the results of who can actually audit these things based on the normal process that LAPS writes or 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. Uh the above checks you know also generic all because that will imply that DS Control Access. Also, you know that object control stuff that we talked about. So are you the owner? You know, can you modify the DACL and can you modify the owner? This list is also is not comprehensive, so the white paper was updated. There were several more flaws we discovered you know in just the few days before giving the presentation. These are the flaws. So DS Control if DS Control Access is flipped, but the ACE applies to all decedent objects instead of computer decedent objects, that's an edge case. Also it doesn't check if you're the owner, you can write the DACL, write the owner and it only analyzes OU's in the oppositionally specific computers. It doesn't check for things in the default you know user container computer. So here's a normal case. We has this uh, this John Smith user. And he is not able to read that LAPS password down there at the bottom. But if you run this find Admin Password Rights, you can see he's not listed. 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 within inheritance so when we add this ACE that particular John Smith principle will have the right to read the LAPS password forever whenever it's changed but the default auditing components release of LAPS will not find it. So this is a LAPS based backdoor. And here you see it actually executed. So John Smith, he's not in the server admins but he's able to read the LAPS backdoor despite not actually showing up in the default auditing on any cmdlets so cool. We think these issues will be fixed pretty soon. It was just we we dove pretty deep into some of the LAPS information. And again a ton more in the white paper. >> Okay so. >> This is my favorite. >> It's mine too, I'm a little bit biased though. Uh so, we mentioned how a third party applications can extend back to directory schema, they can add security groups, they can add control from groups to other principles in active directory. By far the biggest offender in this, is Microsoft Exchange. So with Microsoft Exchange server twenty sixteen, twenty thirteen, and two dozen seven SP one and forward, exchange server will create a group called Exchange Trusted Sub-System 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 DACL is protected by the admin SD Holder Object. Before 2007 SP one, this also included full control over everything. So essentially an exchanged server had the same privilege that a domain controller did. >> So if you're ever on a Pen Test 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 to where what we have seen is reality is of the Exchange Trusted Sub-System does have full control of everything. The domain object, domain admins, domain controller, enterprise admins, you name it, Exchange owns it. So for this, we're we're gonna go through a couple of steps to implement our backdoor. First of all, we want to find an object that we can backdoor that's not going to be very obvious for an auditor to find. So we're gonna ride existing privilege by finding a group that already has admin rights against one exchange server uhh through group delegation. So not just one that is like, if you did Net Local Group Administrators and you found that group we're gonna go further back. Then we're gonna grant authenticated users full control over that security group. We're gonna change the group that we're backdooring to the exchange server and then deny read permissions on that group to the everyone principle. How do we execute this? We're gonna regain access to active directory as any user on any computer. We're gonna add our current user because they are an authenticated user to the domain they have full control over this security group like everybody else. We're gonna add ourselves to that group and then now with our new found local admin rights on an exchange server, we're gonna use PS Exec, thanks Mark Russinovich, to execute mimikatz 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 times this means DC Sync. So we're gonna go into Bloodhound and we're gonna find the group that we're gonna backdoor. So we'll go to Domain Admins and we'll look at uh what other principles have control over the domain admins group. We can see that the Exchange Trusted Sub-System has full control over the domain admins group. And there are several computers that are added to the security group. We're gonna select one of those, we're gonna select Exchange zero zero one. And we're gonna see who the existing admins are on that box. Through Bloodhound we can automatically unrule out who all the affective admins of a system are by group delegation. And we can see there are there are seven users that have local admin admin rights on this system. There's a system on the right, that group is explicitly an admin. That group has a group there and in this intermediary group also has a group called Server Back Up 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 gonna backdoor that group. First we're gonna import PowerView, then we're gonna get the raw directory entry for the object. So server backup to tier two, the group. We're gonna grant authenticated users full control over that security group. That's done. Then we're gonna change the owner of the group to an exchange server. Just for anti-audit reasons. That's done. Then we're gonna deny read permissions on that group to the everyone principles. You can't easily audit this backdoor. And that's done. The backdoor is in. How do we execute this? We regain access to the environment as any user. Domain User, you're not an admin anywhere. Again, we're gonna import PowerView. And then we're going to add ourselves to that security group, Server Back-Up Tier Two. Which is now done. Then we're gonna use PS Exec to remotely run mimkatz as a system user on that exchange server. Then we're gonna DC Sync the curve TGT user. Which which we can then use a created golden ticket. And we effectively then own the domain. And it's done. [Applause] >> Cool. Exciting. Love, love those curve bashes. So this last one we don't have a video for but it's also the most complicated. But again, it's specked out and 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's to trustee. And then you kind of grant that patsy or proxy user the right DACL privilege to the default to main controller's GPO. That's the entire backdoor. And this is kind of a separate approach that we talked about in the paper of using alright a proxy or patsy type user instead of the actual attacker principle. So to execute it, get codex in the system again, you force reset the proxy's user password. You use that authentication context to add a DACL to that default to main controller's GPO. That grants oh that uh you're adding a DACL to the GPO that allows right access to that GPC file sys path. So we are granting ourselves the right to edit the GPO itself. Then we're going to grant through modifying the GPO the SE enabled delegation privilege. 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 for super protected property on user accounts. And the reason it is protected is 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 mimkatz and kikio. This is pretty complicated, I have some stuff in my blog in the uh earlier in January that goes in this in more detail. But cool stuff. Pretty subtle though right. It's just one user that's not the actual attacker. Then you have generic all on that. Use that user as a proxy to add the rights you want. 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, but they have to walk back every possibility of someone that might have had access or could gain access to that object. So you could this is again, kind of an anti- instance 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 the misconfiguration is introduced. So if this was introduced ten years ago and you didn't have this stuff tuned up or you don't have ten years of event log data which I don't think many people have, then you're not gonna 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 this is actually a pretty persistent strategy. But for example, if you want to stop these from being put in in the future, there's different event log ID's like, four seven three eighty's account want changed and you can filter these by the particular property modified. And you don't have to mon uh monitor for every single possible change, you just need to start monitoring PeaceMeal by all these kind of object takeover primitives that we talked about. And I'm also gonna be putting out a blog in hopefully the next few months that gives complete defensive guidance for every single ACL based uh takeover primitive that we've covered. >> [Inaudible] >> Okay. So Replication Metadata. Metadata remnants from domain controller or or are 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. As and I have a draft post that I'm gonna drop that goes into the replication metadata for hunting in a lot more detail. Also SACLs so, those System Access Control Lists that specify the types of access attempts that generate audit records in the security event log of the domain controller. SACLs have been around for forever. People don't use them because if you turn them on they're gonna be there's gonna be tons and tons and tons of events. But we really think that if you implement SACLs 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 you know really pay attention to the good stuff. There's a bit-ly link that has some more information on there. Future Work, we uh we worked really heavily with Lee Christensen tifkin on this stuff. And we tried really hard to set a null DACL for our otherwise manipulate the uh header control bits like SE DACL Present. See the idea being you know like you can do on host, setting a normal DACL so at anyone in you know any anybody authenticated users can have access. But any attempts to set the NT 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 uh SACL type auditing. So credits. We wanna, special thanks to all the people that helped us with the slide deck and research. Definitely uh Lee Christensen tifkin, uh he really really helped us. Uh Jeff Dimmick for content review. Everyone else at SpecterOps and also Matt Graeber who used to work with us gave us some really good feedback and some really, I don't 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. [Applause] [Laughter] >> Awkward white guy. [Applause]