Ben Goodman & Eric Kuehn - Hidden Threats In Your Active Directory Adventure

Uh we're here to talk about active directory and we wanted to put this in a way that hit more people than just your admins even though probably most of you are admins or or red teamers. So we decided to tie this to something we both care a lot about which is actually Dungeons and Dragons. Uh I've been a DM for a long time. Uh been a player even longer. But myself I'm Eric Keane. I'm one of the principal security consultants at Secure Ideas. I've been there eight years, but before that I was responsible for active directory at very large enterprise environments. Uh used to support one of the biggest in the world. We thought it

was the biggest. The military beat us out, but hey, it's all right. Uh been doing it for before AD was actually released. And like I said, I like playing role playing games. My kids are older. We get to play D and D together now. It's great. Ben. >> So, I'm Ben. Um I've been at Secure Ideas for since August. Um, I've got about 10 years experience in offensive security consulting. Did a lot of network admining and things like that before that. Um, a lot of you folks know me from back in my Sword and Shield days. Um, I am also kind of like super hyper nerd. Uh, play a lot of D and D. um don't I don't DM as much as Eric

does, but um I do like, you know, the power gaming and I have an obscene miniatures collection and I will never finish painting them and um get off my back. So, to start, I said that this is we're tying it to D and D. So, we're using this like an adventure. We're here together. We're having a session, a campaign. If you have any questions, because D&D is cooperative, ask them at any time. Please don't wait till the end. All right, we want to go through this. So, we're starting out in our adventure. We have our nice party here. We have the cleric, we have the fighter, all the good stuff. And like any good adventuring group, you start in a

dungeon somewhere, right? And the first thing that you look for whenever you're playing is these secret passages. How does this relate to Active Directory? Well, it's permissions. All right. ad active directory itself, believe it or not, can be secure. It's unfortunate that we as administrators have made it insecure. And part of that is because Microsoft told us to. I'm not saying that everybody said it's perfect, right? But Microsoft says you don't want your domain admins doing things. I think we all agree you don't want your domain admins doing everything with their DA creds. We see it still to this day, but they don't want you to do that. So they say, delegate these rights out. give

other people permissions, which is fine. You should do that. But we start seeing this thing where permissions, people with more permissions are on like less secure devices. People are doing admin from workstations, all sorts of bad things. And so we want to look at this. How hard is it for us to find those identities and move around, right? Have you given generic all, you know, user Sally in marketing has the ability to make changes to all these groups for some unknown reason. she can do whatever she wants or maybe write I can just write any attribute I can uh let's see maybe I don't have the ability to write it but for some reason I can change the

security on it we've seen that time and time again where for some unknown reason people have been granted ownership or the ability to just say I can change security so we become them change that little bit of security and suddenly now we can write anywhere some of my favorites though are a little bit further further down. Kind of hard to see because there's a table in the way, but there's these things called replicating directory changes. All anybody familiar with this permission, you see it on the MSOL account, right? When you set up and you're syncing to Azure. It basically says that I get to act like a domain controller. Don't care who I am, but I can pull anything I want

out of Active Directory anytime I want, like I'm a DC, including all the password hashes. So, just a small thing. There's some limitations that we can have saying filtered set doesn't make a difference still has the ability to do stuff. We have seen recently Ben and I have seen where domain users so anybody in the environment has the ability to do things like oh modify a GPO at the root of the domain. A go let you put policies down on Windows devices. So suddenly at the root of the domain I could say you know what my account is an administrator everywhere. It's done. Uh some other good ones I've seen domain users have replicate directory changes all for some

unknown reason. It is amazing what we do. But there's another permission out there that people often forget about and I consider this pass wall. Anybody know what pass is from D&D? It literally does what it says. It's a spell that says I know there's a wall here but I'm going to create an opening. It's the same thing here. Adding our own computer as a user by default. anybody in your forest, so not just your domain, but any domain or a domain you trust, any number of things, have the ability to add a computer to the domain. You might be thinking, why is this bad? Well, I like to say that pentesting ad is great from

