 All right. We're going to start off with Sean. He's got a little special message he's got to do. Here he is, Sean. Morning, DEF CON. How are we doing? So happy to be back at DEF CON. I got a friend here. This is Bunny. My daughter asked me to bring Bunny. So can everyone say hi, Bunny? Hi. Awesome. Thank you. All right. So Bunny is going to sit over here and get a front seat. So this is Exploiting Active Directory Administrator and Securities. I'm Sean Metcalf. I'm really excited about this slide deck because one of the things that I've talked about before are problems with Active Directory, the way it's configured, the way that people manage it, configurations within it. But rarely have I gotten to talk about the problems with how it's administered and the challenges with the systems that are often connected that are secure. So I'm Sean Metcalf, founder of Trimark. We help companies better secure their Microsoft platform, which is part of the reason why I do all this fun Active Directory security stuff. I'm a Microsoft certified master in Active Directory. There's about 100 in the world, most of whom work at Microsoft. I don't. So I can talk about whatever I want. I'm very happy to be back on stage at DEF CON. I'm a security consultant and researcher and I run 80secure.org. Show of hands. Have you used 80secure.org? Okay. Everyone is not raising their hand. Talk to one of the people that raised their hand and ask them what they think about it. So we're going to talk about the evolution of admin discovery. How do we find admins in the environment? The challenges with that and some of the issues with correctly discovering admins around Active Directory. How to exploit typical administration, at least how I often see AD administered. Challenges and problems with multi-factor. Password vaults seem to be more popular. So we're going to talk about bypassing and subverting password vaults. And then the vaulted admin forest, aka the red forest. And then I'm going to talk about how you can actually attack read-only domain controllers to compromise AD, which would be fun. So the evolution of admin discovery, we look for domain admins. We love domain admins, right? That's great. So we run a command like this. Get net group member. Thank you, Will Harmjoy, for giving us power view. So we can do this easily and quickly. And enumerate the members of domain admins. But a lot of times, pentesters and red teamers and security folks forget about administrators. So if we're just looking at domain admins, we're going to miss a ton of Active Directory administrators. How does this look? When most environments, we end up with, what, six domain admins? But once we enumerate the administrators group, we might have as many as 20 or more. And so if we don't pay attention to the administrators group, they have full AD admin rights, as well as full domain controller admin rights. So it's very important to make sure we're capturing both of those. And if we see something like this, what do you do? There are no domain admins. There doesn't need to be any domain admins in order to correctly manage and administer Active Directory. Domain admins really are not the AD admins. The administrators are. So the other way that we've talked about, or I've talked about discovering admins is by using an admin counting equals one, right? We look for any account in that domain that has admin count the attribute set to one. Active Directory is a process that goes through and enumerates the most privileged accounts groups in the domain and then flags them, put some additional security permissions on them, and flags it with admin counting equals one. The issue here is that if you're just looking for this, that's only in that single domain. So in a multi-domain forest, you're gonna miss all of the others. In multi-forest environments, you're gonna miss the others as well. And if we have a tool that isn't multi-domain or multi-forest capable, which by the way, this is Microsoft's PowerShell commandlet, it is not correctly multi-forest capable because when I add a group from another forest into the administrator's group in this domain, it breaks, at least in half of the environments I've seen. And when I run it against the administrator's group recursive, it doesn't give me everything. So definitely use the tool. Will's PowerView works really well for correctly enumerating the membership, but test your tool in a lab, test it to make sure that you're getting what you're supposed to be seeing. Otherwise, you might miss something. So there's also what I call hidden admins. Many people forget about group policy. The default domain controllers group policy or policy, GPO, contains something called user rights assignments. These are the user rights assignments that you would find on workstations and servers who can log on locally, who can do certain things on the system, but the ones that are configured for domain controllers actually has domain rights also, very privileged rights. And this is often missed. This is what I call hidden gold. If you're a pentester or red teamer, which is my target audience today, and you're not looking at group policy settings that are applied to domain controllers, please start doing that, because user rights assignments is going to help you find an even easier way in and be able to get you to meet your objective more quickly, a lot of times. Why is this? Well, it looks like this. I know you can't read that. It's okay. But this is the display. This is what you look at. So let's dig into a couple of these. Allow log on locally. It is what you think it is. This gives you the ability to log on locally. But when you apply this setting to a domain controller, guess what? You can log on locally to that domain controller. So if you can walk up to that domain controller and physically get on that keyboard, you can log on to that domain controller like it was a workstation. And you might have noticed something weird on this slide. That is not a typo. I have actually found this in customer sites. So anybody can log on to a domain controller. I don't know. Just in case the admin left early that Friday and they needed to reboot it or something. Who knows? But the thing about log on locally, it's not always local. There are remote ways to do local, right? When we have a VM, we can use the remote console to connect into that VM's console and log on locally over the network. There's also this little thing called ILO, which has been around for many years. Physical servers, physical domain controllers have ILO. It gives you the ability to out of band off another network, connect into that server as if you could RDP into it or connect to it and get that console access. And the recommendation is to often have that ILO connection be on a separate network and out of band network, a backup network, not on the production network. But guess what everyone does? They put it on the production network. Guess what can happen? HP ILO vulnerability from last year, about a year ago. Some very clever researchers fuzzed, reverse engineered the ILO configuration and what you can do with it. And they discovered that you want to see the POC? Yeah? Okay, here it is. You run Curl, you send 29 As and you completely bypass authentication. So this vulnerability is brought to you by the letter A. So this is not mine. They did a great job on it. I was chatting with one of the members of the team over at Manila a couple days ago and he was talking about some really cool stuff that they figured off of this because ILO is connected into the hardware. So not only can you bypass the ILO auth and just get local console access over ILO but there's some other interesting things they'll be talking about. He told me a little bit about it but I'll let him talk about that later. So that's one way that you can do it. So you definitely want to check this out, especially when you have physical DCs. DCs usually don't have VM in the name, just a hint. But there is a way through the Microsoft settings in user rights assignments to have the ability to log on over RDP to a domain controller. If there's allow log on locally and the ability to log on to terminal services, well guess what, server tier three can do this. Only domain admins, only administrators should ever be able to log on to the domain controllers via RDP but a lot of times we find this with our customers. And who's a member of server tier three? Well, it's Eddie. And that's just a regular user account. So whoever can control Eddie's account or manage Eddie's account or compromise Eddie, I don't know, then they can get on to the domain controller. And if you can log on interactively on a domain controller, you can do a lot of fun stuff from there. The other interesting thing is manage auditing and security log. You're on an engagement. Definitely check this out. You'll typically see exchange that's configured this way but this gives you the rights to actually clear the event log. I'm not advocating, depending on your scope to clear event logs on DCs but certainly bring it up to your customer and say, hey, by the way, this group, lab admins can clear your event logs on your DCs. You probably don't want that and we compromised one of the members of this group and we could have cleared the event logs on all your domain controllers with this. Trusted for delegation. This is a really interesting thing. Will Harmjoy did a great blog article about this. I talked about the dangers of unconstrained Kerberos delegation. Kerberos delegation is impersonation. So when you configure a computer or an account with the ability to delegate to impersonate a user, that means they can impersonate that user for Kerberos services on the network. This right that's configured in user rights assignments for domain controllers these accounts actually set up and configure and set the delegation, Kerberos delegation on those accounts and those computer accounts. Now they do need one extra right for it to actually follow up and finish but most of the time these groups will have those rights. They'll have full control over those accounts because they have controls on those OUs. So it's dangerous and a lot of times if you enumerate the Kerberos delegation in the environment to see what accounts have Kerberos delegation configured if there's more than like 30 or 40 you definitely want to check this out because there's probably a big group that has this ability that aren't the administrators. And then as we have environments that are getting better some of you have probably seen some environments that have gotten stronger they set up better restrictions they have more controls over their admin environment things that have been around forever that people have forgotten about are logon hours. So you can restrict when someone logon to Active Directory and what they can do in that time frame. You can also configure what workstations or computers are actually allowed to logon interactively too. So most of the tools that I've looked at that are used in pentests and red teams don't look for this. So if you find an account you're like I pop this account but I can't do anything with it why? Check this out. You want to check these two attributes logon hours and logon restrict workstation. The other thing you want to check are honeypot accounts in the environment that will look like they're great they're honey tokens in the environment they're a member of the right groups but you can't do anything with them. Check these attributes. It's probably why they're locked down why you can't do anything with them. So when we talk about administration where it's been, where it's going who remembers VNC? Just applause. Yeah right. Some environments still have VNC right and VNC by default is not secured RDP. We had run as people would use MMC on their computer in order to perform administration so we moved forward from that but in the beginning there were admins everywhere user accounts for domain admins every local administrator account was the same probably same now in some places please change that but some environments have as many domain admins as users which is bad so like as many admins as ostriches in this picture because I like ostriches there were a lot of opportunities any account you found had some sort of admin rights which is probably not too much different in some of the environments you walk into and the methods that were used then were bad log on to a workstation as an admin credentials and LSAS run as credentials and LSAS even the RDP so this is the thing that people forget they stopped doing the things on their local workstation they then RDP into a server like an admin server and then don't track how that admin server is protected so maybe cats obviously newer admin security methods so no more run as no more MMC on a local system should be great right we're going to use RDP we're going to connect to another system I'm not going to log in with my admin credentials on this workstation because someone could use bloodhound and know that I'm on this system and they could potentially get access to that and then compromise my account so I'm going to use RDP and maybe I'll use MFA maybe I'll use something like duo I'm on the news for something I don't remember but I pick on duo duo's good but there's some interesting things that happen when you use a regular workstation to do administration and as a pentester red teamer you want to be aware of some of those interesting things that happen some people are using password vaults we're going to talk about those so we have the typical administrator logs on to their workstation as a regular user then they open up the RDP window and they connect to their server their domain controller their main admin but something interesting happens in the background when this occurs there's a new file that shows up on the C drive a temp file that's kind of weird okay but windows drops temp files everywhere because it's a crazy OS like that so who cares well we the problem is that in this situation there's actually a WMI implant that's been dropped on the system so there's a WMI implant that is looking for the process mstsc.exe and when that executes it's going to run this script that I'm very helpfully named SCCM health check which is probably benign it's for the good of the system let's make the windows great again yes and so what actually happens is this is that SCCM health check PowerShell script and it actually has a function called get keystrokes well that's a little weird what is that so let's look at that file well we open up that file it's a text file and it's a keylogger so as soon as someone opens up that RDP window it's keylogging whatever is typed in on that keyboard and logging it to a file and it keeps doing that for a preset amount of time 20 minutes 30 minutes whatever we set and then we can use PowerShell to go through and parse that and actually extract the information that would be useful for us so while the admin thinks they're secure because they're not using their admin credentials on that workstation they're typing them in on the keyboard so we use MFA that'll solve the problem we're going to MFA the RDP so we got our RDP MFA problem solved so let's look at that we use RDP we MFA it we click on the button send me a push I get the little pop up on my phone I go yeah that looks fine approve but a second later I get a second one I approve this one it's probably a hiccup right sure it's okay do I tell anyone about it do I deny the first one do I approve like what's the situation how do I make that decision or with ADFS same thing I get two of these or maybe I'm the admin I log in in the morning and I log in to three different systems and I get these prompts in a row and I don't keep track I'm like yeah yeah yeah I gotta get my coffee what happens when I get this pop up which says log on request and there's no not that additional detail like the IP address location the time the date here I just it just says log on request okay yeah approve oh wait approve approve I'm pretty sure I only logged in twice I'm sure it was just like the phone it's been acting up recently it's probably okay so if we can set up a situation where there's a race condition between the admin clicking the push and the attacker clicking the push we might be able to have a situation where the admin MFA is for us and we've we've seen this before with other things like scams and different situations where they get an email they get a text message they're like oh by the way if you see this just send that code to me it's it's okay please do that but there's actually a way that you can serve vert MFA in certain environments based on what I've seen and so it has to do with a certain type of configuration which is fairly common this is the self service portal this is the configuration where users are able to update their own attributes and there's very benign attributes like their work phone number their mobile number or specific attributes maybe sometimes the title department whatever looks like this so we have a user has their mobile number set that way their boss can call them or they can be called when when they're on call but the problem is that if the attacker knows that they can change this and then they do to their number eight six seven five three oh nine nine that works well so they change it to theirs what they can actually do is instead of clicking the push button within duo or the MFA product they can force a text message to be sent to their phone this number that they just updated because in some environments where they have this this attribute the admin user has the attribute their mobile phone number associated with their account and that's associated with their admin account for MFA so if we can modify that phone number we can say give me a text message and the admin gets nothing no notification nothing at all and we can bypass it MFA configuration there's other MFA's that have this as a backup duo has it as a backup method that I've seen in many environments there's a quick summary for the people who are looking at slides later about how this actually works there's another interesting thing about duo is that duo fails open so for duo to work it connects to an API A record duosecurity.com and that's configured with that company and that instance of duo within that company and what happens is when you connect to it and you have that prompt it's got a check obviously to figure out how to push to you how to know that you can access it who you are etc what if we block that if we block that communication we can interfere or influence that connection guess what happens there's no MFA at all thanks to newbie for this he did a blog post earlier this month there's another thing that's interesting here if we change this default if we have access to the registry we can actually turn off MFA for local accounts so if we compromise the local account on the server we can connect to that using user and password all day long without any MFA when we're going through the RDP connection the other interesting thing about MFA is there's an onboarding process what is this onboarding process well a lot of times you go to a website you click on something you click a request and you get an email hmm that's interesting the email comes in they click on the link to approve it and the MFA gets set up for whatever they put in that form alright but if we've compromised that account that admin account we have influence over that email so we can set up a rule to filter it out or we can just delete it so they never see it so we could potentially add additional devices for MFA or even switch it over entirely because what happens when they lose their phone they're at DEF CON they're hanging out at a party and they're like I don't know where my phone is they've got to get MFA set up again a lot of times text SMS is the backup to that okay I have a new phone I got an email this person saying I had to get a temporary phone because I lost mine here's the number can you just update the MFA the executive Mr Kawasaki says I need this right now so I got to do this okay fine so there's some recommendations around this put the slide up you can look at them later but yes MFA is good but there are situations and conditions where MFA could be subverted or bypassed depending on how it's configured you want to let your customers know about this you want to let them know oh you have MFA that's great that's going to make my life a little harder but let me take a look at what that actually is doing and we want customers to better try what are the potential bypass methods because they know it better than we do we talk to customers all the time we're like let's talk about your MFA and how that works in this setup and what if this happens oh yeah we know that this could be an issue okay well I'm going to write that in my report thank you here you go but what's interesting about this is attackers don't need to bother with MFA at all because nowadays MFA is typically something that's added to RDP so if we can pull and extract we just can use that to DC sync we don't have to bother with RDP at all and that way we can pull any credential we want from Active Directory so customers are going to think well our admins have to use MFA to do things because they RDP in make sure they understand that the attackers are not bound by the same rules and there's something about password vaults so I'm seeing password vaults more and more I'm probably sure you are as well it's typically cyber arc or a secret server and often times there's a reconciliation account which is a domain admin account which is used to ensure that certain accounts that the password vault is managing, staying compliance, have the correct current password so if someone has changed the password for that account outside of that vault then it goes through and sets it back to what it should be but that means that this password vault is running under the context of domain admins or AD administration so if we can compromise and take over the password vault we would have access to that account and password vaults more and more are managing these AD admin accounts and have something called a session manager which is often used password vaults are being pushed more and more into being part of the administrative workflow so let's look at one of these workflows scenario the admin logs onto the workstation as the user they connect to the password vault via HTTPS using their web browser they then check out the password copy it out of the web browser into their clipboard they paste it into RDP the RDP window and then connect to their admin server and they have a great day I'm sure you see a problem here there's a password on that workstation in the clipboard but we can use another PowerSpoiler function called get clipboard contents so we can do kind of the same thing as before malware has been doing this for years where they're monitoring the title windows in web browser so if they see certain bank names they can log on the screenshot the key log can also do keyboard clipboard scraping and then from that they have the information that's going into that web browser so we can gather that the same thing sort of happens we have a second temp file here that has text file that has passwords I made up these passwords these are not from a password vault but the key is that we can also on top of this do get time screenshot because if we just have the password we're like I'm not really sure what that's for or what server they're connecting to but we can combine these two we can say alright it was this account at this time on this server and here's the password and correlate that so we want to make sure that organizations and companies know that just because they're using a password vault they are not secured just because they have dropped it into the environment second option so we use the password vault as an RDP proxy so the admin connects to the password vault via HTTPS or some sort of RDP pass through connection or RDP direct connection and they use the web browser just like before and then the password vault then does the RDP connection to the server on the user's behalf and the user never actually sees that account or credential which is interesting because everything is handled by the password vault but there's a few issues with this approach first of all who's logging on to the workstation it's usually the admin user so it's a user account and then what account is used to connect to that password vault again an admin user who has ability to or I'm sorry that connectivity and connection and logon is that using MFA sometimes it is sometimes it's not and then of course who has control of that password vault system and then ultimately can just anybody on the network connect to that password vault over HTTPS or any other connection what else is running on that system so I started thinking about this I'm like there's a lot of dependencies on this web browser right so what if we just compromise the web browser we don't have to do anything else what if we installed I don't know an extension and what if we didn't put it in the toolbar and what if all it did was it looked for the connection to the password vault system and when that happened it just set up a secondary connection to another system that we own and that way we could interact with the password vault in a separate hidden web tab so as the admin is doing what they're doing we can go through and copy out credentials for admin accounts but then the other problem is a lot of times the administrators of the password vault are regular users I find this too often so you just look for a secret server or a cyberarc and then you look for groups with those names and you're probably going to find something like cyberarc admins with a space or without or some other things that are in there these are user accounts we just have to compromise this user and then I can potentially own the cyberarc system that sounds bad to me and sometimes there's password vaults in the internet against the recommendations of the vendors people are putting their password vaults on the internet so depending on your scoping you definitely want to do some showdown to see what other things pop up in their range and sometimes they're using a really old version of that password vault and it's on the internet I don't know what credentials they're storing but they shouldn't be on the internet so here's a summary of what I've talked about again making sure that what accounts are accessing the password vault that their admin accounts are they're protected with MFA making sure that the system is administrated correctly because as a pentester red teamer we want to make sure that we're testing out all of these defenses and password vaults oftentimes are not protected at the same level as say a domain controller I can tell you right now that they're not very rarely do I see an organization protecting their password vault and putting a lot of extra time and energy into it a lot of times they just stand it up and then the vulnerability or the problem with that could result in complete and total active directory compromise so while I'm talking about vulnerabilities there happened to be one a few months ago for CyberArc this was an RCE so that's what about as bad as it can get right and this happened to have to do with serialize.net object to the authorization HTTP header they realized this pentest team realized that they could modify the information that was sent to the this API that's built in part of the web server and connect into it and what they could do is they could use YSO Serial in order to modify it and they could run ping on that system they could do something else on it so what about the admin forest or the red forest what do we do with that this is meant to be the most secure method of administering active directory and managing the system while it's a high security configuration it's isolated from the production network with firewalls and cryptic communication has a one way trust where the production forest trusts this admin forest and ideally correctly all of the admin groups and the production forest are emptied except for the one group that's in this admin forest well as attack emulators it's easy to discover this we just need to enumerate the trust look for an outbound trust for something that looks kind of weird like .priv or in addition to that we enumerate the administrators group is a group from this other domain and if we find that there's no other members of administrators this is very likely an admin forest which means that we're probably not going to find anyone that has really good privileges in this environment in this active directory forest as far as accounts go but the other thing to look at is for this account we notice that it's in foreign security principles that means that it's in a different forest so I'll tell you right away that that account group or security principle is not something that you can find in that forest you'd have to try to connect to the other one if you can't connect to the other one and do any kind of enumeration it's possible that it's an admin forest so what do we go after we look at agents we look at service counts one of my favorites in this situation is backups everyone overlooks backups it's the thing that we need so we're going to make it work we're going to make sure that it's configured we're going to make sure it has the rights it needs backup operators gives that backup service count and we have a backup computer account and backup operators which doesn't make sense to me but there's also a backup AD service count which is pretty interesting and sometimes these backup accounts are members of the administrators group for the domain because they do a lot of interesting things like per attribute recovery and so if we look at this backup server account at the top this computer account it's in the servers OU and a sub OU of that called backup likely in this environment first thing I think of is who manages the server OU and nine times out of ten is a group called server admins or something along those lines we can compromise one of those accounts we can compromise this computer and this service count which will enable us to jump up and potentially compromise the domain without ever touching the admin forest so if you run into an environment where you see it's locked down like this focus on the production AD forest because nine times out of ten they have not fixed the issues that were inherent in that production AD forest someone sold the CIO a lot of the times here's an admin forest we need this now there are some environments where an admin forest makes sense but that's outside the scope of this talk did you know this is interesting to me the Splunk universe of forwarder is often installed on the main controller it's effectively a mini version of Splunk and can run scripts it's fascinating so I was trying to look up some more information about this and I found that there was this talk at Splunk conference a couple years ago where someone's talking about how you could leverage the deployment server leverage Splunk to potentially run scripts run arbitrary commands so that means if Splunk is in the environment and it's installed on the main controllers depending on the configuration if we can compromise a Splunk account or an admin account we can potentially jump to our domain controllers so again this is a summary of the things that I just talked about identifying those systems and agents that connect to the domain controllers what agents, what services, what service accounts have ability to install and run code on domain controllers and that answer isn't always obvious but we can do a lot of that discovery from Active Directory because most of this is in the directory and the problem stems from cross forest administration a lot of organizations have multiple forests well not a ton but a bunch of them do and so they have their production forest forest A forest forest forest B because I'm really creative in my naming and there's a trust from forest B to forest A this untrusted lower level of trust forest forest B trusts all of the accounts in forest A to connect to it and connect to resources so what is how this is set up so the users in forest A connect in that means that we can have a domain admin in forest A actually administer and control and manage forest B the problem here is that forest B is a dev tested environment often times it's in a DMZ it's a dev test environment it's for some external configurations of external system but since the domain admin account in forest A is connecting in via RDP to that forest B environment the credentials are there so if forest B gets compromised or if you have that in scope and you can go after that forest to jump back to A you can compromise forest B the problem is a lot of organizations are going by Microsoft guidance Microsoft guidance from 10 years ago says this is okay they don't realize and they haven't updated the documentation a lot of times to our new world of how many cats works how credentials are stored and managed in most organizations and that the compromise of this could lead to the other so the recommendations you can give your customers to please just use a an external forest account to manage that forest or use an unprivileged account in our production forest to then manage that other forest this is not necessary so let's talk about read-only to make controllers read-only to make controllers are very interesting you probably won't see them in a lot of environments some of the larger ones you will there's a very specific circumstance where a read-only will actually be deployed often times at a branch office where it can't be trusted maybe it's just put next to the reception desk or in a closet they can't trust that it's going to be well protected some environments put them in our DMZs but the RODCs connect back into production that's not a good idea either so discovering read-only to make controllers is not that complicated we look for is read-only is true or there's another option to do it this one's a little easier we can just look for the primary group ID 521 or enumerate the membership of read-only to make controllers and that will give us a list of our read-only to make controllers so what's interesting about read-only is that oftentimes I find these three things set up maybe not all the time but I'd say half the time I find a configuration like this in an environment they cache more passwords that are actually required they're typically administered by RODC admins which may include user accounts and the passwords for the DSRM account which is the built-in administrator account for that single to main controller is often the same across all the DCs and the read-only to main controllers and that's text for later so there's four key attributes on read-only to main controllers that we want to enumerate one is the reveal-on-demand group which tells the RODC and the domain controllers what can actually be replicated what accounts, security principles can have their password data replicated to that RODC and then never reveal means that these can never be replicated the revealed list is a list of the accounts that have ever had their passwords copied to that read-only to main controller read-only to main controller is a domain controller it has an MTDS that did just like the writables and you can extract the information from it just like a writable the authenticated too is a little interesting because this tells you the accounts that have ever authenticated to the read-only and if the read-only doesn't have the password data for that user it's going to chain up that authentication request to a nearby writable but you still know which accounts are actually connecting to it so this is a replication policy those are the ones that are allowed on there allowed to have their passwords there or not so this allowed RODC password policy is defined at the domain level a lot of times that's how it's configured domain level all of these groups for all read-only domain controllers the denied RODC password replication group is very often default and then it's interesting because you can delegate writes to the read-only it's a regular server effectively so Microsoft's recommendation of mine is to manage read-onlys but they're full administrators on the RODC this is easy they can do it during install or interestingly enough we can use the manage by attribute to update who has admin rights to the server and so we can enumerate that manage by once we get that information about who the admins are we can then enumerate the membership and we see there's Ray and Poe here it's interesting because these have admin in the name but these are in the regular account so you can compromise one of these accounts once we do we're an admin on the read-only domain controller so then we start poking around and figuring out what we can find in this environment and we can use the GUI to see what the password caching is but I mean we can get all this information from the attribute itself or the attributes on the read-only but there's an interesting part of the GUI here and this is something that I haven't seen anyone write about before if you have admin rights in the act directory environment you can interact with and control read-only capability and one of the things that read-only can do that most people aren't aware of is that you can pre-populate passwords on a read-only so let's think of this from a persistence perspective let's say we have 80 admin rights for like 5 minutes what we can do is we can remove the CurbTT account from the denied replicate we can remove the administrator's group from the denied replicate and then we can click pre-populate and we can pre-populate and say these accounts I want you to put on this RDC like now potentially we can replicate the CurbTT account password hash to our read-only that we control and if we can stay on the read-only even if they take care of everything else we have no one's going to notice this so how do we figure out what password hashes are on a read-only well there's an attribute called MSDS revealed users it looks like this which looks very difficult to read let's make it simpler basically here's Han Solo he's logged in a bunch of times every time he logs in the read-only tries to authenticate him with the password that it has and if it can then it's good if it's not certain what's going on it will track each instance of that authentication so we can see that there is a password hash version and so the read-only will update the password that it has every time that user logs on if it needs to to make sure it has the current password for that user let's take a look at our show and break this down and identify all of the unique accounts that are on this read-only domain controller and one of them is pretty interesting because it's account provisioning well that sounds like an account that could have some rights so let's take a look at that so we look at it a little bit more closely and it has an SRV name or SVC name to it so we're going to use a PowerView function called invoke ACL scanner to look for anything in this domain that has permissions for this account to see what it can do and the first thing we find is that it has generic all rights to this group's OU well generic all in Active Directory lingo just means full control okay so we have password hash for the service count that is full control on the group's OU okay well what's in that group's OU it's the R to C admins which okay I don't really care about that but there's a server admins group at the bottom here the admins probably has rights to a bunch of things like maybe the password vault so we dig in a server admins and we find that there's a group policy that's actually adding this server admins group to the local administrators group on all of the computers in this OU so at this point just because we compromised one user that had R to C admin rights we were able to compromise all of the servers that are in the server OU but what else can we get off an R to C depending on the configuration and if you're thinking well R to C they don't cash passwords by default you're right they don't but pretty much 99% of the time in order to effectively use R to C you have to turn on password caching because it cannot authenticate users without their password data and computer accounts as well so in order for an R to C to authenticate a user they need that user's password hash and the computer password hash the user has authenticated from so R to Cs can be a goldmine because organizations ignore them a lot of the time so let's look at this again what else can we find in here that's really interesting there's a computer account that says admin in the name let's look at that what is that well we do some discovery we do some more digging in and we discover that this admin server or admin in the name is the admin server all of the admins use this server and the computer account password for the admin server ended up on this read only and so we just go ahead and dump the password hash for this account this computer account and then we can create a silver ticket create a couple of silver tickets and then we can do power shell remoting once we have those Kerberos tickets on our system just because we were able to compromise that R to C and get that password hash so once we get onto that we can start dumping credentials from LSAS because all of our admins are going to be logging out on that admin server and then there's one other thing that's pretty interesting is I mentioned the DSRM account and I talked about this before the DSRM account is that built-in default admin account on domain controllers when a domain admin is standing up a new domain controller they type in the credential or a password for this DSRM account and this account is a break glass account in case you need to get on the domain controller into DSRM mode directory services restore mode in order to use this account and do anything with it but there's a registry key as of 2008 where you can log in with this not on by default but you can configure this registry key as of 2008 where you can log on to the domain controller without restarting it into the special mode you can log on from the console depending on the registry key if it's set to 1 you can log on when the active directory services are stopped if it's set to 2 you can log on anytime you want if it's set to 2 you can actually pass the hash using this password hash on the network and there are environments that have that configured so it is entirely possible that you can compromise the environment from just taking over a single RODC so some key recommendations here for you to give to your customers and for red teamers and pen testers make sure that you're actively looking for the 80 admins you can find see what you can discover correlate these user to admin accounts because if you're using net session enumeration or group membership to see where users are or what computer they're logged on to you might not be seeing the full picture and there's a lot more that could be there look at MFA look at password vaults see how they're configured poke the edges around them and then look at the RODCs thank you so much for yours I think I have some time for questions