Active Directory Password Auditing

Fingerprint Icon

Introduction

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 NTDS.dit.
  • Extract the hashes from it.
  • Crack the hashes.
  • Analyse and interpret the results.

Copying NTDS.dit

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 ntdsutil.

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 NTDS.dit and 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 NTDS.dit and 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 --wordlist=/path/to/wordlist.txt

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 john.conf:

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 Password1:

L9-?l?d?u (domain.local\Administrator)

The output indicates that the password is nine characters long and is made up of lower-case (?l), digits (?d) and upper-case (?u) characters.

Analysis

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:

pipal cracked_passwords.txt

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-hashes option 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:
    • --markov for passwords that are based on similar patterns.
    • --mask for passwords that follow a common pattern.
    • --prince for 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.

Next Steps

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.