Linux. You can do a lot of stuff from Linux. It's better if you can do it from Windows. And if I can be part of the domain, I'm trusted, right? I get a step up above everybody else. Easy to do it. Two ways to stop it from happening. It's because of this policy in default domain controllers. It says authenticated users down there. Anybody can do this. You can also change the machine quota if you want and say zero. I've seen some people do that. Either way, it works. You get to exploit this in other ways later, which we're going to talk about during the demo. Some options that you have. Yeah, you'll you'll start to see that like even even

if your regular domain user is locked down tight, if they have the ability to create a computer object, frequently those computer objects have a lot more permissions on the domain. >> Yep. And by default, where this computer is placed is in a special location in the domain called the default computers container. It's right under the root, which means the only policies that get applied to it are at the top of your domain. And since you want your policies to kind of follow that lowest common denominator methodology up there, you typically get things like here's your auditing. Hey, here's some other light stuff that you want to affect everybody. So even if your endpoint protection on

your devices is incredible, you're using CrowdStrike and you're logging everything and we're sending PowerShell auditing everywhere. We are doing everything we possibly can. That workstation will not let you do anything. We add our own. It doesn't make a difference because we're not going to get those settings, right? Quick win to get some sort of leverage in the domain. So, pass wall, secret doors, big problem. >> Secret tunnel. >> Secret tunnel. I'm not going to sing it for you. Nobody wants to hear that. So, next up, your DM is a mean person. You've made your way. You found that secret passage. You found the secret treasure chest. and you open it and there is this beautiful

amulet. You know it's magical because it's the only thing in the room that isn't rusted, corroded, dead, etc. You pick it up, you might look at it and say, "What does it do? Cast some magic on it to see if it can tell you what it does, but it looks great. You know it's powerful." You put it on and then suddenly you realize your GM is mean and you've been cursed, right? You can't do something now. Well, we have this problem in AD as well. And it's all because of NLM. Everybody goes, "Uh, NLM, we all know this, right?" Believe it or not, NLM is so old that what is considered the new protocol, Kerros, is really 26 years old

now. So, NLM is like 30 something plus years. It is really, really old. Kerros is your default. But unfortunately, most people don't know how to set up Kerros for applications in your environment. It takes a little bit of work. Developers don't know how to do it. They just expect it to work. They don't give you good documentation and if they do, it doesn't work. And then you just do whatever. And really what happens is your apps are dropping to NLM for free behind the scenes. You just don't know it. So NLM is a challenge protocol. All right? So it works like this. We have our user. They've logged in already. Okay? They've already doing whatever in the background. They decide

to go to that application or file server. So they make the connection behind the scenes that app server whatever responds back with a challenge. It's some random numbers. Okay. The device is very nice and behind the scenes takes that number set of numbers encrypts it with a password hash of the user and sends it back to the application. Then the application says all right hey Mr. Domain controller here's my the person who's trying to authenticate. Here's their username. here's the challenge I sent them and here's their response. The DC because it knows everybody's password hash says great let me do the exact same encryption and if it matches it goes great let you in. Does anybody see a problem with this

dynamic? Everything occurs over here right? Yep. Responds with hey you have access. Everything is happening over here and we like to insert ourselves in that pretend to be something else. So we get your password hash. To make it worse, there's a whole bunch of other problems. NLMv2, the newest version which was released in NT4 SP2, I think, maybe three, I don't know. I forget the NTS service packs a long, long time ago, is the default. That means that at least I'm doing a little bit of extra checks. there's some randomness that's been assigned to this methodology, but by default there's nothing enforcing it. So even though you expect NLMV2 that has some better protections to be there, all

