TLDR: Python script to automate the extraction of hashes from ntds.dit and system files. Available here : https://bitbucket.org/grimhacker/esedbxtract.
During an internal Penetration Test, once I’ve gained Domain Administrator access the fun doesn’t stop. In order to test the strength of user account passwords I need to retrieve the password hashes.
There are several ways to do this with either specialist tools or builtin Windows utilities as @lanjelot discusses here and Inquis discusses here and here.
My preferred method is to use Volume Shadow Copy to extract a copy of the NTDS.dit and SYSTEM files, since this is an administrative task carried out with Windows utilities it does not normal cause alerts or require the Antivirus to be disabled – as is the case with some of the other options.
Once I have these files on my Kali box I use esedbexport from libesedb to export the data and link tables, these tables are used with the SYSTEM file by ntdshashes.py (available here by LaNMaSteR53 based on ntdsusers.py from ntdsxtract) to get the hashes.
This method can take a long time if the Active Directory is very large, but at this point during the assessment I’m not usually in a rush, it is less intensive on the domain controller, and it doesn’t panic the IT staff of the organisation with alerts.
There are a few reasons why I wrote a script to automate the extraction of the hashes from the NTDS.dit and SYSTEM files.
First and foremost, it’s a multi step process that doesn’t actually require any brain power – just for the output of one tool to be fed into another in the correct way. Writing a script to do this means that time isn’t wasted waiting for me to come back to it between each step. And of course it is another success for my continuing mission to replace myself with a small script…
Second ntdshashes.py didn’t work with the the latest version of ntdsxtract when I last rebuilt my machine (because a ntdsxtract added a new required working directory parameter). I patched the script (and raised an Issue on the repository) but decided it wouldn’t take much work to rewrite it as a class and include it in a larger tool.
Finally I hadn’t played with calling external programs as a subprocess in python before and this seemed like a reasonable excuse.
The result is esedbxtraxt.py available on BitBucket: https://bitbucket.org/grimhacker/esedbxtract.
Dependencies are stated in the README.
Normal usage will result in the password hashes being written to ‘hashes.pwdump’:
python esedbxtract.py -n /path/to/NTDS.dit -s /path/to/SYSTEM
Use ‘–help’ or see the README for further options.
As always, if you have any questions, comments or suggestions please feel free to get in touch.
Hey, great tool you have created here. I found that using the latest libesedb was taking literally weeks to complete extracting hashes. Something was obviously wrong. A little investigating found others having the same problem, and stating that the problem was introduced in a libesedb release in 2014, and has been there ever since. So, the solution has been to go back to a 2014 version of libesedb, which is not available on their git repo, and took a little searching to find. This makes me nervous, of course. I wonder if you had any similar experience to speak of or if you are still using an old libesedb version, or are aware of any solution or workaround? Many thanks in advance.
Hi! Thanks very much!
I haven’t experienced this issue with libesedb myself, however I do know of others who have and solved it in the same way.
I am using the version from the Fedora package manager, I’ve just checked and this appears to be a build from 2012. If you are comfortable building from source you can download a tarball of this version here.
The full project history back to 2009 is also available on GitHub (here), so I believe you should be able to clone the repository then checkout the version you require and build from source.
I hope that is helpful, feel free to get in touch of the is anything else I can help with. 🙂
Brilliant stuff, thank you for the quick reply. Great suggestion, I will check out the code from 2014 and compile. Curious about what was introduced to slow things down so much… conspiracy theories abound!
Thanks again