Active Directory Password Auditing Part 1 – Dumping the Hashes

One of the recurring issues in our internal penetration tests is inadequate password management, which in most cases leads to a fast takeover of the Active Directory (AD) domain. Most system administrators consider that just enabling password complexity and setting a sensible password length are enough. However, since “Password1” can pass the default Windows complexity requirements, organisations should consider additional technical controls to reduce the risk of weak domain passwords. This blog post will focus on how to conduct an AD password audit in order to identify weak domain credentials.

Windows Passwords Storage

Both local and domain Windows passwords are stored as a hash on disk using the NTLM algorithm. Older versions of Windows (prior to Windows Server 2008) also store passwords using the LM hashing algorithm. LM hashing was deprecated due its weak security design which is vulnerable to rainbow tables attacks within a greatly reduced period of time.

By default, the domain password hashes are stored in domain controllers (DC) at the following locations:

Ntds.dit is the main AD database, and includes information about domain users, groups, and group membership. It also includes the password hashes for all users in the domain. To further protect the password hashes these are encrypted using a key stored in the SYSTEM registry hive. This second encryption step is why in order to perform a password dump for auditing, a copy of both files is needed.

The major steps required for performing a password security audit are obtaining the files containing the information, dumping the password hashes from the files, and then using a password cracker to test these hashes for weak passwords:

Obtaining Windows Password Files

The most reliable method of performing a password audit is offline by getting a copy of the Ntds.dit and SYSTEM files. Since these are locked by Windows preventing standard reading or copying, special techniques have to be used to obtain a copy. The guideline below shows how it’s possible to obtain these files.

Windows Server 2008-2016

On systems using Windows Server 2008 and onwards, the easiest and most reliable way of dumping both Ntds.dit and the SYSTEM hive is to use Microsoft’s built-in tool ntdsutil. This automatically locates the files, takes a volume shadow copy, and repairs and defragments the database.

The following commands will create a folder called C:\audit containing the Ntds.dit and SYSTEM files:

C:\> ntdsutil

ntdsutil: activate instance ntds
ntdsutil: ifm
ifm: create full c:\audit
ifm: quit
ntdsutil: quit

These commands and the output you can expect are shown below:

At this point we’re ready for the next step.

Windows Server 2003

For Windows Server 2003 systems, this can be done using the Volume Shadow Copy method. Volume Shadow Copy allows you to obtain copies of Ntds.dit and SYSTEM files.

The following command allows to check whether any shadow copies already exist:

vssadmin list shadows

Check that the server has sufficient free disk space available and then create a shadow copy using the command below:

vssadmin create shadow /for=C:

Once this has run, check the ID and GUID of the shadow copy created. These can be substituted into the following commands to copy out the Ntds.dit and SYSTEM files:

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy[ID]\windows\ntds\ntds.dit .

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy[ID]\windows\system32\config\SYSTEM .

After that, delete the shadow copy initially made (double check the GUID):

vssadmin delete shadows /shadow=[GUID]

Please note that in order to obtain the hashes in Windows 2003 systems you also need to repair the Ntds.dit database first, which you can do with esentutl tool. Note that whilst esentutl is available on Windows 10, the version of Jet Blue (the NTDS database format) is incompatible with Windows Server 2003. Therefore, these repair commands must be run on a Windows 2003 system, such as the DC.

Ensure copies of the Ntds.dit file and the edb*.log files are available in the same folder where Ntds.dit is located and run the following commands:

esentutl /r edb /8 /d /o

esentutl /p .\ntds.dit /8 /o

Dumping Hashes

While there are many tools online for decrypting NTLM password hashes, we found that most of them are quite unreliable. As a result, my colleague Phill developed a tool called NtdsAudit to do this, which has now been publicly released. You can get the latest release from Dionach’s Github repository.

To dump the NTLM password hashes from the files you obtained in the first step, you can use the following command:

NtdsAudit.exe "ntds.dit" -s "SYSTEM" -p pwdump.txt --users-csv users.csv

A sample of the outputted pwdump.txt file is shown below, containing the username and LM and NTLM hashes:

Further AD Analysis

Besides dumping password hashes, NtdsAudit computes some useful summary statistics about Active Directory accounts and passwords, including information about dormant accounts or users with duplicate passwords. By appending the –users-csv parameter, more details on AD accounts can be obtained.

An example is shown below:

Cracking the Hashes

Now that we have the hashes dumped, the next step is cracking them to obtain the clear-text passwords. Part 2 of this series explores some of the different tools and techniques that can be used.

Conclusion

While AD password auditing used to be in the grey area for a long time due to the large number of tools and unreliable guidelines, this should be no longer an excuse for any organization irrespective the size. By performing regular password security audits (i.e. at least twice a year) and implementing additional technical security controls (such as Windows hardening, and regular penetration tests), organizations can decrease the risk of hitting the headlines for the wrong reasons.