we do is say, you know what, let's drop us to NLM v1. And now we have a much easier hash to deal with. We can crack it much faster. We can do all other things, right? uh like drop the mic. >> Yeah. So uh Intel MV1 with it being as old as it is, you can effectively so whenever whenever signing is enabled, you have this thing that's called message integrity code. That's basically like that is where the sign the signing verifies like hey you're you are who you're supposed to be. Net Intelm one will just let you drop that. And so even if you have signing enabled, it will bypass it because it it like for some

reason by default Microsoft is like, "Oh, you don't have your integrity code. Cool. You can go in like um and from there it allows you to do, you know, all manners of things over usually frequently it's through an SMB relay to LDAP. Um, you can do things like delegate access to another machine, do a DC sync, you can get a shadow credentials. Um, trying to think of some other things off the top of my head. Um, >> the relay itself is beautiful, right? It's a two for one. >> So, right here you have this wonderful thing. We said, here's my evil malicious attackers device. We're sitting in between behind the scenes because Windows is trying to be helpful.

That's its main purpose. Let me be helpful. When you try and connect to server one, what's happening is behind the scenes, your device is actually saying, "I'm looking for something called S." Now, I'm looking for SE, SE, SV until it matches it so it can fill in that nice share list for people. Okay? We create the poisoners right sitting there in the middle. And what happens is as you're broadcasting, your devices broadcasting, we sit there and saying, "That's me. That's me. That's me. Yep, definitely me. And we can send it on to our actual target where that domain admin is logged in. At least they're not on their workstation, right? But they're on a server and we hit it. And you were

going to say something. Yeah. Well, I was just going to just add on to your point like sitting on the wire and listening for that that traffic, you know, that's that's all well and good. And if you've you've got users authenticating on your VLAN that that have that kind of access, that's great. But you can also kind of force that authentication if you have access to an account that can perform those actions. You can coersse one of those machines to do that for you through there's at least three different ones, but the ones one that comes to the top of my head is like with Patipotam, you can just have that machine do actions for

you. And so you don't necessarily have to wait for someone to authenticate over the wire. >> No, absolutely not. And I mean honestly the poisoners just help us. A relay itself is a passive thing. It's just sitting there waiting, waiting, waiting, right? And when something comes along and connects to our device, we forward it on and we just pretend and and sit in the middle and send all the challenges back and forth. So relay is passive. Poisoners let us get more people trying to connect to us. So even if you have turned off LLMR or all of the fun things that Windows is supposed to be doing in the background, if you do something else

that you're supposed to do because we security people say you should, like oh vulnerability scanning on your network or a knack solution, that's my favorite, comes along and hits my bad device and your Knack solution is probably running as a domain admin because you want it to be able to test your servers and your workstations, right? It comes along, it hits my poise, it hits my device, I relay it to the target server, and now I'm an admin on that server. I've not only moved, I have escalated my privileges. It's a two for one. My favorite story with this is an act solution. All right, we're sitting there, we're working away, the network is pretty strong, and then we noticed,

oh, I got booted off the network. Even though we're doing spoofing, right? Oh, I I pretended to be that MAC address. We got booted off the network. Like, all right, interesting. Let me set up my po. Let me set up my relay here to that server. The knack solution came by again, dropped me off the network. It's okay. The relay triggered. I connected yet again as a different MAC address and my reverse shell, my shell was sitting on that remote server. It didn't make a difference. They kicked me off because I just connected again. Relays are incredible. signing that Ben talked about, SMB signing, LDAP signing are great and will protect you unless we drop you to NLMB1 like Ben said. Now, it

doesn't make a difference. We're still in the door. And this is especially dangerous when your domain controller supports Intel MV1 because what can every user do? Authenticate to the domain controller. And so even if you have just the lowest of privileged users, they will still have this ability to just instant instant DA. >> Yep. And we we we talked about it like offline cracking your NTLMv2 hash on my cracking server which is now four years old and running 1080s I think something like that. Four of them will hit an NLMv2 password in 20 hours. That's how long it's going to take me. And that's if you're like at the end. Most likely though, you started with a letter

