Domain Controller Password Quality Check

Overview

In this article, we gonna talk about auditing the quality of the passwords from a Microsoft Windows Domain Controller. As we all know, we need to use strong passwords. SysAdmins do have control over the password policy, through the Group Policy. When the SysAdmins are aware of the cybersecurity risks of the company, they will configure a strong password policy. But, in the end, it comes to a user action to set a strong password. If the company is forcing a minimum password strength of a password with at least 13 characters, and a user is configuring the password: ‘MyPassword123!’, then it corresponds to the minimum length of 13 characters and to the complexity requirements. But, we all know that this is not a recommended password and that this can be considered a weak password. For an average home computer, it will take approx 13 days to crack this password. So, time to audit the passwords of your company. In this article, we walk through the steps of how you can conduct a password quality check.

First a deep bow to the work of Michael Grafnetter for wrapping up the DSInternals Framework. Without his work, it would not have been possible for us to perform a password audit. The DSInternals Framework can be downloaded from his Github page.

The DSInternals Framework, will check the following components:

1. If the passwords of these accounts are stored using reversible encryption.
2. If the LM hashes of passwords of the accounts are present.
3. If there are accounts that have no password set.
4. If the passwords of the accounts have been found in the HIBP dictionary.
5. If the historical passwords of these accounts have been found in the dictionary.
6. If there are accounts that have the same passwords.
7. If the computer accounts have default passwords.
8. If the Kerberos AES keys are missing from the accounts.
9. If Kerberos pre-authentication is not required for these accounts.
10. If only DES encryption is allowed to be used with these accounts.
11. If there are administrative accounts that are allowed to be delegated to a service.
12. If there are passwords of the accounts are set to never expire.
13. If there are accounts that are not required to have a password.

As you can see, it is an extensive audit that takes place, which actually goes far beyond a password audit.

What is the NTDS.dit?

If you are already familiar with the NTDS.dit, you can directly jump the Password Quality Check. The NTDS.dit is the Active Directory database. It stores all of the Active Directory objects, including user objects, groups, and group memberships, and all of the password hashes of the user accounts. This file is located in the ‘C:\Windows\NTDS\’ directory. You’re not able to open, modify, or copy this file since it is being used by the Kerberos Key Distribution Center. By extracting the hashes, it’s possible to crack these hashes with hashcat or to perform pass-the-hash attacks with Mimikatz.

Preparations

Download wordlist from HaveIbeenPwned

The password hashes will be compared against the HIBP password list. This password list can be downloaded from https://haveibeenpwned.com/Passwords. Choose the torrent download ‘ordered by hash’. You need this file in order to proceed.

HIBP is regularly updating the password file. Make sure that each time you performing a password audit, that you check whether you’re using the latest version of the file.

Install Powershell Module DSInternals

