Extracting Password Hashes from a Domain Controller

On a Penetration Test, once you’ve scored Domain Admin (DA) Access, it’s generally a good idea to take a look at the hashes stored in Active Directory (AD). Not least because it’ll point out all of the weak accounts that you missed on your journey to DA but also because password reuse across accounts may get you into other systems, such as Linux servers or the network infrastructure.

There are a few methods of dumping hashes and every PenTester I expect knows one of these, but I’ve included a few as it’s always good to have a backup plan.


The first method is the one I personally use the most; I find it the simplest way of achieving the goal. Simply upload Fgdump (from https://github.com/interference-security/kali-windows-binaries/tree/master/fgdump) to the server and run it with elevated privileges! Personally I use RDP for this and mount my local machine’s drive then execute the EXE from the share.

The benefit here is that I find that a surprising number of anti-virus systems will ignore known malicious files if they’re loaded over an SMB share.

Meterpreter’s Hashdump

The second method is almost as easy and has an added anti-virus evasion option. Simply pop a Meterpreter shell on the target system and utilise the “hashdump” command from Meterpreter. You can do that simply by uploading the EXE over RDP as above, through the exploitation of a vulnerability or by using the built in PsExec module in exploit/windows/smb/psexec.

The benefit here is that if you’re battling against anti-virus you can make use of Veil-Evasion (from https://www.veil-framework.com/framework/veil-evasion/) to bypass many common anti-virus in a few simply steps.

Volume Shadow Copy

The last method I ignored for a long time, the benefits told to me were that it’s more manual and therefore not reliant on tools – I acknowledged this but took the “lazy” approaches above for the most part; Then of course one day the tools I favour didn’t work and I was left with no choice but to break out the books and learn this method. By /more manual/, it turns out that it’s really not so bad at all and may become my preferred method in the future.

This is a two step process, the first is to acquire the NTDS.dit and SYSTEM file from the target Domain Controller (DC) which contains the hashes, the second step is to extract the hashes.

Grabbing NTDS.dit via Shadow Copy:

vssadmin create shadow /for=C:
copy \\?GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit c:\
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM c:\

Throw those over to your attack machine and you can extract the hashes using GrimHacker’s ESEDBxtract tool, available here: https://bitbucket.org/grimhacker/esedbxtract – note it depends on libesedb (from https://code.google.com/p/libesedb/) but if you’re part of the Fedora Superrace then you can install it with: sudo yum install libesedb and grabbing esedbxtract is as simple as:

 git clone https://bitbucket.org/grimhacker/esedbxtract.git 

Utilising the tool looks a little like:

python esedbxtract.py -s /home/holly/Engagements/ClientXSep2015/SYSTEM -n /home/holly/Engagements/ClientXSep2015/ntds.dit 

The benefit here is that the extraction of hashes is done on the attacker’s machine rather than the domain controller, plus that it uses standard Windows tools and therefore shouldn’t trigger any anti-virus!
Whatever method you use, you should end up with output like this:


Which you can feed in to a tool like OphCrack, John the Ripper, or HashCat to crack back in to a plaintext password!

Read More