capitalized, right? So, we can cut that down. We can do a couple more things. I'm probably going to get it about 10 hours. If we're talking Entil invo V1, we're probably looking at 10 hours, maybe. If we drop you to LAN, man, we own your network anyways. Uh, it's going to be even faster. Okay. And the reason this works is the default setting for everything in the domain is when a client requests this. When he makes this initial connection from the workstation to me, it's going to be I want to use NTLMv2. And the servers are going to say, okay, great. Let's do it. But I'm more than willing to accept a lower authentication method. I'm willing to do V1, not LAN,

man. We we really have to do some work to get you down there, but at least NLM v1. So, what can you do? You could remove NLM from your network. And if you do this, I want you to reach out to me because you'll be one of like three organizations in the world that have done it. Okay? It would be incredible. And I want to use you as a case study. And it's because it's hard, right? As I said, everything wants to use Kerros, but nobody knows how to set it up, right? And so the only thing actually using Keraros is your default login hopefully. And when administrators connect to systems as soon as you talk

about an application you've installed, we're probably dropping to NLM1. All right. So let's just say that would be a great pipe dream. Once again, if you do it, please let me know. Okay. We got a question in the back.

Great question. So it was >> Yep. >> Great. Yes. So the question was in in incredibly hard environments like in a STIG environment, something that's using the the federal requirements, military requirements and stigs, will this work? Most likely not, believe it or not, because they do require it that you you've enforced NLM V2 at least, right? So, probably not. This will not work. However, >> thinking through >> uh No, I don't believe it. It does not say turn it off. It it's >> there are right. So, we could find potentially ways of of getting that hash. we wouldn't be able to relay it most likely in that environment unless they reduced it. What we will typically

see is one of two things in an environment. A part of it is incredibly hardened. Another part is not quite as hardened. And so we start over here and we can just pivot into that other one. Um the other things we'll see is they are enforcing those requirements on the servers themselves, not necessarily through a go or some policy. And then we can make changes to registries. We can do some things. But if you are enforcing them the right way, poisoners, things like a relay should not work. Um, dropping you to NTLV1 should not work. All right. But we can still get your hash, right? If you connect to us, we can still get your hash and we can still

try and crack it offline. Do things like that. And more to that point, if if we were to able to identify a machine that's not enforcing SMB signing, you can't do a lot of the crazy LDAP shenanigans that you can do with that Intelv1, but you can still get code execution via the SMB relay because it will still authenticate um when there's no SMB signing. And so like we can still execute code or do things like that, but at the very minimum you can try to crack the hash. So the better way is in force sent v2 uh it's if you do the registry it's LM compatibility level five. You do this on all of your endpoints and then you turn

it on on the DC. That's the way you go through this. Actually I would do it on all the the client workstations then the servers then the domain controllers or you can set it via GPO. So next up, who knows what a mimic is? >> All right, I know who my D and D players are now. Awesome. >> Is anyone a mimic in here? Yeah. Oh, good question. >> Yeah. >> So, a mimic, if you're not familiar, is something that looks enticing, right, but is actually something waiting to eat you. Like our adventurers right here. This happens in Active Directory in a slightly different way. I talked about Kerros before the way you actually want to be

authenticating because it's all pointto-point. I like to think about Keraros as passports. Okay, they're tickets. So, you have your passport, you go to through customs, you go to the front, you give them your passport, they look at it, and they look at you, and then they say, "Okay, great. Have entry." They didn't actually go back to the US and say, "Hey, is this guy really here? Is this valid? I trusted where this passport came from, so I trust you." Kerros is the same way. So, down here behind Ben is my poor person who's already logged in. When you connect to a Kerros enabled app, what happens is for free behind the scenes, your workstation is sending your

