Hello. This is Dan Conrad from One Identity by Quest. And today I'm going to give you a quick walk through of-- I'm going to call it a point and click Active Directory breach. I'm going to use some command line tools, but then the tools that I actually used to breach are going to be point and click. I've seen a lot of videos online and demos of different breaches and most of them are using power show commandlets and command lines, and I'm just going to simply do the breach from the command line and then I'm going to use the point and click tools.
The test lab that I'm going to be using I call it the perfect storm of vulnerabilities because it's a legacy operating system. The user has local admin rights on the box. And in this case, we're going to assume the attacker already has remote access to that box, whether it's through a phishing campaign or something like that. And the attacker, in this case, has actually installed Mimikatz on the box to be able to use that. So I'm going to go ahead and jump over into my lab environment and start the exploit here.
So here's my test lab environment. I'm going to go ahead launch a command prompt as an administrator here. So I'm logged on as G-I-N-A-B-A-I. That's the username I'm using right now. So, just to kind of show you who this user is, has no actual permissions and active directory. So if I wanted to do something like create a user account, I simply don't have the rights to do that. If I want to do something like enable a user account I can't do that, because I don't have any rights in Active Directory. So let me get that out of the way. So when the command prompt I'm going to launch over too Mimikatz. So let me just change over to that directory. It's in the x 64 part of the Mimikatz directory and then I'm going to launch Mimikatz.
So now I'm in the Mimikatz command prompt and I'm going to clear the screen. So first thing we're going to do is elevate our privilege. So that works successfully, then we're going to dump all the local hashes. So we're going to use the sekurlsa command. So here's all the passwords in the local cache. So let's go through and start at the top and figure out which ones we want to use. I know specifically which ones I'm going to use. It's not that many on here, but we'll go grab them and take a look at what we have. OK. So we're looking for specific users and their log on domains. This is a server name. This is another service here. There's Gina's user name and her ntlm hash, so let's go ahead and grab her hash just to keep it interesting here. We go over here and mark that down. So that's the user name, there's the hash that goes with it. Let's go find another one.
So here's a user account da1. And here's the ntlm hash that goes with that one. Let's go find one more here that I'm looking for. Here's another one, da2. And the ntlm hash that goes with that. So now we have some hashes. If you take a quick look at the hashes, you see Gina's hash right here starts with 64f and ends in 49b. You'll notice that the da2 hash starts with 64sf and ends in 49b, which means they have the same password. Since I set the lab up I know what their passwords are so that's just an interesting thing to look at. So let's clear the screen now and let's go ahead and use a pass the hash technique. So we're going to use a sekurlsa command, and then we're going to do pth, past the hash. We're going to pick the user. We'll start at the bottom, da2. Then we'll pick the domain name, which is 1q2w.tech, fully qualified. And then you have to choose the ntlm hash here. Going to make sure we have this one still on the clipboard. Paste it in right here.
So what this is going to do is open a command prompt for me. It's misspelled, sekurlsa, so let me go back and correct that. User, domain, ntlm hash. So now it's launched a command prompt for me, and I'll get this out of the way and get this out of the way. So now I have a command prompt running as that hash, at a privileged user hash. So I can see what I want to do. In this case, I'm just simply going to launch the Active Directory uses computers, which is dsa.msc command. So I can go through and launch that. So now I have Active Directory Users and Computers running as that privileged hash. So I can do things now like I can go through and create myself a user account. I am a j hacker. Put a password in. Then I can go through and modify that user to do whatever I needed to do, so let me put it in a privileged group.
So now that'd count as a member of the domain admins group. Another thing I can do that's very useful is to launch group policy editor. So this is my group policy management console. And in this case, I can deploy a GPO called ransomware if I wanted to. I can go through and edit a policy, software settings, software installation, and deploy a software package right here. And that could be literally anything that I want to do. And since this is linked at the top level of the domain, then that's literally going to be installed on every server and workstation in the domain. So let's take a pause right here and go back and figure out why that worked.
So why did the breach against the da2 account work? Well, obviously the da2 account had previously logged into that server and therefore cached am ntlm hash. That cache would be released when that server was rebooted. The account was enabled in an AD, so obviously it worked because if it hadn't been enabled I wouldn't be able to authenticate against AD and use that account to do anything, really. And then, of course, it is a member of the Domain Admins group or its privileges inactive directory are what we call persistent. So they're not on demand privileges set up as they need to go. Had it not had permissions in Active Directory or had it been disabled, none of these things would have actually worked for that account.
So let's jump over and take a look at another account. We'll take a look at the da1 account real quick and see how that's different from what happened with da2. OK, back in the lab. Let's take a look at the other account, first let's clear the screen. So we're going to pass the hash against another account. So we'll take the da1 account in this case. I'll go ahead and grab that hash. So we're going to do sekurlsa, pth, user colon da1 slash domain colon. And then ntlm. And paste that hash in. Same thing, we're going to go to command prompt. So now I have a command prompt running as that privileged user. So let's go ahead and run dsa.msc and try to do the same things. So it doesn't work, I can't enumerate the domain. So here I can't really see anything, I can't change to the domain, I can enumerate because I don't have any permissions and you get access denied. I tried gpmc.msc, same thing. Access denied because I can't enumerate the domain.
This is the difference between one that works and one that doesn't. So real quick, I'm going to jump back over to my slides and we'll talk about why it did not work in this case. So the breach against the da1 account failed for a lot of reasons, really. The account itself had been a domain admin and it had previously logged on to the server, but after the admin was done using a da1 account, the password was check back into the PAM solution which was Safeguard in this case, and the password was changed. What happens when you change that password is the hash is completely irrelevant at that point. It's just a mess of numbers that don't relate to anything. Additionally, the account was disabled. So a breach against a disabled account adds a lot of complexity, it's very difficult to do. And this account is no longer a member of a privileged group because active roles running in the background had removed the group membership because safeguard told it to do that.
So even if the account had been successfully breached, hadn't been enabled, and a lot of other things had lined up, it's not a member of any privileged group so it wouldn't have permissions to do anything beyond just look at the domain. At that point you could enumerate the domain, but it wouldn't be a lot of value. I'm going to jump over into change auditor real quick, for change auditor for Active Directory and show you what it has been seeing the whole time here. So here's my change auditor interface, and this is right off the bat that the events that have happened in the last five minutes. So we can see right here this da1 account is attempting to authenticate through ntlm, and it's not working, it's not working. So it tries repeatedly to authenticate, and that doesn't work. I also have a couple searches set up here for the things that have happened with the da2 account and the da1 account. So there's everything that da2 did, so the group policy being created and that sort of thing.
When I created the user account, here can tell me the da2 did it. Obviously I was logged on as Gina Bye. But I emulated the da2 account. The da1 account has really done nothing other than try to authenticate. And it's not able to do that because the account itself is disabled, its group membership is stripped, and really can't do anything. So within change auditor I have the capability to do what's called a protection template. So when I turn on the full functionality of change auditor, this would really prevent a lot of the things that the da2 account was allowed to do. Like add members to groups and things like that. So especially the critical enterprise group that you see right here. Where I'm a hacker was added to the built in administrator's, or the domain admins group, and things like that. So that is a protection profile as part of the change auditor auditing suite.
I'm going to talk real quick about the solutions that I have in place that are affecting the protected account versus the unprotected account. I have active role, safeguard, and change auditor for Active Directory working for me. So active roles is in there to set up the permissions model for Active Directory and proxy all changes to Active Directory. So I can actually remove most of the permissions from AD and I wouldn't really need a domain admin account to do most of the work that I'm going to do anyway. And then it works with safeguard to dynamically populate group membership only when required and approved. So if I would need the da2 account or the da1 account, I would check that account out from safeguard. Active roles would see that that happened and it would populate the appropriate group membership, and that would be just for the time that I have it checked out. Then when I'm done using it, I can check it back in and it'll change the password, which cycles the hash and disables the account and removes the group membership. Rendering any residual hash is left in the environment like we just saw completely useless.
And then safeguards in there to cycle passwords and spoil ntlm hashes. And it's going to disable accounts when not in use, further making them even less useful than they would be before. Change auditor for Active Directory is in here, and it's doing exactly what it says is does. Change auditor for Active Directory audits changes to Active Directory. So I can set up alerts on things like privilege group membership changes. I can also set up protection profiles for change auditor for Active Directory. So when you saw the account I went in and created a user account and then added that the domain admins group, change auditor can block that. Active roles has ways to create dynamic groups as well, so that anytime somebody modifies one of these dynamic groups active roles will immediately revert those changes. Change auditor, however, will completely block it and it'll look like a permissions error. So thanks for your time. That was a quick point and click breach of Active Directory. I'm Dan Conrad from One Identity.
14:17