Where does Active Directory store user hashes?

Question

During a penetration test for a client, having an infrastructure with multiple (5) Active Directory Servers (Win Serv 2008 R2)... I found a nice exploit to drop a system shell in one of the servers, and stole the domain admin account with mimikatz.

But the problem is, I used quarks-pwdump to dump the hashes... And I am not able to dump all the domain user hashes (most of the LM hashes retrieved are "aad3b435b51404eeaad3b435b51404ee").

I dumped them from the main DC, and a secondary one, both showing the same result. Is there a way to locate the password hashes in the ADs? Is it possible to change the domain configuration to choose the DC on which the hashes are stored ?

Answer 1

The hashes are located in NTDS.dit, although some software can inject into the LSASS process and extract them in-memory. In terms of which DC to use, this data should be replicated across each controller. You may see minor differences where a password has been changed on one and not yet copied the others (more on replication timings), but it is likely that the majority will be up-to-date.

quarks-pwdump expects you to use the Volume Shadow Copy method (utilising Volume Shadow Service - VSS) to retrieve NTDS.dit manually. The tool can then be used to parse hashes from this file. This in is contrast to dumping local hashes where the tool injects into the LSASS process. Using VSS (or registry backups for local dumping) can generally be safer and quieter than using an in-memory technique. These should be preferred where possible, which may be what Quarks are trying to promote.

The VSS method is detailed here (although this is to dump the registry hives, so needs to be adapted to NTDS.dit): http://bernardodamele.blogspot.co.uk/2011/12/dump-windows-password-hashes.html

A follow up post on NTDS.dit: http://bernardodamele.blogspot.co.uk/2011/12/dump-windows-password-hashes_16.html

Once you've retrieved the file, you can use quarks-pwdump to parse it with -dhd and -nt path/to/file/NTDS.dit (which is a hell of a lot easier than using NTDSXtract).