identity, your passport, it's called a TGT, a special type of Kerros ticket to the domain controller. It verifies that that TGT is still good and some other checks. Are you allowed to log in still, etc., etc., etc. And if you are, it creates a service ticket. A service ticket is encrypted with the password hash of whatever is running the application. Okay? Could be a user account, could be a workstation, could be any number of things. That ticket is then sent for free to the application you're trying to access. And because it has its password, it can decrypt the ticket and look at it and say, "Okay, this is Eric. He wants to come access me. Great." If you've turned

on excessive kerros checking, which no one ever has, it actually reaches back out to the DC and says, "This is true." But really, it just trusts it like a passport. And if everything is good, it says yes, you can enter and whatever permissions you have. Keraros is all about validating your identity. Okay? But it's all pointto-oint, right? Because it's encrypted with that password, things like that. So I can't this application could not send this ticket somewhere else to access something which is a problem. There's this idea I learned about it called the kerros double hop but it's called ker kerros delegation. This is used for applications that are reaching out to a third source like oh a

database server and instead of using the service account for the application they actually want to become you to do it. Okay, I need to know your permissions so I can access this special set. So multi-tered and what happens is it allows that application to pretend to be you to impersonate you. It can do it in a couple of different ways. The really bad way is this unconstrained one. This is released with Windows 2000. It's really bad. It literally gets your identity when you log into it. It becomes you literally it is you. And so if we can get that application we are you um to do anything you could do least secure and then we

get some other ones here constrained which is better it can say I can pretend to be you to do specific things recently when I say recently we're now talking 13 years 2012 R2 2012 there's this new idea of resource-based constraint delegation because kerros is really important to active directory All of these upper ones require that you have domain admin privileges to turn it on on a system to allow it to occur. This is the reverse. They said, "Okay, that that's way too tough. People aren't doing this right. Let's try this." And re resource-based constraint delegation says if you have permissions like we showed at the beginning, write those secret doors to write to specific attributes on this object, you can now

delegate and pretend to be somebody to access you. Okay? So it's all about permissions. It's different the other way. So it acts in reverse. So you say here is a server and this user ID can impersonate other people to access you or this other server can pretend to be you. So we're going to talk about that last one. How can you become a mimic in the environment? Well, if permissions are set badly or we have the ability to coersse your domain controller and lower itself down to like that V1 NLM v1, we just create our new computer account out there, right? And because the DCs have permission to themselves, they have full control. So, we can modify that special attribute

down here called I don't even want to say it so long, but MSDS allowed to act on behalf of other identity. That's the attribute. It can add itself in there. And so then we just say when we are going to connect to that remote system, in this case we're going to say a DC, I'm going to pretend when I log in using this third-party application that can delegate me. I'm not Eric anymore. I'm gonna pick somebody in the environment, anybody in that domain, and say I'm actually them, and it will forward it on for us without a problem. And when we connect to that server where this delegation has been turned on, we are that person.

All right. So all it takes is having some special rights on that computer object in AD. Full control of course will work. The ability to write to any attribute will work. the ability to once again change security. If I can say I have read access but I can give myself right access I can do it or write account restrictions. I said we could coersse a DC once again drop it to Entin V1. Ben mentioned petite patam before but there are other wonderful tools in here that we could use to do the exact same thing. It doesn't make a difference. We just asked the DC to please give me its hash so we can do something.

You want to say >> Oh, no. I was going to say uh just a small caveat, something something I I'd forgotten about for the resourcebased constraint delegation for that in order for that to be exploitable, you have to have control of something with a service principle name attached to it. So a service account or we mentioned this earlier, a computer account. And so the ability to create that computer account suddenly you're able to do this on machines and you're not you're not a DA at that point because well as far as the machine is concerned you're a DA but you're not actually on like it's in the context of that machine itself. It's not the the entire domain if that makes

