Now, when you want to dump Active Directory password hashes, there are two main techniques that are involved, and we're going to cover each one of those, and what the pros and cons of each technique is.
This is a little different world than just dumping your local account password hashes on a workstation. This is going to be the password hash for every single account in your Active Directory domain. If you get this, you'll basically have unlimited access to the entire network. Both of these require having some sort of presence on a actual domain controller.
The first method is the oldest method that we use, and that's what's called LSASS injection. This is where an attacker will inject his malicious code, in the case of something like Metasploit, this would be your meterpreter, into something called the LSASS process. LSASS is the Local Security Authentication Subsystem Service. And so, on a domain controller, this is the service that is running the process that is running on the domain controller, that all of the different machines on the network talk to for authentication. So when you log into your workstation on a domain, it sends a request to the domain controller that is processed by LSASS. And it takes the username and the password hash that you've send it, and it checks it against what it has stored in memory in LSASS, and says, "Yes, that's the right password hash," or "No, it's not." And that's how authentication happens in the Active Directory domain for the most cases.
So what we do for LSASS Injection, is we inject our code directly into the LSASS process. Before we do that, we have no real access to read what's in memory here. So we know there's things in memory and LSASS, but we don't know what they are. We inject our code directly into LSASS, and start reading the memory space, because we're now a part of that process, we have access to read all of that memory. We then search through all of the memory space, until we find those usernames and password hashes. We extract those out, and we send them back to our attacker box. Now, this sounds pretty straightforward, but there are a couple of things to be aware of.
One, it's not particularly fast, because you're going to have to search through a huge amount of memory space to do this.
And two, it's actually very risky. Because if anything goes wrong while you're inside the LSASS memory space, you're going to crash the LSASS process. Which means that that domain controller can no longer handle authentication requests until LSASS is either restarted, or the machine is rebooted. So anything that goes wrong inside that process while you're injected into it, can basically screw up the entire domain. And as a penetration tester, your client is probably not going to be happy with you.
So that brings us to a more modern technique. LSASS is constantly communicating with a database file on the filesystem called NTDS.dit. This is the database that all of Active Directory syncs its information to, about every five minutes, usually. Now, that means all of our usernames and password hashes are stored in this database. But it's open for reading and writing by the LSASS process, which means we can't access it, it's locked. So how do we get access to that NTDS.dit file?
Well, the answer is what's called the Volume Shadow Copy Service or VSS. Volume Shadow Copy is basically a backup mechanism built into Windows. So as an attacker, we talk to VSS on that box and we say, "Hey, I need a backup of the C volume," assuming that NTDS.dit is on your C volume. You say, "I need a backup of the entire C volume." It makes a backup of that C volume, and then you reach into that shadow copy, and you pull out just a copy of NTDS.dit.
You now have a full replica of NTDS.dit at the time that you made that copy, and it is not open for reading/writing by any other process, so we can now open it. And once we open it, we can parse through it using a bunch of different methods. There are several tools out there that do this, including NTDS extract and Metasploit's Meterpreter. We can then parse that out and find the usernames and password hashes, and send them back.
Now, the drawback of this is that it requires several things to be in place for it to work. You have to have an appropriate administrative level access on the box, the Volume Shadow Copy Service has to be running and available, and you have to have sufficient space to make that backup on the drive. But if you can do all of those things, there is no chance of crashing LSASS or any other critical process, which means that you're far less disruptive to the environment, and you're less likely to get caught.
One of the other advantages to this technique versus LSASS, is while LSASS will give you what the current usernames and password hashes are, NTDS.dit also contains the password history. This means that the previous 12 password hashes, and this can actually be configured up to 20, are also stored for each username in here. So you can get not only what somebody's current password hash is, but the previous 12 to 20 password hashes that they've had.
Now, if you take those password hashes and start cracking them, you might very quickly determine that there is a pattern to how those people pick that password. So now, not only do you have their current password, but you probably have pretty good guess as to what their next password is going to be if they follow a pattern of something like say, "summer2015," or, "fall2015," etc, etc.
So you can see that while this method requires a lot more setup, it is a superior and much safer way of performing this kind of an attack.
Thank you for joining us, and we'll talk to you next week.
