The awesomesauce of the Kerberos Golden Ticket (based on the spoofed-PAC whitepaper from BlackHat 2012) has started to change how I operate on my engagements, especially during repeat assessments done for the same customer. I’m now maniacally intent on getting the krbtgt hashes for as many domains as I can in the target network. Most often, I’ll try to do some trust enumeration and then target the forest root if I can realistically reach it.
Once I get to a DC, I try not to use Meterpreter’s smart_hashdump if I can help it. There is a particular defensive product that has given us heartburn when trying to use this module to dump hashes from a live domain controller. Think hash dumping failing, or even the DC rebooting :)
So my standard tradecraft is to not put any active agents on a DC itself, but to use volume shadow copy to save off clones of the SYSTEM hive and the ntds.dit Active Directory database. There are some great posts out there on how to do just this, through a RDP session, PSEXEC, or straight with WMI. This technique has been around for a good while but still works like a charm. Also, clymb3r has a method that uses PowerShell (and no Volume Shadow Copy) to clone off NTDS.dit’s. This script (Invoke-NinjaCopy) has been in PowerSploit for a bit now.
After you get these files back onto your machine, standard practice seems to involve using libesedb to extract the datatable from the ntds.dit database, and then ntdsxtract/creddump to extract the hashes (or history/whatever you want). However, I’ve had a few engagements now where the ntds.dit recovered didn’t like to parse with these libraries. The database being wonky and/or ‘not being shut down properly’ caused standard extraction to fail. Even Microsoft’s repair tool Esentutl failed to help deliver me that delicious krbtgt hash.
I may have been missing something obvious/doing something dumb that caused the extraction to error out, but my focus on a limited engagement is to get things working as quickly as I can. And there’s nothing more frustrating than going through a non-trivial attack chain, knocking over a DC, exfiltrating the ntds.dit/SYSTEM hive, and then not being able to extract the information you want from it :(
Luckily, after some research, there was one tool that seemed to work more consistently across the (possibly corrupted) ntds.dit databases I had in my possession. Impacket, the awesome network manipulation library, has a great tool called esentutl.py which will extract tables from a NTDS.dit database. However, while all the data needed is there, this output doesn’t play nice by default with the creddump toolkit. I got tired of doing the decryption more or less manually per account and ended up writing a short parser for this type of output.
ImpDump will take the raw output from esentutl.py and decrypt user hashes and/or user hash histories using the appropriate SYSTEM hive. After installing Impacket, you can save some space on the initial extract by just pulling the fields we need for hash extraction by using the supplied ./extract.sh bash script. This just wraps some syntax for esentutl.py. Then using the SYSTEM hive of the DC and ImpDump, you can extract users hashes like so:
./impdump.py /path/to/SYSTEM output > hashes.txt
If you want hash histories, do:
./impdump.py /path/to/SYSTEM output -history > hash_history.txt
If anyone else find this useful, let me know!