sense. >> Yep. Great point. So yes, when we connect whatever that delegation has been granted to, we can become anybody to affect that thing. That thing is very generic because it could be anything. It could be a computer, it could be a specific app. So thinking about our pentesting, quite often we'll see this delegation put in place for once again accessing a database. Okay? So being a domain admin and accessing a database may not do anything, but I can find out who your DBAs are who probably have database owner and gain their level of access to hit that database server where then I spawn XP command shell or something else and start pivoting around that way.

Right? You can become anybody. It's just a matter of knowing who you want to become at that specific time. >> Yeah. >> So now we get to see a demo here. Ben's going to show us how you do this. I'm going to switch you over. >> Dual screen this so I don't have to. >> Sure. >> I guess I can just use the cash because I was going to have

>> Sorry that one. Yeah, it'll just see my cheat sheet. Okay. So, in our lab example here, and make sure everybody can hear me, okay, we have a domain that's called elemental evil.com, >> a good call out back to if anybody plays D and D. >> We have a user um by the name of Morty Kanan who wants to do bad things. And so, I am lazy and going to use the cash on this uh Cali box. So, um I'm not sorry. Um so we are going to first demonstrate one on our domain controller DC1 um we are not going to have the proper permissions to delegate access. So um we have our uh same account name for our domain

controller DC1. We're going to read the ACL on it and then um this these are our credentials for our user. So you will see here that this really long attribute that I can't say without going blah blah blah um is empty. And so if we try to do anything on the domain controller right now as this user um nothing happens. you'll get access denied log on failure. Um, and so now we want to so we find out through whatever means uh blood hounds you're just messing around on the network whatever um you find out that Morty for some reason has write permissions on the domain controller object. We don't know why. And so knowing that we can create our own

machine, Morty has created his own machine called similacrim here. And so now we are going to write to this permission that similacrim can act as anyone else on the domain controller. And so we're just going to hit enter here. And so accounts allowed to act on behalf of other identity. We have similacrim. So now we're going to request a service ticket, but it's going to be a little bit different because we're not going to request that ticket as Morty. We're going to request it as our computer account Similac. And so you'll see here um

>> my right or your right? There you go. >> Just this work. >> Oh, okay. How's this? >> There we go. Thank Sorry about that. So, you'll see here we're requesting a ticket for the CIFS service. Um, which I'm not sure on the specific >> file sharing. >> File share. Okay. And then for our alternate service, we're going to request a ticket for LDAP, which will allow us to do a DC sync on the domain controller. Without that LDAP service ticket, you won't be able to do this. So now we get a bunch of errors about Python stuff and but we hit we have here we've got our service ticket. So now we're going to export that into

our Keraros cache here. So now anything that we do through Keraros is going to be done as our DA. And so now we're going to try this secret stump again when I get there. So now we have similar output here. We're going to authenticate as the DA right here. Um but we're authenticating over Kerros with no password because you don't need it. You got a Kerros ticket. And so we hit enter. And we get a weird error, but because you know, we didn't make a sacrifice to the demo gods. >> No, not enough chicken. >> But as you can see here, we've dumped all the hashes on the domain controller. And so now I can just be I can just grab

one of these Intelm hashes and be who I want to be. And so we've got a DA here by the name of El Morning Lord. I can just get his NLM hash here and just basically own the domain at that point. I can look for whatever I want um on the file shares um control other servers, burn it down, whatever. Yep. Because once again, Microsoft being helpful, we don't need to know your password if we can get this hash. This is the password hash and ad that you use what it uses to do all of the fun things behind the scene. Right? So in this case, we had right access to a domain controller, which may or may not

actually occur. But as we've said, if we can coersse your DC into talking back to us, we can have the DC be able to write to itself or another DC. Right? So it is a little contrived because hopefully no user has the ability to write to a domain controller attribute, but we could do this if we wanted to access once again that server. the domain admin is logged into, right? We just jump the gun, jump the shark all the way over to to domain controllers. But we can pivot. We find out where you're logged in using things like Blood Hound or other recon, other methods and see where you are and just become you there. All right.

