Just-in-time provisioning of Active Directory

Hello. This is Dan Conrad from One Identity. And welcome to Virtual Unite 2020. Really glad you're joining us for this session today. Today, I'm going to talk to you about a point-and-click Active Directory breach. And some simple steps that you can take to protect against that. We've seen-- if you're into cybersecurity at all, you look at different ways to do breaches, and different ways things are attacked, and different ways that attackers will try to grab the intellectual property or whatever it is they're after on your environment. And we've seen some deep-dive command-line stuff. But today, I'm going to show you about as simple as it can possibly be of what an Active Directory breach looks like. And then I'm going to walk you through some of the One Identity tools that protect against that. A little bit about my lab here. So this is a test lab. This is not an instructional video on how to do this. This is a simple sample of what it could look like in your environment. This lab, I call it the perfect storm of vulnerabilities. So it's running, first off, a legacy operating system. So it's an old operating system that doesn't have a lot of the modern protections built into that. The user has local admin rights. So this could be a workstation. This could be a server. But the person using the workstation actually has local admin rights to the box. And then in this case, we're going to assume that the attacker already has remote access. That could have been through a phishing attempt or something like that that actually gave the attacker a way to install things on that box. In this case, the attacker has installed a little program called Mimikatz. Maybe you've heard of it, maybe not. If not, I'm going to walk you through what that looks like. So real quick, let's jump over. And we're going to take a look at taking a breach into our lab environment. So I'm logged on to a server in my environment here as my user. So I'm going to emulate what an attacker would do in this environment. So first off, I want to see who I am right now. So I'm logged on as this user, ginabai. So let's go over to the Mimikatz directory. And then it's the tools we want are in x64 directory. And then I'm going to launch the Mimikatz command line. So now I'm in Mimikatz. So let's clear the screen. First thing you want to do in Mimikatz is get a cup of coffee. So, oops, c-o-f-f-e-e. So there's your cup of coffee. And Mimikatz doesn't do anything. It's just interesting. So first thing we're going to do is raise our privilege level. So we're going to type-- set it to the debug level. So that worked. So now we're going to run a command called sekurlsa. And we're going to do a switch on that call logonpasswords. This is going to reach into memory and pick up all the locally cached logon passwords on that machine. So as the screen is scrolling by, it looks a little bit scary. It's really not that bad. So I'm going to open up Notepad so I can capture some of these. Let's go back to the top and start looking at what we want here. So I can see a username right here, SGTempDomAdmin1. Let's copy that, put it over in Notepad because I'm going to use that later. So that looks like an account that I'm going to be able to use. Paste that in over here. I know the domain name. Then I'm going to go down, and you can see right here this is my NTLM hash. So let me capture this NTLM hash right here. And this is what's going to give me access to the rest of the environment. Guess I'll paste this in over here. Let's go grab a couple more. So same one, same one. Some of these are server names that are authenticating. Don't need to worry about those. I'm going to look for more users. Here's ginabai. So that's my-- let me go ahead, and I'll use hers as well. So that's the username. And here's the NTLM hash right there on this user. I'm going to grab this just in case I need to use it later. Typically, an attacker is going to grab every hash possible and try them all. But this lab, this environment, I set it up, so I know what I'm looking for. But you would typically grab all of these. Are servers authenticating. So here's an account called da2. So let's grab this one as well. So here's the NTLM hash right here. And we'll paste this in right here. All right, so now we've got some hashes that we can use. If I was going to keep going, i would grab more and more of these. An interesting tidbit on the hashes here-- you'll notice that ginabai starts with "64f" and ends in "949b." The account da2 starts with "64f," and that ends in "949b." That means they have the same password. So now we're going to go try to use those hashes. OK, so now we're going to run the sekurlsa command again. And we're going to do colon colon pth the Pass The Hash. We're going to choose the username, da2. We're going to choose the domain name, fully qualified. Then I'm going to pass the credential, which is the NTLM hash right here. We go capture that, take this space out right here. So this is going to launch a command prompt for me so that I can actually run that as the da2 account simply by passing the NTLM credential right here. So now I have a command prompt. So you could do a lot of things from a command prompt right here. But I have a point-and-click kind of AD administrator. So I can do a couple of different things right here. So I can go run dsa.msc. If you're not an Active Directory administrator, you probably don't realize that this is the command for launching Active Directory Users and Computers. Now, this is the primary tool that the day-to-day admin would use. And I can go through and do anything I want to do with this. So I can go into my Enterprise. I'll go into this Test OU, and I'll go create myself a user account. And I'll call it Ima J. Hacker. If you don't catch that in your environment, if you probably have a problem. Put a password in. So now I've created myself a user account. Then I need to give that user account privileges. I can do just about anything I want to do in this environment, like put it in a privileged group, such as the Domain Admins. Populate that for me. So now I've got a way back into the environment [INAUDIBLE] with an extremely privileged account. Another great thing you can do with this-- well, "great" depends on your opinion. But you can launch a Group Policy management console. So Group Policy controls the way all of your machines operate in your entire architecture, so everything joined at Active Directory. And I could come down to something like the default domain policy right here, and I can edit that. So when I edit that, I'm probably going to do something like go into my Policies and Software Settings and probably deploy software. This is a ransomware technique. So I could say a new package right here. And I could deploy something like RansomMe-1.0.1 right here and push that out to my entire architecture. Now what will happen is that will push out to every machine in my environment because it's the default domain policy. And it's linked to every machine in the environment. Therefore, when those machines, at least when they reboot, they're going to install this package, and I'm going to own the entire architecture through ransomware. So let's take a minute here. Let me exit out of this command. And we'll go back into the slides for a second and talk about why that worked. So why did that work? So why were we able to successfully compromise Active Directory using the da2 account? Well, the account had logged on to the server previously. So in that case, an attacker might do something to the system that requires somebody with elevated privileges to log on. And if they don't reboot the system to clear that NTLM hash on the way out, then the credentials are going to be stored [INAUDIBLE] The account itself was enabled in Active Directory. So it was a highly privileged account in Active Directory. And it was also enabled. So, I mean, obviously, accounts need to be able to be used. But in this case, it was an account that was most likely something shared or something that different admins would use at different times, but it was enabled. And then that account itself had persistent privileges of a highly privileged group. And in this case, it was Domain Admins. But it could have been any other privilege group or any privilege group that was nested in any other privilege group. So the permissions that are assigned to this account were static and did not change over time. So that's kind of something to consider in this case. Now I'm going to come back to the other account that I grabbed here besides the ginabai account. And I'm going to take this SGTempDomAdmin's account and see what we can do with that. So I'm back in the lab again, same info, same environment. And let me go ahead and exit this Mimikatz right here. And we'll come back in the same way. And we're going to clear screen, and we're going to elevate our privilege again. The only thing I don't need right now is to recapture the hashes because I already have them over here on Notepad. So I'm going to come after this account right here. And we'll do a pass-the-hash on this again. So it's a sekurlsa command again, pth. And we're going to /user:SGTempDomAdmin1 /domain, and we're going to pass the NTLM credential again. So I have the same thing. I have a command prompt again. So let's minimize these and get them out of the way. I'm in the same situation I was before. I'm running as SGTempDomAdmin1. So let's do the same thing we did before. Let's go over to dsa.msc. And in this case, I'll go do something to that same account if possible. Well, how about this? So first off, I get an error, says the naming information cannot be loaded. Well, why is that? Well, I can't authenticate with this account. The login attempt failed. So I'm not able to authenticate with that. Well, OK. That's going to be a problem for an attacker. So I get an Active Directory blank console with nothing in it. I can't do anything with it. So let's go over and try the Group Policy management console again. Going to get basically the same type of information with a little bit of a different error. It's telling me that I can't connect. So this is going to be kind of a dead end for me. Whether I'm running command-line exploits, or whether I'm running the point-and-click exploit like I showed you just now, it's not going to work for me. So I'll go ahead and kill this. So let's step back over to the slides and talk about why that didn't work. So the TempDomAdmin account had logged in previously. As you can tell, it logged in previously because I had the hash there. If I had never logged in, or if the server had been rebooted or something like that, it wouldn't have worked for me because that credential would have been cleared. So the password that the-- the account itself was disabled. When I tried to use it, it wasn't able to authenticate. On top of that, the password that I used to-- or the password for the account that generates the hash was changed every time I used that account. So if I'm an admin, and I launch a session out to that, I log on to that with a temporary password, simply by checking that back into safeguarding the password changing, well, it does what I call "spoil that hash." So the hash is still there, but it's not of any value to anybody. On top of that, the account is enrolled in our just-in-time provisioning. So the privileges of that account don't have any-- it doesn't actually have any group membership in Active Directory beyond something called Domain Users. So all of that group membership has been removed. If the password was enabled, and the account was enabled, and I would have that, the account is still useless. So in this case, we've basically broken that chain three different ways so that the account can't be used. Here's the solutions I have in place to mitigate that. First off, I've got Active Roles. so Active Roles is proxying my permissions for me into Active Directory. So the account I'm using doesn't need to have permissions in AD. So I'm working with Safeguard through Active Roles to populate that group membership dynamically as it's checked out. And Safeguard itself does what Safeguard does. It changes passwords when they're used. So you check out a password or you check out a session, and you use it, Safeguard changes the password on that account in Active Directory so that it's not available, and the hash is of no value. On top of that, the account is disabled. In the background, I've got Change Auditor for Active Directory from the Quest portfolio working as well. So it's watching changes. But at the same time, I'm using an object protection feature of Active Roles to lock the group membership of those privileged groups so that it can't be changed dynamically or adjusted so that someone could use it. If they try to do that, it's simply going to block that attribute. Here's what the just-in-time provisioning looks like. So your admins are going to connect to the Safeguard appliance and check out a credential. At that time, it's going to reach into Active Directory and enable the account and populate the group membership dynamically for me. When I'm done with that, it's going to undo that and roll it back the other way. So let me jump back into the lab and show you what that would look like in about a 2-minute session here. So I'm in the lab here. So let's take a look at that SGTempDomAdmin1 account. And I keep them all in an OU right here just for demonstration purposes. So this is the account we're going to use. You can see right here it's disabled by the big red X. And on top of that, it has no group membership other than the default Domain Users. So if I would need a session or a password on that account, I would simply come to Safeguard and request that. And I can check it out right here. It's a member of the 1q2W domain. I'm going to go and select that account for check-out, SGTempDomAdmin1. And then this could go off for workflow approval. In this case, I have it set up for instant approval. Now it says, "Pending account restored," and now available. So if I come over here and refresh, the account is now enabled. And the group membership is populated. I've populated SGTempDomAdmins group, which is a member of the Domain Admins group. So I nest it in there. I didn't directly control the Domain Admins group that way. So then when I'm done using the account, and you can go get the password if you want to go get a password. And sorry if this matches anyone else's password. But this is the password to the account right here, and go use it, do whatever I want to do with it. When I'm done using it, I simply check it back in, and the process is reversed. So that's going to reach into Active Directory and disable the account. And then it's going to strip the group membership so the account, should it be compromised, is completely useless. So this is the just-in-time provisioning I was talking about. So what it's going to do-- it's going to assign privileges as the accounts are checked out in a dynamic way. It's using functions from both Safeguard and Active Roles to do that. In Safeguard, it's simply listening to the Safe-- the service is listening to Safeguard so that the account is available for checkout. And in Active Roles, it's populating a virtual attribute that uses the dynamic group capability of Active Roles. And then accounts in AD that are required to perform a function-- you can check those out, and they're added to the groups when necessary. This isn't dependent on the naming convention or anything that I have. It can be built into anything that you need for your architecture, whether it's a personally linked admin account or something like I have here that is a pool of accounts. And our goal there is to reduce the attack surface. So these accounts, whether you can enumerate them as members of the Domain Admins group or other pieces like that, it's really not going to make much difference if you know that an account was previously in a privileged group. It's not now, and you can really reduce the numbers of user objects or accounts in these privileged groups. And something like this is really designed to mitigate this pass-the-hash-type attacks. We get conversations around Golden Ticket exploits and other ways to get involved and mitigate Golden Ticket exploits. But a Golden Ticket is something that is more of a persistence thing that is a stem from a pass-the-hash or another type of privilege elevation breach. So having those under control up front really helps you in this type of scenario. The solutions I'm talking about here from the just-in-time provisioning is available free on GitHub. And I realize this is a long link. So don't think you've got to write this down and run off and go get it. Feel free to reach out to me at either in my daniel.conrad@oneidentity.com or, after this session, there's going to be a time for questions and answers. And I do have a three-minute demo up on our YouTube channel, as well as a full install video of the just-in-time provisioning, again, to help with these Active Directory security scenarios. Really, thanks for your time today. I appreciate you joining us virtually. And I hope to engage with you right after the event.