Weak passwords are one of the most common ways to compromise an environment. If you’re using a traditional on-premise Active Directory, then carrying out your own password auditing is a very effective way to identify weak passwords in your network, and also to measure the effectiveness of policy changes and training programs. Please note that this article is focused on Active Directory - if you’re using Azure AD or Azure AD DS then please see the discussion of those in the Azure AD Password Auditing article.
The basic steps to carrying out an internal password audit are:
- Obtain a copy of
- Extract the hashes from it.
- Crack the hashes.
- Analyse and interpret the results.
The first step is to take a copy of the
NTDS.dit file from a Domain Controller, which contains the password hashes (and most of the other information stored in AD). There are various techniques that can be used to obtain them, but the simplest one is using a built-in Microsoft tool called
You can dump a copy of the
NTDS.dit file (and also the
SYSTEM registry hive which is required) into
C:\passwordaudit by running the following command from an elevated command prompt on the server:
ntdsutil "activate instance ntds" "ifm" "create full c:\passwordaudit" "q" "q"
Depending on the size of your AD, this file will vary from a few MB up to a few GB - so make sure that you have enough free space. Endpoint security software on the server might also block this action.
Once the command is completed, you can copy the
SYSTEM files onto another system to extract the hashes there (they compress well, so ZIP them if they’re large). These files contain password hashes, so should be treated with the same sensitivity as you would a list of administrative passwords for your domain. Remember to clean them up on the Domain Controller once you have a copy.
Extracting the hashes
Once these files have been obtained, we need to extract the hashes from them. The best tool for this is NtdsAudit, which is available as both source code and as a pre-compiled binary on GitHub. You can dump the password hashes from the files we previously copied with the following command:
NtdsAudit.exe -s SYSTEM -p hashes.txt NTDS.dit
This will create a file called
hashes.txt with the password hashes, and also output some useful stats to the screen. Once you have this file, you can delete the
SYSTEM files. As above, this file is very sensitive, so make sure that you protect it.
Cracking the hashes
There are a variety of tools that can be used to crack the hashes, but in this example we’ll use John the Ripper. It’s installed by default in Kali, but you can also get Windows binaries from the Openwall website.
Once you’ve installed or unzipped it, you can run it from a command prompt. Single crack mode (which tries variants of the username, as well as some common strings and patterns) is always a good starting point:
john hashes.txt --format=nt --single
After that, a wordlist attack with some rules:
john hashes.txt --format=nt --wordlist --rules=best64
The default wordlist with john is pretty small, but there are lots of other ones available, such as the popular rockyou list, which is included in the
/usr/share/wordlists/ folder in Kali (although made need decompressing before use). You can specify a custom wordlist with
Once you’ve done that, it’s worth running loopback mode, which tries permutations of previously cracked passwords:
john hashes.txt --format=nt --loop
As well as printing them to the console, john will store all cracked passwords in the
john.pot file, and potentially also in the
john.log file. Keeping a pot file can make future audits quicker (and allow you to see how many passwords are unchanged) - but the file must be carefully protected.
John’s Secure Mode
One of the risks of password auditing is that it exposes other users’ passwords to the individual who’s carrying out the audit. In some environments this is an unacceptable accountability issue - but there is a way that it can be avoided.
John has a little-used feature called SecureMode, which means that passwords are never displayed in the output, and are not written to the log or pot files. You can enable it by setting the following configuration option in
SecureMode = Y
When passwords were normally be displayed, John will display a string that shows some information about the length and character set, such as the example below for an account with a password of
The output indicates that the password is nine characters long and is made up of lower-case (
?l), digits (
?d) and upper-case (
Once you’ve finished with the cracking, you can display all of the cracked passwords with:
john hashes.txt --format=nt --show
The output is quite messy, but if we want just the usernames and passwords for enabled and active accounts, we can filter it with grep and cut:
john hashes.txt --format=nt --show | grep -Ev "Disabled=True|Expired=True|__history" | cut -f 1,2 -d:
Rather than trying to manually analyse these, there are several tools available that can help. pwdumpstats.py is a Python script that can be run on a hash file and identifies issues such as password re-use between accounts. It can be run with:
pwdumpstats.py hashes.txt -p john.pot
If you’re more interested in the stats than the passwords themselves (such as common base words, character sets and lengths) then Pipal can also provide some details. First we need to dump out a list of just the passwords:
john hashes.txt --format=nt --show | grep -Ev "Disabled=True|Expired=True|__history" | cut -f 2 -d: > cracked_passwords.txt
Then we run Pipal against the output:
Improving the Process
Once you’re comfortable with the basic process, there are lots of additional improvements you can make, such as:
- Dumping password history hashes with NtdsAudit’s
--history-hashesoption to see trends over time.
- Using bigger wordlists and more rules to crack additional passwords.
- Creating custom wordlists based on your organisation details or sector.
- Using more advanced attacks such as:
--markovfor passwords that are based on similar patterns.
--maskfor passwords that follow a common pattern.
--princefor passwords made by combining multiple words or strings.
- Carrying out further analysis with custom scripts or more powerful tools.
- Automating the process to make it quicker to perform in future.
Once you’ve finished auditing the passwords you get to the tricky bit: dealing with the weak ones. There’s no simple answer to this, and the steps that are appropriate will depending on both your findings and the wider context around your organisation. However, some common areas to consider are:
- Changing any passwords that were cracked in the audit.
- Disabling regular password expiration, as recommended by NCSC, Microsoft, NIST and others.
- Enforcing multi-factor authentication (MFA) for all externally facing systems.
- Ensuring that your IT staff and support desk always set strong passphrases on new accounts or password resets.
- Providing additional training on how to create secure passphrases using methods such as combining multiple words.
- Providing users with secure password managers and single-sign on, to reduce the number of passwords that they have to remember.