So, how can we find these mimics? Uh, a whole bunch of things. Uh, and believe it or not, all of these are really bad to run on a domain. FYI, except for the first one. Uh, when you're looking in Active Directory to find things, you all want to use index attributes like a database. Most of these aren't indexed, which means if you have a large environment, it's actually going to be bad. It's going to cause some problems. Um, but so what I would do, what I typically do is I say, give me all the computers in your environment with these other attributes aside with it when you give me the output. and I get a nice

list. But if you're going to go quick and dirty, you can run each one of these indiv individually. So we're going to look for our resourcebased constraint delegation because most people aren't using this one. Almost everybody uses these up here. So this looks odd in most places and say let us find where people have the ability to impersonate others. But you can use any one of these to find where Kerros uh impersonation can occur. How do you prevent yourself from being eaten by the mimic? All right. Well, number one, know where keros delegation is. As I mentioned before, keros delegation is a valid thing to occur. It should be happening in your environment for specific apps. You just want to be

sure that it's locked down and you know where it is so you aren't logging into those devices with your admin administrative credentials, your domain admins, etc. So know where they are so you know how to handle them. To protect yourself, all of your really big administrative accounts like domain admins, server admins, etc. should either be marked as insensitive and cannot be delegated, but that's individually on each object. It's a special attribute in ADU that you can click on. Or you can use my favorite protected users group. Does anybody know what this group is? Is anybody using this group? I see a couple hands. If you are not using this group, your domain admins should be a member of this group.

Your server admins should be a member of this group as long as they don't log into apps. Okay, so we're talking actually logging into a Windows box to do things. This puts so many restrictions on what it can and cannot do. It will work for Windows stuff, no problem. It makes our lives really, really hard when we want to try and use the account, but it does things like it won't accept NLM authentication. It cannot have its tickets corros tickets uh impersonated. It can only have a certain lifetime on tickets. All sorts of things that are wonderful improvements. But because it cannot use NLM V2 or any NLM authentication, it can't log into other apps most likely.

All right. So have separate accounts, but put them in that group. It does what the second one here does, but a lot more. It's a lot better. So, in summary, we've gone through our small adventure. Our poor adventure has been beaten up by by the horrible GM, but they've survived. How can we do this? We need to know who has the ability to write to things in AD. Not only who has that ability, but where they're logging in. Okay, it should be done on special devices. That's getting better. But quite often we see once again people who have domain admin and server admins and maybe workstation admins and people with other rights all logging on to one jump box.

So that becomes the target and it's not as protected as your domain controller. Guaranteed it's not. So we just go there. So know who's logging in where best tools for that still Blood Hound is probably great if you're familiar with how to use it. Uh Avalanche is a close second. Uh, Pin Castle kind of does it, but not as good. It's more of an auditing tool. Um, I have some scripts that will give you at least OU level permissions, not individual objects. But know who has the ability to write and where enforce NLM v2. If you have not done this yet, please go through the process. Everything at this point should be using NLMv2 on their own. It shouldn't be a

problem. You might have some old stuff. Once again, force all of your clients. they're already trying to use NTLMD2 force all the clients to five then do your servers then do your domain controllers you should not see a big impact there and then lastly be aware of that kerros delegation it should be there in your environment domain controllers by the way need to be able to delegate right so you're going to see your domain controllers always come up as hey we can do unconstrained delegation don't turn that off you turn that off and your domain's going to stop working right so that's appropriate just know what other member servers are using that permission. All right. Anything you

want to add, Ben? >> Uh, just to add to the thing about the DCs. Um, with the enforcing Intel and V V2, you cannot turn off the delegation on a DC. And so supporting older versions of NLM, that's why that is so bad on a DC. It's just it it you anybody can delegate to it. So that's just um yeah, the nature of the beast, I guess. That that's why you should at minimum be enforcing intel MP2. Absolutely. >> On your DCs? >> Everywhere. But definitely on the DCs. >> Any other questions? Yes, sir. >> No, I love questions.

