00:00:00.375-->00:00:05.375 >> My name is Andy Robbins, this is Will Schroeder. Uh thanks for being here for our talk. Thank 00:00:07.625-->00:00:12.625 you, thank you, thank you. [Applause] The title of our talk An ACE Ip the Sleeve- Feigning 00:00:12.625-->00:00:17.542 Active Directory DACL base Backdoors. Uh quick information about me, my name is Andy 00:00:17.542-->00:00:23.000 Robbins, my handle is Waldo. Uh I’m a cofounder and founder on the Bloodhound project. [Cheers] 00:00:23.000-->00:00:27.708 I’ve spoken at places, done training. Um, if you really wanna get me excited come up and 00:00:27.708-->00:00:34.458 talk to me about the ACH file format and uh we can talk offline about that. [Laughs] >> 00:00:34.458-->00:00:38.583 Hi, my name is Will Schroeder, my handle is Harm Joy. I’m an offensive engineer at 00:00:38.583-->00:00:43.000 SpecterOps, with this guy. I’m a I’ve run a lot of code, I’ve helped write a good chunk of 00:00:43.000-->00:00:47.458 Veil-Framework, Empire/EmPyre, PowerView and PowerUp if any of you guys use that. Bloodhound, 00:00:47.458-->00:00:51.292 uh KeeThief. I really love active directory and dived into this research and it’s been a 00:00:51.292-->00:00:56.250 whole ton of fun. I’ve spoken at a few conferences. I’m a PowerSploit developer actively 00:00:56.250-->00:01:01.458 and I’m a Microsoft PowerShell MVP. SO somehow Microsoft doesn’t hate me that much I 00:01:01.458-->00:01:07.417 guess. >> Alright, so give you guys a quick TLDR. Where we are now, where were gonna be and 00:01:07.417-->00:01:11.000 where were gonna wind up. So first were gonna talk about DACLs and ACEs, what these are, 00:01:11.000-->00:01:15.042 how they work, why they matter. We’re gonna look at typical misconfigurations and how we can 00:01:15.042-->00:01:19.583 abuse these misconfigurations. We’ll look at how we can analyze this stuff easily with 00:01:19.583-->00:01:24.458 Bloodhound from offensive and defensive perspective. We will look at designed ACL Based 00:01:24.458-->00:01:28.167 Backdoors. And then we’re gonna show you some demos, some examples and case studies, and 00:01:28.167-->00:01:33.625 then finally at the end we’re gonna talk about like what we can actually do with all of this 00:01:33.625-->00:01:38.167 as as defenders. So an important caveat to keep in mind uh we’re not talking about 0-Day, we’re 00:01:38.167-->00:01:41.542 not talking about anything worthy of a CVE, really what we’re talking about is how to 00:01:41.542-->00:01:47.417 abuse the existing Windows uh security model uh for malicious purposes. UH. [Cheers] Thank 00:01:47.417-->00:01:53.750 you. [Laughs] Secondly, so we’re not dropping 0-Day, secondly, uh we’re talking about putting 00:01:53.750-->00:01:57.667 backdoors into an environment, most of the time you actually need to be already elevated to 00:01:57.667-->00:02:02.250 do that. So uh all of the stuff that we’re putting in we’re already domain admin, and then 00:02:02.250-->00:02:07.958 were looking at you know once we lose that, how do we get that back easily. >>So why care about 00:02:07.958-->00:02:13.833 this? Some of the few things hat we think are really cool about this approach or persistence is 00:02:13.833-->00:02:17.875 one, it’;s often very difficult to determine, if even if you find one of these 00:02:17.875-->00:02:22.000 misconfigurations, how do you tell if it’s malicious? It could have been put there you know 00:02:22.000-->00:02:25.958 almost by accident from some third party tool. Really old exchange install in a lot of the 00:02:25.958-->00:02:30.958 stuff we’re gonna talk about. These changes also will very often survive domain functional 00:02:30.958-->00:02:36.375 level upgrades and operating systems upgrades. So there’s remnants in a lot of domains in 00:02:36.375-->00:02:40.208 a lot of these misconfigurations. So a backdoor may have been put in ten years 00:02:40.208-->00:02:44.542 ago in a really insecure environment and even though the environments more secured now, 00:02:44.542-->00:02:49.042 these could have existed for years. And we hope this kind of scares you. And you know we’re 00:02:49.042-->00:02:53.833 gonna into some background and some stuff but finally bring it all together, we hope the 00:02:53.833-->00:02:57.667 examples really kinda hopefully terrify a few people. So I love this quote from Matt Graeber, 00:02:57.667-->00:03:03.542 he’s actually up here in uh in one of the rows. So as an offensive engineer, if you can 00:03:03.542-->00:03:09.208 dream it, someone has likely already done it and that someone isn’t the kind of person who 00:03:09.208-->00:03:14.583 comes speaks at security cons like DefCon so, we’re not we fully believe like we are not 00:03:14.583-->00:03:19.083 the first ones to come up with this idea. We think that you know difference advanced 00:03:19.083-->00:03:22.500 adversaries have probably almost certainly come to the same conclusions. So a big thing to 00:03:22.500-->00:03:26.958 this talk is we want to bring attention to the problem. The research isn’t complete, but 00:03:26.958-->00:03:31.875 we’re excited and you know, this may have already happened. >> Alright so, let’s talk about 00:03:31.875-->00:03:36.958 some background. First of all we need to acknowledge some existing work uh first and most 00:03:36.958-->00:03:42.333 importantly is this uh French project from ANSSI which is the French equivalent of the NSA. Uh 00:03:42.333-->00:03:46.375 the two guys who did this work, uh Lucas Bouillot and Emmanuel Gras. Uh this is the active 00:03:46.375-->00:03:51.250 directory control paths project. If you hadn’t had a chance, I recon recommend you go and take 00:03:51.250-->00:03:56.667 a look at it. We learned a lot about the uh Windows Security Model and DACLs and ACEs from 00:03:56.667-->00:04:02.083 their White Paper. They also serve as initial inspiration for using a an attack graph to model 00:04:02.083-->00:04:05.208 an attack paths in an environment. So they served as initial inspiration for our 00:04:05.208-->00:04:08.667 Bloodhound project as well, early on. >> We also had to run the White Paper through Google 00:04:08.667-->00:04:12.792 Translate because we’re stupid Americans and can’t speak any other languages so we think we 00:04:12.792-->00:04:17.333 got all the details right. We think we got some cool stuff but I’m sure there might have been 00:04:17.333-->00:04:19.875 some stuff that we we missed. >> There’s also this work from Robin Brandgard at Microsoft. 00:04:19.875-->00:04:24.958 This is the AD ACL Scanner. uh let’s you do things like export ASUS to CSV you can do basic 00:04:24.958-->00:04:30.500 diffing. Uh if you want to know more about that, look at the uh tech net link there. And the 00:04:30.500-->00:04:35.250 deck is obviously going to be online after. Uh and then next, there’s also this other project 00:04:35.250-->00:04:40.917 called BTA. Uh unfortunately we missed this before our Black Hat talk so uh this is from he team 00:04:40.917-->00:04:47.208 at Air Bus for trying to get a wrangle on Active Directory ASUS as well. >> One, one thing to 00:04:47.208-->00:04:52.500 note like they do some really cool analysis but you need an offline NTDS dot DAT. In our 00:04:52.500-->00:04:56.458 case everything were showing will be done remotely through LDAP wrapped into Power Shell 00:04:56.458-->00:05:01.375 but there’s other weaponization methods obviously. >> So when we first starting looking at this 00:05:01.375-->00:05:06.667 we had the idea like how could we implement backdoors that abuse uh active directory uh 00:05:06.667-->00:05:10.167 object control. We scoured the internet as well as we could. This is the closest thing that 00:05:10.167-->00:05:15.625 we could find. Uh it’s a blog post from twenty ten written in Russian obviously. This was all 00:05:15.625-->00:05:19.167 we could find. And we figured like if the only thing we could find was written in Russian, we 00:05:19.167-->00:05:24.500 were probably on the right track. Uh [Laughter] They also in in in this blog post this guy 00:05:24.500-->00:05:29.500 also talked about uh hiding the existence of Active Directory of Principles which would uh we 00:05:29.500-->00:05:34.875 built on and I think we improved on in a couple different ways. Uh so yeah, check out that 00:05:34.875-->00:05:40.708 blogpost and run that through Google Translate. Cool so, we’re gonna go into a little bit of 00:05:40.708-->00:05:45.333 technical background. I know this might not be as super interesting some of these few 00:05:45.333-->00:05:49.667 slides. But you really need some of the background of this stuff to understand why and how these 00:05:49.667-->00:05:55.333 backdoors work. So securable objects and Windows. A securable object is defined by as pretty 00:05:55.333-->00:05:59.625 much as an object that has a security descriptor. This is a breakdown of the binary 00:05:59.625-->00:06:03.042 structure. So there there’s a lot of pieces to this, you know header, bits all this kind of 00:06:03.042-->00:06:08.542 stuff. That all this can be expressed as a SDDL. So uh a Security Descriptor Definition 00:06:08.542-->00:06:11.875 Language string. If you guys have ever seen that. We’re not gonna really kinda cover that 00:06:11.875-->00:06:17.542 too much. The pieces that we care about are the owner. So the SID of the owner, you know for 00:06:17.542-->00:06:22.375 our particular object and we care about the DACL. So the pointer to that DACL here at the 00:06:22.375-->00:06:26.417 end. So if you’re not familiar with Active Directory, you’re not familiar with the access 00:06:26.417-->00:06:30.542 control model. People throw around ACL, DACL, SACL and all these types of things. People 00:06:30.542-->00:06:35.500 often use them interchangeably as well. So essentially, the access control list, the ACL for 00:06:35.500-->00:06:40.333 an object is basically shorthand for the uh the DACL and SACL super set. So the Discretionary 00:06:40.333-->00:06:45.375 Access Control List that you saw on the last slide and the System Access Control List, the SACL. 00:06:45.375-->00:06:49.583 These are ordered collections of Access Control Entries. So it’s a pointer from the binary 00:06:49.583-->00:06:56.125 structure and memory to an array of these Access Control Entires. The DACL specifies what 00:06:56.125-->00:07:00.958 principles or trustees is another term have what rights over the object. Nothing crazy 00:07:00.958-->00:07:05.500 right? The SACL allows for auditing of access attempts to the object. We’re not really 00:07:05.500-->00:07:09.917 gonna dive into SACLs we’re gonna cover a little bit at the end but you know in this in this 00:07:09.917-->00:07:16.500 case we’re just mostly going to cover the DACL. So the in an Access Control Entry, there’s 00:07:16.500-->00:07:21.583 some bits, there’s some 32 bit fields that control kind of some auditing kind of components. 00:07:21.583-->00:07:27.333 There’s a there’s a lot of stuff in there. What we really care about for one, it’s the the 00:07:27.333-->00:07:33.167 owner or sorry the principle that has the rights over the object for this particular entry 00:07:33.167-->00:07:39.167 and then the access mass. Which is a 32 bit field that what those rights are. This is what 00:07:39.167-->00:07:43.250 it will look like in ADUC, in Active Directory Users and Computers. So you can see that 00:07:43.250-->00:07:48.083 the principle is sorry up there all the way up at the top right the object is victim so victim 00:07:48.083-->00:07:52.333 user their principle is harm joy so so Harm Joy has these rights. There’s lots of rights in there 00:07:52.333-->00:07:55.667 and the ones we care about are you know like modify the permissions on the object, 00:07:55.667-->00:08:00.667 modify the owner. So again this is just the access mask. There’s one bit in the access mask that 00:08:02.958-->00:08:08.708 we we particularly care about. So in those headers kind of like the control bits in this ACE 00:08:08.708-->00:08:14.750 Entry uh with this Access Mask there’s a DS Control Bit so this is interpreted in one of two 00:08:14.750-->00:08:21.667 ways. So if the target GUI or the target GUID, for the object ACE type for that particular ACE 00:08:21.667-->00:08:27.500 is a confidential attribute so the most common case is LAPS right. So you don’t want 00:08:27.500-->00:08:32.500 everyone to be able to read that LAPS password and we’ll go into LAPS in a little bit. If control 00:08:34.750-->00:08:40.208 DS Control Access is flipped then that grants read access to that confidential attribute so 00:08:40.208-->00:08:46.042 that’s one particular way to interpret it. The second way is extended rights. So if the 00:08:46.042-->00:08:50.500 ObjectAceType GUID matches a registered extended right that is registered in the forced 00:08:50.500-->00:08:55.458 Schema, say User-Force-Change-Password or DS-Replication-Get-Changes and 00:08:55.458-->00:08:59.667 Replication-Get-Changes-All. So these are DC synch rights. So those are registered in the 00:08:59.667-->00:09:06.083 forced schema already and that GUID uh you know is resolved and actually points to a particular 00:09:06.083-->00:09:11.333 extended right. Then flipping the DS Control Access will grant a control access right for this. 00:09:11.333-->00:09:15.250 So it’s a way that Extended Rights are granted. Extended Rights are just a way to you 00:09:15.250-->00:09:21.125 know like I mentioned, extend the actual generic rights that are available in that 32 bit 00:09:21.125-->00:09:26.542 access mask. >> Okay, so the part of the operating system that is actually in charge of 00:09:26.542-->00:09:30.583 evaluating these ACEs uh and what is called Canonical Order is the Colonel Mode Security 00:09:30.583-->00:09:36.708 Reference Monitor. So the SRM takes an access request for a given principle against another 00:09:36.708-->00:09:42.500 object and evaluates the DACL in that Canonical Order to make an access decision whether access 00:09:42.500-->00:09:48.542 is allowed or denied. Importantly, we can use we can abuse this function of SRM to 00:09:48.542-->00:09:55.208 hide pri uh principles or to hide the existence of DACLs. The way that we do this is we abuse 00:09:55.208-->00:10:00.083 the fact that ex explicitly defined ACEs on an object are always they always take 00:10:00.083-->00:10:05.792 precedence over inherited uh ACEs. So let’s look at an example here. We have this OU 00:10:05.792-->00:10:10.792 called IT. And on that OU, I’m gonna specify an Explicit Deny ACE. Let’s say it’s just for 00:10:10.792-->00:10:15.417 full control. That’s gonna inherit down to the OU that can is contained there called help 00:10:15.417-->00:10:20.625 desk. And then the Robby Winchester user at the bottom of this OU tree also gets this ACE 00:10:20.625-->00:10:26.500 inherited down to it. Well what if I put a conflicting ACE in the inter intermediary OU? So at 00:10:26.500-->00:10:32.292 help desk I say well wait a minute I want to have an Explicit Allow. The Explicit 00:10:32.292-->00:10:37.958 Allow takes precedence over the inherited deny even though typically denies are given 00:10:37.958-->00:10:44.667 precedence over allows. Finally on the Robby Winchester user I specify two explicit ACEs on 00:10:44.667-->00:10:50.250 there. An Explicit Allow and an Explicit Deny. So the order that you see on here is what is 00:10:50.250-->00:10:57.083 called the Canonical Order and is based on inheritance from parent and grand parent OUs. So 00:10:57.083-->00:11:01.708 the Explicit Deny will be evaluated first, then the Explicit Allow, then the 00:11:01.708-->00:11:06.833 Inherited Allow and then finally the Inherited Deny. The green Inherited Allow on Robby 00:11:06.833-->00:11:12.667 Winchester is given precedence over the other inherited ACE. Because generationally that OU 00:11:12.667-->00:11:17.667 that inherits that ACE from is closer. So let’s look at some typical DACL misconfigurations 00:11:20.417-->00:11:25.542 for how we can do object takeover and how we can abuse these. Under that caveat that I 00:11:25.542-->00:11:31.875 remind you of, uh we’re talking during this talk primarily about persistence. We’re not looking 00:11:31.875-->00:11:36.708 at privilege escalation for this talk. We do have content on my blog if you want to read about 00:11:36.708-->00:11:41.708 that. Uh but the primitives for object takeover are gonna be the same. Additionally we’re looking 00:11:43.958-->00:11:48.833 at chaining together multiple different control relationships between different principles to 00:11:48.833-->00:11:55.708 make this very very difficult for defender to find. So you have User Objects and Active 00:11:55.708-->00:12:01.417 Directory, how can we take over a User Object by by abusing these Access Control Entries? 00:12:01.417-->00:12:06.500 There are two primitives that we have for you. One we could do a targeted Kerberoasting attack. 00:12:06.500-->00:12:12.750 By a show of hands, who knows what Kerberoasting is? After our talk is done, go read Sean 00:12:12.750-->00:12:17.583 Metcalf’s blog about Kerberoasting. It’s gonna change your life. So basically we can 00:12:17.583-->00:12:23.542 set a value on a service principle name for a user and then we can request a Kerberoast 00:12:23.542-->00:12:29.500 ticket back from the domain controller for that user as any other user. And then we can 00:12:29.500-->00:12:34.792 crack that ticket and recover that user’s clear text password. Anybody in that domain can do 00:12:34.792-->00:12:40.542 this. Secondly we can change the user’s password without knowing its’ current value. This is with 00:12:40.542-->00:12:44.750 the privilege that you give your help desk so that they can change people’s passwords after 00:12:44.750-->00:12:50.042 they fat finger and lock themselves out. At the bottom here, we have two cmdlets that 00:12:50.042-->00:12:55.792 can abuse these. Set-DomainObjectOwner and Set-DomainUserPassword. There’s 00:12:55.792-->00:13:01.500 also one for setting a user SPO. How can we take over a group object? Well what we’re 00:13:01.500-->00:13:05.583 interested in is not necessarily the group but we’re interested in the privileges that the group 00:13:05.583-->00:13:11.750 has. So if we have the ability to add an arbitrary user to that group we can give ourselves the 00:13:11.750-->00:13:17.750 same rights that that user has and ride that existing privilege forward. We can WriteProperty to 00:13:17.750-->00:13:22.583 all properties that do this or we can have Write access only to the member property and we can 00:13:22.583-->00:13:29.208 add a user to that group. In PowerView you do this with Add dash Domain Group Member. For 00:13:29.208-->00:13:34.292 Computer Objects this gets a little bit tricky because the only thing we know of right now 00:13:34.292-->00:13:38.917 is being able to abuse a LAPS installation. And so if our user has the ability to read the 00:13:38.917-->00:13:43.250 local Admin Password attribute on the computer object. Obviously we can pivot to that 00:13:43.250-->00:13:49.875 system and can be a local admin. If you have other ideas about this we are very very excited to 00:13:49.875-->00:13:54.250 hear it, we are all ears. >> One thing to note as well is we are not claiming that this kind of 00:13:54.250-->00:13:58.625 taxonomy complete. These are some of the primitives that we’ve found that we’ve used to 00:13:58.625-->00:14:03.250 you know operationally but we know for sure there are other types of object takeover 00:14:03.250-->00:14:07.375 relationships. So, the point of this talk is not to show you every way to take over any 00:14:07.375-->00:14:13.417 object, it’s to show you chains of these kind of interesting backdoors. >> Uh next, Domain 00:14:13.417-->00:14:17.583 Objects. So even though I’m not a local admin on a domain controller. Even though Im not a 00:14:17.583-->00:14:21.833 domain admin, if I have full control over the Domain Object, which represents the active 00:14:21.833-->00:14:28.625 Directory Domain, I can DCSync. DCSync if you’re familiar allows me to remotely request an NT 00:14:28.625-->00:14:33.750 Hash for any other user in the Domain if I have that privilege. >> Thank you Benjamin Dailey and 00:14:33.750-->00:14:39.250 Vincent Latour for DCSync. >> Yes. Yes. Uh so the two explicit privileges that we actually need 00:14:39.250-->00:14:43.500 for this. We don’t need full control of the Domain Object, we need DS Replication Get Changes 00:14:43.500-->00:14:48.417 and DS Replication Get Changes All. Then we can request NT Hashes for any user including 00:14:48.417-->00:14:53.417 the Curve TGT. Which is interesting and we’ll show you why later. >> So Group Policy 00:14:55.458-->00:15:00.000 Objects. This is one of the few relationships that we don’t have incorporated into the Bloodhound 00:15:00.000-->00:15:03.500 Schema yet because we’re gonna have to write a custom path finding algorithm that can 00:15:03.500-->00:15:08.333 handle all the weird inheritance issues. What the main takeover primitive is, can you modify the 00:15:08.333-->00:15:14.458 GPO? You can modify the GPO. These GPOs are linked to OU, sites, and domains. And there 00:15:14.458-->00:15:19.333 are users, groups and computers contain within these. So if you can modify the GPO, there’s a 00:15:19.333-->00:15:23.500 million and one ways that you can get code execution on a computer to supply it to. Or you 00:15:23.500-->00:15:28.792 can get essentially code execution the context of the user that the GPO is applied to. 00:15:28.792-->00:15:32.333 So the rights to care about here are Write Property and to all properties like some of the 00:15:32.333-->00:15:37.083 other examples. And Write Property specifically to the GPC-File-Sys-Path. This 00:15:37.083-->00:15:43.083 represents the right to actually modify the GPO. And if you modify the permissions on this, 00:15:43.083-->00:15:47.042 those permissions will actually clone down to the file system in SYSVOL. So if you have the 00:15:47.042-->00:15:52.708 rights or modify the rights, then you can just go straight to SYSVOL and modify any of the GPO 00:15:52.708-->00:15:59.625 settings. There’s a set of a few rights that apply to pretty much all the objects. So Generic All, 00:15:59.625-->00:16:03.500 so connect to all generic rights like we mentioned. It also covers some of the controller 00:16:03.500-->00:16:07.500 object takeover rights that we’re gonna cover in the next slide. Generic Write allows for 00:16:07.500-->00:16:13.375 the modification to almost all properties except for those confidential properties uh 00:16:13.375-->00:16:18.208 handled by that DS control access bit. These are abusable by PowerView’s set the domain 00:16:18.208-->00:16:21.792 object. Again this is how you can do that targeted Kerberoasting. And again these 00:16:21.792-->00:16:26.792 rights normally apply to most objects for take over. So Control Rights. These are rights 00:16:29.208-->00:16:34.667 that allow principle or trustee to take control of the particular object. So if you 00:16:34.667-->00:16:39.958 have Write DACL, you have the ability to modify the security information for an Object. You 00:16:39.958-->00:16:43.833 can add whatever new ACE entries you want. So you can grant yourself whatever rights. So if 00:16:43.833-->00:16:48.333 you WriteDACL in the domain then you can grant yourself DCSync rights. And again that’s 00:16:48.333-->00:16:54.708 abusable with Add Domain ACL. With Write Owner. Owners have implicit full control of the 00:16:54.708-->00:17:00.333 object despite any existing you know deny ACEs or anything like that. This will come into play 00:17:00.333-->00:17:04.625 when we actually wanna hide the DACL and things here in a little bit. So this is also available 00:17:04.625-->00:17:09.625 PowerView with set Domain Object Owner. >> Okay, so , let’s slow down for a second. let’s do some 00:17:11.833-->00:17:16.333 visuals uh to kinda make sense of what all we’re talking about. We’re gonna look at some like 00:17:16.333-->00:17:21.375 analysis that we can do with the bloodhound interface. We added several of these ACEd edges into 00:17:21.375-->00:17:26.667 the Bloodhound database so that you can hopefully, easily map out what these existing control 00:17:26.667-->00:17:30.708 relationship looks like. >> That’s uh the one point three update that happened just about 00:17:30.708-->00:17:36.000 a month or two ago. >> So for defenders we hope that you guys can use this for uh enforcing 00:17:36.000-->00:17:42.083 your lease privilege uh policies uh for identify what ACLs may be misconfigured and giving people 00:17:42.083-->00:17:47.042 more privilege than they actually need. Uh and then detecting some of the more non 00:17:47.042-->00:17:53.375 stealthy uh DACL based backdoors. As an attacker we can use this to find uh ACL based 00:17:53.375-->00:17:58.417 escalation paths. Uh we can also look for principles that are interesting for us, a back door 00:17:58.417-->00:18:04.583 based on the existing privilege that they have. And we can also understand the existing uh you 00:18:04.583-->00:18:09.917 know situation there is with ACLs and you know do we really care about being sneaky in the 00:18:09.917-->00:18:14.875 first place? So this is the Bloodhound interface. The default view we see the domain 00:18:14.875-->00:18:19.917 admins. We’ll click on the domain admins group, and we'll look at inbound object controls. 00:18:19.917-->00:18:23.958 So who has control of this group? From the first degree perspective we see that there 00:18:23.958-->00:18:29.917 are six groups that have control over the domain admins. Several of them are generic all 00:18:29.917-->00:18:34.792 privilege and then one of them is right DACL privilege. You may notice that a lot of these are 00:18:34.792-->00:18:41.125 exchange groups. These groups also include other groups, and computers and users. So if you 00:18:41.125-->00:18:46.000 unrule this out you can see that there are actually in fact twenty nine principles that have 00:18:46.000-->00:18:52.083 full control of the Domain MS Group, because of security group delegation. Well what if I want 00:18:52.083-->00:18:58.167 to unwind this out and say who can take control over all these principles. What we call this is 00:18:58.167-->00:19:03.167 Transitive Object Control or an ACL only Attack Path. I can do that with Bloodhound, after I 00:19:05.292-->00:19:11.667 finish doing this right here. It's showing you the group delegation. So let's go back 00:19:11.667-->00:19:16.750 into Inbound Object Control. Transitive Object Controllers, there are actually fifty of 00:19:16.750-->00:19:20.917 them. So there are fifty objects that have a ACL only attack path to be able to take control of 00:19:20.917-->00:19:26.167 the Domain Admins Group. These users here all belong to a group called Identity Administrators 00:19:26.167-->00:19:30.667 which is a member of this group called Account Operators. That has force change password over 00:19:30.667-->00:19:35.167 this user which is a member of the domain admins group. So let's look at something a little 00:19:35.167-->00:19:40.167 more interesting and complex. This user here belongs to a group which also belongs to a 00:19:43.250-->00:19:48.250 group, that can change this user's password who can change this user's password, who's a 00:19:51.000-->00:19:56.000 member of this group, who has full control of the Domain Admin's Group. So that's Inbound 00:19:59.750-->00:20:05.458 Object Control. What we can also easily audit is outbound Access Control. So for a given 00:20:05.458-->00:20:10.417 principle, what privileges do they have against other objects? So I'll find this user here 00:20:10.417-->00:20:15.750 called R-taylor and go to outbound object control. First degree object control, it's zero 00:20:15.750-->00:20:20.208 because that user itself is not specified as a principle having privilege against another 00:20:20.208-->00:20:25.417 object. For group delegated control. There are four users that he has the ability to take 00:20:25.417-->00:20:30.417 control of because of security group delegation. What I can also say is Transitive Outbound 00:20:32.958-->00:20:39.333 Object Control. So if I can take over any of these four users, then what? What can I do? 00:20:39.333-->00:20:43.750 Bloodhound finds this easily. And I see that for Transitive Object Control I have control 00:20:43.750-->00:20:48.958 over all these principles here by ACL Only Attack Path. So this user belongs to this group, 00:20:48.958-->00:20:55.208 belongs to that group, who can change that user's password, who's a member of that group, 00:20:55.208-->00:21:00.208 who has control over all these other users over here. That's it. Alright, thanks. [Applause] 00:21:07.833-->00:21:12.833 Pretty good on time. So let's look at how we can actually design backdoors based on these 00:21:16.875-->00:21:23.000 uh principles. So what our objective is we want to be able to get back into an active 00:21:23.000-->00:21:27.042 directory environment on any computer and be able to instantaneously escalate our 00:21:27.042-->00:21:31.417 privileges back up to whatever we want. Maybe that's Enterprise Admin, maybe that's Domain 00:21:31.417-->00:21:37.000 Admin, maybe it's local admin on a system. We want to be able to blend in with normal ACL's that 00:21:37.000-->00:21:43.958 already exist in the environment so let's see what we can come up with. So how can we hide the 00:21:43.958-->00:21:47.375 DACL? I just showed you with Bloodhound on how we can audit the DACL's. But what if I don't 00:21:47.375-->00:21:53.167 want you to be able to audit the DACL as a defender? This requires two steps. I change the 00:21:53.167-->00:21:59.208 object owner for the object I am backdooring away from domain admins to another principle I 00:21:59.208-->00:22:04.792 control or the principle itself. >> And remember that's because object owners have implicit full 00:22:04.792-->00:22:10.708 rights despite any explicit denies than what exists in the chain. >> Secondly I will add a 00:22:10.708-->00:22:17.125 new explicit deny ACE which recall will take precedence over anything else in the DACL. And I 00:22:17.125-->00:22:22.792 say the Everyone Principle is denied the read permission privilege. Then I can't audit 00:22:22.792-->00:22:27.125 the DACL from any of the principle except for the one that's backdoored. Here's what 00:22:27.125-->00:22:32.125 it looks like in ADUC GUEY for setting this. So I'm saying the principle everyone is denied, 00:22:34.958-->00:22:40.042 read permissions. It's that simple. I can also hide the existence of a principle that 00:22:40.042-->00:22:46.792 I'm backdooring. And this requires three steps. First of all, I need to change the object 00:22:46.792-->00:22:51.792 owner. Because owners always have full control. Then I'll grant explicit control either to 00:22:51.792-->00:22:57.875 the object itself or another object that I control. And then on the OU that contains this 00:22:57.875-->00:23:03.292 user, or group, or computer, whatever it is that I am backdooring, I'm gonna say that 00:23:03.292-->00:23:08.750 everyone is denied, the list contents privilege. And then when they try to look up that 00:23:08.750-->00:23:15.292 user in ADUC or LDAP or with a Net Executable, they can't see it. Here's it looks like an 00:23:15.292-->00:23:20.792 ADUC. I assure you there is a user in this OU. You cannot see it. >> Well these uh, these uh, 00:23:20.792-->00:23:26.208 these stealth primitives that we're gonna factor into some of the case study demos at the end 00:23:26.208-->00:23:30.292 of the presentation. >> So to summarize, we know how we can abuse ACEs to take over other 00:23:30.292-->00:23:35.750 objects. We know that we can control who has the ability to audit the DACLs and we know that 00:23:35.750-->00:23:39.917 we can hide the principles and trustees from easy identification. >> Cool, so 00:23:39.917-->00:23:45.125 remember that quote. Uh you know, if you can dream it, if you can imagine it, it's 00:23:45.125-->00:23:49.958 probably already been done. We're gonna go over five case studies that we were able to 00:23:49.958-->00:23:54.750 come up with in the course of this research. You know we're two guys in a basement just 00:23:54.750-->00:23:57.792 figuring this out for the first time, and thought for about a week what's some cool stuff we 00:23:57.792-->00:24:02.333 could do. If you actually had people much smarter than us with with a lot more money and time 00:24:02.333-->00:24:07.042 and you know funding, I'm sure it could be even you know more subtle on kind of crazy things 00:24:07.042-->00:24:12.583 you could do with this. So the first one like we mentioned, you don't need to be Domain Admin to 00:24:12.583-->00:24:18.750 DCSync. DCSync is entirely dependent on two ACEs on the principle domain object and 00:24:18.750-->00:24:24.458 again all domains are a domain is actually represented as a domain object and active 00:24:24.458-->00:24:29.042 directory. So if we do implement the backdoor then these will all kind of follow the standard 00:24:29.042-->00:24:33.792 we'll show how to implement the backdoor and then we'll show how to execute the backdoor. So if 00:24:33.792-->00:24:39.208 we add manually DCC DS Replication Get Changes and Replication Get Changes All 00:24:39.208-->00:24:44.750 Rights to the Domain Object, then this user who's the attacker controlled user, who's 00:24:44.750-->00:24:51.542 not in any privileged groups, you know just stock just created user has the ability to DCSync 00:24:51.542-->00:24:56.750 any user's account forever. Unless defenders actually figure out these rights to the domain 00:24:56.750-->00:25:01.917 object and actually remove them. >> So uh one thing to add to that is you can do DCSync 00:25:01.917-->00:25:05.083 remotely, you don't code execution on a domain controller. So you can do this 00:25:05.083-->00:25:11.375 from any domain joint system. >> Here's a video, so okay I'm going to go ahead and import 00:25:11.375-->00:25:17.250 PowerView and then the bad guy user is going to be our attacker kind of controlled principle. 00:25:17.250-->00:25:22.042 I'm just gonna show that the bad guy user is not in any privileged groups. This is brand 00:25:22.042-->00:25:27.625 new. We're gonna save the Sid for the bad guy user off and then next we're gonna use and 00:25:27.625-->00:25:32.208 again all this PowerView stuff, we're gonna use uh an ACL enumeration cmdlet and show you 00:25:32.208-->00:25:36.917 that there are no explicit ACEs on the object where the bad guy is the principle. Then we're 00:25:36.917-->00:25:42.000 gonna use add domain object ACL and we're gonna grant DCSync rights. You can do this in your 00:25:42.000-->00:25:48.250 lab tomorrow. We're gonna add those then we're gonna enumerate those rights again and just show 00:25:48.250-->00:25:53.250 you that these new explicit ACEs have been added. You see, okay, there's a Sid for that bad guy 00:25:55.917-->00:26:01.583 user. And he has now has these DCSync Replication Rights. Cool, cool. Now we're gonna pop up a 00:26:01.583-->00:26:05.250 window that had you know it'a a little small, but when we're running this bad guy, we tried 00:26:05.250-->00:26:11.125 to DCSync previously. We're gonna try it again and now we have DCSync Rights despite them 00:26:11.125-->00:26:16.375 not being in any any privilege group. So starting simple, nothing too you know. [Applause] 00:26:16.375-->00:26:22.667 Thank you. You know this this is a pretty simple example of an ACL based backdoor, and we're 00:26:22.667-->00:26:27.333 gonna get a lot more complicated. So Admin SD Holder, I don't have time to completely 00:26:27.333-->00:26:31.708 go into this. This is also a good time to note that for we gave this presentation at Black 00:26:31.708-->00:26:37.167 Hat and we wrote a sixty four page white paper that goes into excruciating details for all 00:26:37.167-->00:26:40.292 these things. That will be released through Black Hat and also through our website at 00:26:40.292-->00:26:45.042 SpecterOps dot I O. Uh we're gonna release release it probably next week, so if you 00:26:45.042-->00:26:48.875 are interested in this stuff there's gonna be tons more background and examples, and 00:26:48.875-->00:26:53.208 mitigation and all that fun stuff. So thirty second summary. Admin SD Holder essentially acts 00:26:53.208-->00:26:59.042 like a permission template for highly privilege groups. So to implement the backdoor they 00:26:59.042-->00:27:05.333 tacker grants themselves force change password or generic all rights to this CN Admin SD 00:27:05.333-->00:27:09.417 Holder System this. this object exists in every single domain. So they add it to the object 00:27:09.417-->00:27:15.500 itself. Then every sixty minutes a special process called the Security Descriptor Propagator 00:27:15.500-->00:27:20.792 Process or SD Prop will run. It will enumerate all the privileged groups like 00:27:20.792-->00:27:25.042 Enterprise Admins Account Operators Domain Admins, and if the Permissions on those objects 00:27:25.042-->00:27:30.542 differ than the template in Admin SD Holder, it takes the permissions from AdminSD Holder 00:27:30.542-->00:27:35.083 and then imprints on to on to the secured, you know highly privileged groups. Then the 00:27:35.083-->00:27:39.792 attacker hides the principle using the methods described. We don't wanna hide the DACL here 00:27:39.792-->00:27:45.125 because this is gonna be cloned off into every domain admin and enterprise admin and all that 00:27:45.125-->00:27:50.208 kinda stuff. But we complicate it and make it kinda look like an orphaned object. Then to 00:27:50.208-->00:27:54.667 execute, the attacker force resets the password for any account that has admin count 00:27:54.667-->00:28:00.167 equals one, any privileged account. And we have a demo for this too. Okay. I'm gonna load 00:28:00.167-->00:28:04.792 up PowerView again, again I'm not on a DC I just have I do have domain admin rights. Oh, 00:28:04.792-->00:28:09.792 I'm gonna show the bad guy's user OU location, he's in the OU Totes Not Evil, 'cuz that's a 00:28:12.125-->00:28:18.542 good way to hide. Totes Not Evil. Then we're gonna add all rights for this bad guy to 00:28:18.542-->00:28:23.667 principle to the Admin SD Holder Object in the current domain. Now, that was- that was the 00:28:23.667-->00:28:29.167 actual backdoor. Now we are we're gonna hide the principle, we're gonna change that object, 00:28:29.167-->00:28:32.750 that bad guy to, we're gonna change the owner of that to himself then we're gonna deny, 00:28:32.750-->00:28:37.708 hold on one second. We're gonna some of the raw some of the raw objects we need to do some of 00:28:37.708-->00:28:44.167 this manipulation. We're gonna deny everyone the ability to read the permissions on the 00:28:44.167-->00:28:48.125 object. Alright we're gonna do a complete generic all deny so no one can actually do anything on 00:28:48.125-->00:28:52.875 the object. And then we're gonna deny everyone the right to list the children of that Totes Not 00:28:52.875-->00:28:59.625 Evil OU. So this is completely hiding the principle. Commit that all off. And we could have 00:28:59.625-->00:29:03.792 run all these commands you know in three seconds. And we're gonna wait sixty minutes for SD 00:29:03.792-->00:29:08.667 Prop to run, we're back. We're gonna show we're gonna check if the rights propagated, so we're 00:29:08.667-->00:29:14.042 gonna enumerate the rights for a particular domain admin and we see the SID. You know that bad 00:29:14.042-->00:29:20.667 guy SID, shows up for generic all. But if we try to actually enumerate the bad guy to user, 00:29:20.667-->00:29:25.667 we can't find it through LDAP or DS Queried. Now this we're gonna refresh and that guy disappeared 00:29:27.917-->00:29:32.125 even though he's still there. So you know there's there's way that you could eventually you 00:29:32.125-->00:29:37.000 know take these things back over but it's hard to find. And now we're gonna use that, that 00:29:37.000-->00:29:42.000 account to show force resetting that domain admin's password. Then we're gonna do run as a CMV 00:29:45.208-->00:29:50.208 and now we have codex as a DA again. Cool stuff, hopefully. [Applause] I promise I'm not 00:29:52.458-->00:29:58.458 begging for an applause. Uh So LAPS, we don't have a demo video but we're gonna talk through it. 00:29:58.458-->00:30:03.958 So LAPS is Microsoft's Local Administrator Password Solution. It's an awesome, awesome, free 00:30:03.958-->00:30:09.250 thing that Microsoft released. It's a series of client side and schema ex extensions. That every 00:30:09.250-->00:30:14.083 thirty days the computer will randomly rotate its' Local Administrator Password and then 00:30:14.083-->00:30:18.333 store it in this protected attribute or this confidential attribute called MSMCSMN 00:30:18.333-->00:30:24.250 Password. So, the LAPS also includes a series of cmdlets released by Microsoft. So it's 00:30:24.250-->00:30:30.125 the uh the admin password dot PS cmdlets. There's one particular cmdlet called Find Admin 00:30:30.125-->00:30:36.417 Password Extended Rights that audits who can read, who has the rights to read this particular 00:30:36.417-->00:30:43.167 attribute. We're gonna show some issues with it but I want to emphasize up front that these 00:30:43.167-->00:30:48.875 cmdlets were not built as a security protection type thing, it was meant to find it was 00:30:48.875-->00:30:54.625 meant to find the results of who can actually audit these things based on the normal process that 00:30:54.625-->00:31:00.333 LAPS writes or delegated. But there's a few edge cases. So here's who can actually read 00:31:00.333-->00:31:04.875 Admin password. We have some DS Control and a whole bunch of like inheritance kind of issues. 00:31:04.875-->00:31:09.250 Uh the above checks you know also generic all because that will imply that DS Control 00:31:09.250-->00:31:13.500 Access. Also, you know that object control stuff that we talked about. So are you the 00:31:13.500-->00:31:18.125 owner? You know, can you modify the DACL and can you modify the owner? This list is also is not 00:31:18.125-->00:31:22.375 comprehensive, so the white paper was updated. There were several more flaws we discovered 00:31:22.375-->00:31:28.375 you know in just the few days before giving the presentation. These are the flaws. So DS 00:31:28.375-->00:31:34.667 Control if DS Control Access is flipped, but the ACE applies to all decedent objects instead of 00:31:34.667-->00:31:38.875 computer decedent objects, that's an edge case. Also it doesn't check if you're the 00:31:38.875-->00:31:42.958 owner, you can write the DACL, write the owner and it only analyzes OU's in the 00:31:42.958-->00:31:47.958 oppositionally specific computers. It doesn't check for things in the default you know 00:31:50.583-->00:31:56.833 user container computer. So here's a normal case. We has this uh, this John Smith user. 00:31:56.833-->00:32:03.792 And he is not able to read that LAPS password down there at the bottom. But if you run this find 00:32:03.792-->00:32:09.875 Admin Password Rights, you can see he's not listed. So we're showing that this user is not 00:32:09.875-->00:32:15.667 part of the server admins that pops up for this audit. Now, we're going to craft a very 00:32:15.667-->00:32:20.667 specific ACE that exploits the flaw within inheritance so when we add this ACE that particular 00:32:23.667-->00:32:29.250 John Smith principle will have the right to read the LAPS password forever whenever it's 00:32:29.250-->00:32:33.958 changed but the default auditing components release of LAPS will not find it. So this is a LAPS 00:32:33.958-->00:32:40.833 based backdoor. And here you see it actually executed. So John Smith, he's not in the server 00:32:40.833-->00:32:44.875 admins but he's able to read the LAPS backdoor despite not actually showing up in the 00:32:44.875-->00:32:49.875 default auditing on any cmdlets so cool. We think these issues will be fixed pretty soon. It 00:32:49.875-->00:32:55.750 was just we we dove pretty deep into some of the LAPS information. And again a ton 00:32:55.750-->00:33:00.708 more in the white paper. >> Okay so. >> This is my favorite. >> It's mine too, I'm a little bit 00:33:00.708-->00:33:06.875 biased though. Uh so, we mentioned how a third party applications can extend back to 00:33:06.875-->00:33:11.250 directory schema, they can add security groups, they can add control from groups to other 00:33:11.250-->00:33:17.583 principles in active directory. By far the biggest offender in this, is Microsoft Exchange. So 00:33:17.583-->00:33:23.750 with Microsoft Exchange server twenty sixteen, twenty thirteen, and two dozen seven SP one and 00:33:23.750-->00:33:27.792 forward, exchange server will create a group called Exchange Trusted Sub-System and add all 00:33:27.792-->00:33:33.708 of the exchange servers into that group. Then it will grant that group full control over 00:33:33.708-->00:33:40.000 every other object in the domain with the exception of accounts that whose DACL is protected by 00:33:40.000-->00:33:47.083 the admin SD Holder Object. Before 2007 SP one, this also included full control over 00:33:47.083-->00:33:51.375 everything. So essentially an exchanged server had the same privilege that a domain 00:33:51.375-->00:33:55.375 controller did. >> So if you're ever on a Pen Test or Red Teamers, if you ever end up 00:33:55.375-->00:34:00.583 popping an exchange box, you are probably one or two hops away from compromising the entire 00:34:00.583-->00:34:05.208 domain. >> There are several real environments that we've gone into to where what we have 00:34:05.208-->00:34:09.292 seen is reality is of the Exchange Trusted Sub-System does have full control of everything. 00:34:09.292-->00:34:14.417 The domain object, domain admins, domain controller, enterprise admins, you name it, 00:34:14.417-->00:34:20.875 Exchange owns it. So for this, we're we're gonna go through a couple of steps to implement our 00:34:20.875-->00:34:25.625 backdoor. First of all, we want to find an object that we can backdoor that's not going to be 00:34:25.625-->00:34:30.083 very obvious for an auditor to find. So we're gonna ride existing privilege by finding a 00:34:30.083-->00:34:34.833 group that already has admin rights against one exchange server uhh through group 00:34:34.833-->00:34:40.167 delegation. So not just one that is like, if you did Net Local Group Administrators and you 00:34:40.167-->00:34:43.792 found that group we're gonna go further back. Then we're gonna grant authenticated users full 00:34:43.792-->00:34:49.375 control over that security group. We're gonna change the group that we're backdooring to 00:34:49.375-->00:34:55.625 the exchange server and then deny read permissions on that group to the everyone principle. 00:34:55.625-->00:35:03.250 How do we execute this? We're gonna regain access to active directory as any user on any 00:35:03.250-->00:35:08.333 computer. We're gonna add our current user because they are an authenticated user to the domain 00:35:08.333-->00:35:12.708 they have full control over this security group like everybody else. We're gonna add ourselves 00:35:12.708-->00:35:18.000 to that group and then now with our new found local admin rights on an exchange server, we're 00:35:18.000-->00:35:22.625 gonna use PS Exec, thanks Mark Russinovich, to execute mimikatz as the system user on that 00:35:22.625-->00:35:29.625 computer. When you execute as a system user on a computer you have the same privileges that 00:35:29.625-->00:35:35.333 the computer object in active directory has. So a lot times this means DC Sync. So we're 00:35:35.333-->00:35:41.250 gonna go into Bloodhound and we're gonna find the group that we're gonna backdoor. So we'll 00:35:41.250-->00:35:45.917 go to Domain Admins and we'll look at uh what other principles have control over the domain 00:35:45.917-->00:35:50.292 admins group. We can see that the Exchange Trusted Sub-System has full control over the domain 00:35:50.292-->00:35:56.958 admins group. And there are several computers that are added to the security group. We're 00:35:56.958-->00:36:02.375 gonna select one of those, we're gonna select Exchange zero zero one. And we're gonna see who the 00:36:02.375-->00:36:07.875 existing admins are on that box. Through Bloodhound we can automatically unrule out who all 00:36:07.875-->00:36:11.875 the affective admins of a system are by group delegation. And we can see there are there are 00:36:11.875-->00:36:15.958 seven users that have local admin admin rights on this system. There's a system on the 00:36:15.958-->00:36:22.000 right, that group is explicitly an admin. That group has a group there and in this intermediary 00:36:22.000-->00:36:27.625 group also has a group called Server Back Up Tier Two. This group even though it would never 00:36:27.625-->00:36:32.000 show up in the local admins group on that system is a local admin. So we're gonna backdoor 00:36:32.000-->00:36:37.750 that group. First we're gonna import PowerView, then we're gonna get the raw directory 00:36:37.750-->00:36:43.083 entry for the object. So server backup to tier two, the group. We're gonna grant authenticated 00:36:43.083-->00:36:51.125 users full control over that security group. That's done. Then we're gonna change the 00:36:51.125-->00:37:01.000 owner of the group to an exchange server. Just for anti-audit reasons. That's done. 00:37:01.000-->00:37:07.875 Then we're gonna deny read permissions on that group to the everyone principles. You can't 00:37:07.875-->00:37:16.750 easily audit this backdoor. And that's done. The backdoor is in. How do we execute this? We 00:37:16.750-->00:37:21.125 regain access to the environment as any user. Domain User, you're not an admin anywhere. Again, 00:37:21.125-->00:37:26.583 we're gonna import PowerView. And then we're going to add ourselves to that security 00:37:26.583-->00:37:32.333 group, Server Back-Up Tier Two. Which is now done. Then we're gonna use PS Exec to remotely 00:37:32.333-->00:37:39.958 run mimkatz as a system user on that exchange server. Then we're gonna DC Sync the curve TGT 00:37:39.958-->00:37:44.875 user. Which which we can then use a created golden ticket. And we effectively then own the 00:37:44.875-->00:37:57.083 domain. And it's done. [Applause] >> Cool. Exciting. Love, love those curve bashes. 00:37:57.083-->00:38:03.167 So this last one we don't have a video for but it's also the most complicated. But again, it's 00:38:03.167-->00:38:08.417 specked out and even more detail in the white paper. So the entire backdoor consists of an 00:38:08.417-->00:38:15.333 attacker grants him or herself generic all to any user object with the attacker's to trustee. 00:38:15.333-->00:38:21.542 And then you kind of grant that patsy or proxy user the right DACL privilege to the default to 00:38:21.542-->00:38:26.500 main controller's GPO. That's the entire backdoor. And this is kind of a separate approach that 00:38:26.500-->00:38:31.042 we talked about in the paper of using alright a proxy or patsy type user instead of the actual 00:38:31.042-->00:38:35.917 attacker principle. So to execute it, get codex in the system again, you force reset 00:38:35.917-->00:38:42.042 the proxy's user password. You use that authentication context to add a DACL to that default to 00:38:42.042-->00:38:48.583 main controller's GPO. That grants oh that uh you're adding a DACL to the GPO that allows 00:38:48.583-->00:38:54.708 right access to that GPC file sys path. So we are granting ourselves the right to edit the 00:38:54.708-->00:39:02.750 GPO itself. Then we're going to grant through modifying the GPO the SE enabled delegation 00:39:02.750-->00:39:06.792 privilege. This is going to be pushed down to the domain controllers and what this does 00:39:06.792-->00:39:12.125 is it allows us to modify the MSDS allowed to delegate to for super protected property on user 00:39:12.125-->00:39:17.125 accounts. And the reason it is protected is if you're able to modify that, you can 00:39:17.125-->00:39:22.958 re-compromise the entire domain at will by executing essentially a constrained delegation attack 00:39:22.958-->00:39:27.333 through using mimkatz and kikio. This is pretty complicated, I have some stuff in my blog in 00:39:27.333-->00:39:33.292 the uh earlier in January that goes in this in more detail. But cool stuff. Pretty subtle though 00:39:33.292-->00:39:38.250 right. It's just one user that's not the actual attacker. Then you have generic all on that. 00:39:38.250-->00:39:42.917 Use that user as a proxy to add the rights you want. So what we can do in the future, is 00:39:42.917-->00:39:47.458 actually do really kind of crazy chains of this going all the way back. So not only if they find 00:39:47.458-->00:39:51.375 the backdoor, but they have to walk back every possibility of someone that might have had 00:39:51.375-->00:39:55.708 access or could gain access to that object. So you could this is again, kind of an anti- 00:39:55.708-->00:40:03.917 instance response measure. Alright, so defenses, all is not lost. We promise. The problem 00:40:03.917-->00:40:10.708 with these backdoors is you have to have event log auditing turned on at the moment the 00:40:10.708-->00:40:15.042 misconfiguration is introduced. So if this was introduced ten years ago and you didn't have 00:40:15.042-->00:40:20.583 this stuff tuned up or you don't have ten years of event log data which I don't think many people 00:40:20.583-->00:40:25.250 have, then you're not gonna figure out who actually put this stuff in. Assuming you can find 00:40:25.250-->00:40:28.792 it and assuming you believe it's actually malicious. This is why we think this this is actually a 00:40:28.792-->00:40:35.250 pretty persistent strategy. But for example, if you want to stop these from being put in in the 00:40:35.250-->00:40:39.875 future, there's different event log ID's like, four seven three eighty's account want changed 00:40:39.875-->00:40:44.833 and you can filter these by the particular property modified. And you don't have to mon uh 00:40:44.833-->00:40:49.792 monitor for every single possible change, you just need to start monitoring PeaceMeal by 00:40:49.792-->00:40:55.375 all these kind of object takeover primitives that we talked about. And I'm also gonna 00:40:55.375-->00:40:58.625 be putting out a blog in hopefully the next few months that gives complete defensive 00:40:58.625-->00:41:04.958 guidance for every single ACL based uh takeover primitive that we've covered. >> [Inaudible] >> 00:41:04.958-->00:41:10.042 Okay. So Replication Metadata. Metadata remnants from domain controller or or are actually 00:41:10.042-->00:41:12.958 preserved in these particular properties in Active Directory. So in the DC you synchronize 00:41:12.958-->00:41:17.125 everything. There's this XML based metadata that you can pull out. So you can figure out when 00:41:17.125-->00:41:23.458 a given attribute was modified and from what domain controller the modification originated 00:41:23.458-->00:41:28.000 from. So this kind of points you in the right direction, but you have to go to that DC and parse 00:41:28.000-->00:41:32.542 those event logs to actually figure out who actually made the change. As and I have a draft 00:41:32.542-->00:41:36.083 post that I'm gonna drop that goes into the replication metadata for hunting in a lot 00:41:36.083-->00:41:42.208 more detail. Also SACLs so, those System Access Control Lists that specify the types of 00:41:42.208-->00:41:46.792 access attempts that generate audit records in the security event log of the domain 00:41:46.792-->00:41:50.792 controller. SACLs have been around for forever. People don't use them because if you turn 00:41:50.792-->00:41:54.333 them on they're gonna be there's gonna be tons and tons and tons of events. But we really think 00:41:54.333-->00:41:58.583 that if you implement SACLs again just for the object takeover primitives that we 00:41:58.583-->00:42:02.292 talked about, you can cut down a couple orders of magnitude in the amount of noise and actually 00:42:02.292-->00:42:06.292 just you know really pay attention to the good stuff. There's a bit-ly link that has 00:42:06.292-->00:42:10.375 some more information on there. Future Work, we uh we worked really heavily with Lee 00:42:10.375-->00:42:16.042 Christensen tifkin on this stuff. And we tried really hard to set a null DACL for our 00:42:16.042-->00:42:21.500 otherwise manipulate the uh header control bits like SE DACL Present. See the idea being you 00:42:21.500-->00:42:26.375 know like you can do on host, setting a normal DACL so at anyone in you know any anybody 00:42:26.375-->00:42:31.833 authenticated users can have access. But any attempts to set the NT security descriptor 00:42:31.833-->00:42:35.375 remotely on an object were ignored. But this warrants another look, we weren't able to 00:42:35.375-->00:42:40.500 get it working, the documentation said why but there might be a way to do it. We also 00:42:40.500-->00:42:43.500 want to research additional control relationships. Particular those takeover 00:42:43.500-->00:42:50.042 primitives for computers as well as uh SACL type auditing. So credits. We wanna, special 00:42:50.042-->00:42:54.167 thanks to all the people that helped us with the slide deck and research. Definitely uh Lee 00:42:54.167-->00:42:58.875 Christensen tifkin, uh he really really helped us. Uh Jeff Dimmick for content review. 00:42:58.875-->00:43:02.833 Everyone else at SpecterOps and also Matt Graeber who used to work with us gave us some really 00:43:02.833-->00:43:07.500 good feedback and some really, I don't know he, really really good feedback and kind of 00:43:07.500-->00:43:11.625 content review. So with that, we're pretty much done. We can have a few questions and if we 00:43:11.625-->00:43:20.875 run out of time for that we'll be outside. [Applause] [Laughter] >> Awkward white guy. 00:43:20.875-->00:00:00.000 [Applause]