As already mentioned, we are going to perform the audit with the DSInterals Framework. If you’re using Powershell 5 or higher, you can install this module directly from the [Powershell Gallery](https://www.powershellgallery.com/packages/DSInternals/{:target=”_blank”} with the command below. If you’re running an older Powershell version, check the Github repository for further instructions on how to install this module.

Install-Module DSInternals

Everything is set-up. We’re rolling!

Password Quality Check

Create a Volume Shadow Copy

To extract the hashes from the NTDS.dit, we need to create a Volume Shadow Copy of the Windows-drive. Make sure that you open Windows Powershell as Administrator.

vssadmin create shadow /For=C:

Copy the NTDS.dit from the Volume Shadow Copy

The Volume Shadow Copy is created. Make note of the name of the Volume Shadow Copy. The next step is to copy the NTDS.dit database to your location. In this example we will copy it to the C:\Users\Administrator\Desktop\DumpCreds location. Please note: the integer in the command below for defining the VSS copy can be different in your situation.

Copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy25\windows\NTDS\ntds.dit c:\Users\Administrator\Desktop\DumpCreds

Copy the SYSTEM

The NTDS.dit file is encrypted. The Boot Key is located in the SYSTEM in the registry. We need to copy this file and extract it to Boot Key to decrypt the contents of the NTDS.dit.

reg save hklm\system .\system

Extract the Boot Key from the SYSTEM file.

Get-Bootkey -SystemHiveFilePath .\system

Remove the Volume Shadow Copy

Before you are conducting the password quality check, make sure that you remove the Volume Shadow Copy. This in the context that you have to clean up your mess. You can remove the created Volume Shadow Copy with the command below.

vssadmin delete shadows /for=C:\

Password Quality Check

We have the NTDS.dit and we have the Boot Key, now you can perform the password quality check. Run this command below, it will extract all the accounts from the NTDS.dit database and it will compare the hashes with the hash file from HIBP. If you running into any problem, check the Troubleshooting section below.

Get-ADDBAccount -All -DatabasePath 'ntds.dit' -BootKey 0c2ad61118gab7b64e24cdab3f4a84b | Test-PasswordQuality -WeakPasswordHashesSortedFile "C:\Users\administrator\Downloads\passwords\pwned-passwords-ntlm-ordered-by-hash-v7.txt

When the script is done working, the actual report will look like the sample report below. This is a human-readable report, but still, an object, whose properties can be accessed separately (e.g. $result.WeakPassword) to produce the desired output.

Active Directory Password Quality Report
----------------------------------------

Passwords of these accounts are stored using reversible encryption:

LM hashes of passwords of these accounts are present:
  FUTURE\admtricker
  FUTURE\admagb
  FUTURE\Administrator
  FUTURE\denavide
  FUTURE\bhchilversum1
  FUTURE\bia
  FUTURE\idebUNiS
  FUTURE\try.developmentteam
  FUTURE\bph.expertteam
  FUTURE\reception
  FUTURE\store
...Active Directory Password Quality Report
----------------------------------------
 
Passwords of these accounts are stored using reversible encryption:
  April
  Brad
  Don
 
LM hashes of passwords of these accounts are present:
 
These accounts have no password set:
  Guest
  nolan
  test
 
Passwords of these accounts have been found in the dictionary:
  adam
  peter
 
Historical passwords of these accounts have been found in the dictionary:
  april
  brad
 
These groups of accounts have the same passwords:
  Group 1:
    Aidan
    John
  Group 2:
    Joe
    JoeAdmin
    JoeVPN
 
These computer accounts have default passwords:
  LON-CL2$
 
Kerberos AES keys are missing from these accounts:
  Julian
 
Kerberos pre-authentication is not required for these accounts:
  Holly
  Chad
 
Only DES encryption is allowed to be used with these accounts:
  Holly
  Jorgen
 
These administrative accounts are allowed to be delegated to a service:
  Administrator
  April
  krbtgt
 
Passwords of these accounts will never expire:
  Administrator
  Guest
 
These accounts are not required to have a password:
  Guest
  Magnus

The report is showing different sections. To know how you need to read this report, I have created an explanation for each section with a recommendation on what you could do.

The passwords of these accounts are stored using reversible encryption

_{Summary: Change the password immediately, disable reversible encryption in the GPO.}

This check shows whether the password is stored using the reversible encryption. The intent of this way of storing the passwords will provide support for applications that require knowledge of the user password for authentication purposes. Storing passwords using reversible encryption is essentially the same as storing the password in clear-text. For security reasons, you should never have user accounts that store passwords with reversible encryption enabled.

If there are user accounts with passwords, saved in reversible encryption, change the passwords immediately. Also, make sure that you have not configured the Store password using reversible encryption for all users in the domain policy in the Group Policy Object (GPO) or in the Local Security Policy of the workstations or servers.

Policy location Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy.

The LM hashes of passwords of these accounts are present

_{Summary: Change the password immediately, disable storing LM hash in GPO or use passwords that is at least 15 characters long.}

LM hashes are used by the LAN Manager (LM) authentication, an old authentication mechanism that predates NTLM authentication. LM hashes are relativity weak and can often be cracked quickly by attackers using brute force attacks. Windows operating systems before Windows Vista, and server operating systems before Windows Server 2008, still compute store both NT hashes and LM hashes.

If your environment is clear of Windows 95 or Windows 98, you should prevent Windows for storing LM password hashes. You can prevent storing an LM hash of your passwords through the Group Policy Object (GPO) or through the Local Group Policy. After configuring this policy, you should change the passwords of these accounts, to make sure that the LM hash is not stored. The simplest way to prevent Windows from storing an LM hash of your password is to use a password that is at least 15 characters long.

Policy location Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network security: Do not store LAN Manager hash value on next password change.

These accounts have no password set

_{Summary: Set a password for the specific user account.}

This indicated that there are accounts present in the Active Directory without a configured password. You should configure a password for these accounts immediately. It’s possible to have user accounts in the Active Directory with no password.

Passwords of these accounts have been found in the dictionary

_{Summary: Change the passwords immediately. Also implementing Two-Factor Authentication is recommended.}

This means that the passwords are present in the HaveIBeenPwnd dictionary and should be considered as a weak password. These user accounts are vulnerable to password spraying. A password Spraying attack is an attack that attempts to access a large number of user accounts with a few commonly known used passwords. If there is no password policy configured which is forcing a lock-out of the user account after some failed login attempts, makes this user accounts also vulnerable for brute-force attacks. It is also a recommendation to implement Two-Factor Authentication if you have not already done so.

Historical passwords of these accounts have been found in the dictionary

_{Summary: Relax, check you password policy, make sure to set the password history to 24 passwords.}

Password reuse is an important concern in every organization. This is one of the main reasons to make sure that you have properly configured the password policy. To prevent password reuse you should configure the password policy to enforce a password history of 24 passwords. This configuration can be done through the Group Policy Object.

Location Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy.

These groups of accounts have the same passwords

_{Summary: Change the passwords immediately.}

Multiple users share the same password. In most cases, it concerns an administrative tool or script that the users created and (accidentally) set up the same password or that these users happened to choose the same password. Enforcing a strong password policy reduces the risk of having users with the same password. The recommendation is that these users change their password.

These computer accounts have default passwords

_{Summary: Change the computer account password with the Reset-ComputerMachinePassword cmdlet.}

Computers are using the computer account to authenticate to the Domain Controllers in the domain. By default, computers are changing the password change every 30 days. It’s possible to change this behavior through the Group Policy if you increase this interval that can cause a security risk. An attacker has more time to brute-force the computer account password. The recommendation is to change the computer accounts password with the Reset-ComputerMachinePassword cmdlet.

Kerberos AES keys are missing from these accounts

_{Summary: Change the passwords of these accounts.}

These accounts are configured using an older domain functional level and have no AES key. These accounts are using weak encryption like DES or RC4 to authenticate to the Domain Controller. Passwords of these accounts should be changed after raising the domain functional level. You should consider changing the passwords of these accounts.

Kerberos pre-authentication is not required for these accounts

_{Summary: Disable ‘Do not require Kerberos preauthentication’ in the ‘Account’ tab of the user properties.}

It’s possible to send an initial request to authenticate to the Kerberos Key Center (KDC), without a password. This is an artifact left over from Kerberos versions before Kerberos 5. The older versions of Kerberos would allow authentication without a password. In Kerberos 5 a password is required. When setting this option to ‘enabled’, you make these accounts vulnerable for AS-REQ (Authentication Server Request) Roasting Attack. The attacker could send a fake AS-REQ request, and the KDC will issue the Ticket-Granting-Ticket. The password hash could be extracted from the data and could be cracked. You should consider disabling this feature in the ‘Account’ tab of the user properties in the Active Directory. You could simply uncheck the checkbox near Do not require Kerberos preauthentication.

Only DES encryption is allowed to be used with these accounts

_{Summary: Disable ‘Use Kerberos DES encryption types for this account’ in the ‘Account’ tab of the user properties.}

DES-encryption is considered as highly insecure, due to the use of 56-bit encryption. DES-encryption is used by Windows server operating system Windows Server 2000 until the client operating system Windows Vista. User accounts with only DES encryption, cannot use the more secure encryptions. The most common cause that DES-encryption is enabled is for the compatibility of a third party application. Microsoft is not using this type of encryption. The recommendation is to disable this setting through the ‘Account’ tab of the user properties in the Active Directory. You could simply uncheck the checkbox near ‘Use Kerberos DES encryption types for this account’, in the properties.

These administrative accounts are allowed to be delegated to a service

_{Summary: Take note of this accounts. You need this information on a password change, to update the specific Windows Service.}

This is to inform you that these accounts are allowed to be delegated to a service. You should take note of these accounts and mark them down in your IT Documentation solution. When you change the password of these accounts, you also need to update the Windows Services to which these accounts are delegated with the new password.

Passwords of these accounts will never expire

_{Summary: You should avoid using this option. Try to keep user accounts with non-expiring passwords to a minimum.}

User accounts with a non-expiring password are (in my humble opinion) one of the major security issues for most organizations. Passwords that aren’t rotated have a higher likelihood of showing up in breached password dumps. In the field, you can see that you can hardly avoid having users whose passwords are not allowed to expire. In many cases, these are Administrator accounts. Try to keep user accounts with non-expiring passwords to a minimum.

These accounts are not required to have a password

_{Summary: Change the UserAccountControl from ‘512’ to ‘0x10200’ in the ‘Attribute Editor’ of the user account.}

What, wait… Do you have user accounts in your Active Directory which are not requiring a password? This simply means that a user is entering his username and hits ENTER, and his computer will logon. This is a security risk. It means that the PASSWD_NOTREQD flag is set in the UserAccountControl attribute. Make sure you enable the ‘Advanced Features’ in the Active Directory and change the value from the UserAccountControl attribute from 512 (PASSWD_NOTREQD) to 0x10200 (NORMAL_ACCOUNT).

Troubleshooting

NTDS.dit database corrupt

After you have copied the NTDS.dit database from the Volume Shadow Copy to your system, it’s possible that the database becomes corrupt. In that case, run the command below to repair the corrupt database.

Esentutl.exe /p .\ntds.dit

SYSTEM corrupt

There is a small change that the configuration registry database becomes corrupt after the copy. You can choose for two ways to copy the configuration registry database from the server.

Get-Bootkey : The configuration registry database is corrupt
At line:1 char:1
+ Get-Bootkey -SystemHiveFilePath .\SYSTEM
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (.\SYSTEM:String) [Get-BootKey], Win32Exception
    + FullyQualifiedErrorId : GetBootKey_Win32Error,DSInternals.PowerShell.Commands.GetBootKeyCommand

The first one is with the copy commando, to copy the database from the Volume Shadow to your machine, with the command:

Copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy25\windows\system32\config\SYSTEM c:\Users\Administrator\Desktop\DumpCreds

Or you can use the way we have done in this article.

reg save hklm\system .\system

If you still had some problems, please leave a comment below. Please note, I am not the developer of the tool, just a user.

This blog is totally free and I spend my spare time writing articles doing machines on Hack The Box and writing blog articles. I’m not using any advertisements from Google or other advertising programs because they gather much data from you. Please help me to keep this website free of advertisements and consider supporting me.

References

• Auditing Active Directory Password Quality
• Store password using reversible encryption for all users in the domain
• Prevent storage of LAN Manager password hashes
• Enforce password history
• Remove the highly insecure DES encryption from User accounts