>> The Cali box, >> it could have lived anywhere, right? As long as we have line of sight to the domain controller, it could live anywhere. Um, preferably. Yeah. No, because we're saying this account has the ability to do it. So, >> yeah. As long as it has line of sight network-wise to a domain controller, we're good. >> Yeah. If if it's on if it's sitting on a Wi-Fi network that's not segregated from the domain, then yeah. Um, and you know, I used impact on Cali just as a kind of ease of use kind of thing. But um there's also the popular tool uh rubious that you can use uh on PowerShell through a Windows workstation. So you

can if you want to use like an assume breach you can also go from that perspective of hey I've got a thread actor on this workstation that can execute PowerShell. Um so I I debated using that but just for the purposes of the demo I didn't impact it. Okay. Blood Hound. >> Sorry. So the the first question that we answered was what type of network access do you need right where on the network do you need to be to make this work? And so anywhere really. The second question was >> discovery >> discover that we've abused it or discover that it's possible.

you you you'd Yes. To detect the actual you'd be looking for the behaviors of us trying to initiate computer uh creating a computer account, modifying permissions in AD, which nobody is really ever auditing, um or running commands in the background. Seeing the ticket be created would only be done by the domain controller and that's if you're auditing service tickets and if you are your domain controller is burning on fire because of how much is going on. All right, it's literally in flames in your data center. So seeing the actual us become somebody very very hard to see it unless you look for those commands. Any other questions? Uh yeah. So the um credential that you

had for uh Morgan Kanan um so you'd achieve that by cracking a a hash you got from responder or packet capture or >> yeah the yes >> those lines any >> dark web monitoring fishing uh we we asked you for it uh we asked your help desk to reset your password for us um any number of ways that we got a set of credentials. >> Okay. And so that particular uh portion of the attack does require a compromised account. >> It does because we said this user is going to make this change, right? So yes, it requires some form of credentials >> which could be achieved through poisoning relays other methods where we don't have credentials. Right? So yes,

it requires a valid identity in your forest or trusted domains or any number of places, right? A lot of people forget that as soon as you have an identity in an active directory forest, if you trust it, I have permissions everywhere. We see this wonderful thing where we have this lockdown domain and we have a root domain and then we have this other domain out here that we pretend that doesn't exist because some people are administrating it, right? Some other group. We start down here. We have access to everything again. We have read access at least potentially write access in other places. Um, you had a lot of great uh commands in there like all those get commands and

things. Is there a way that you could share that with the group or >> Oh, absolutely. So, uh, number one, email me or Ben. Uh, we we don't believe in in uh charging you by the second, minute, day, whatever. I love answering questions. Our true philosophy at Secure Ideas is we want to work ourselves out of a job. I would much prefer that my kids information was secure and safe than me doing what I do. I love being a pentester, but I can do something else, right? I hate that my kids data has been leaked like 14 times various ways already and they're just getting into college. Okay, so really bad. So, email me. I will send you the slide deck. I

will be happy to talk to you about AD. Ben will be more than happy to talk to you about any of this stuff. I always like to say when I'm on a pin test, sorry. I always like to say when I'm on a pin test, like when I run into this kind of stuff and things are locked down, I'm like, well, this is boring for me, but that's great for you guys. Like I sometimes I like saying that. Other times I'm like, uh, give me something to play with. But anyway, so was there another Yes, sir. >> offer third party services, I guess. >> Uh, internals to like an organization. >> No, no, no. We we are a security

consulting firm. Security has been around for 15 years. Uh we come talk to me afterwards. We'll be happy to set that up. Right. But yes, absolutely. Any other questions? Anything about AD, it doesn't even need to be what we talked about or pentesting. All right. If not, thank you very much for listening to us talk. Hopefully, you had a good adventure. We'll be around.