Active directory in Windows have some built in features to set restriction for passwords created in your environment. How cool would it be if we can compare the passwords used in your AD environment with the passwords disclosed in breach database? By doing this you can ensure that none of your users are using weak or passwords exposed in data breaches. If you are in IT security operations, this is something you really have to do and your CISO will definitely love it. To get this done we can make use of some cool OSINT tools. Password hashes from breaches and tools or scripts to query in Active Directory are required to perform this audit. Integrating them would give you an fantastic solution to audit your Active Directory.

Data breach database

HaveIBeenPwned (HIBP) contains passwords from many major data breaches, including Adobe, LinkedIn and many more. HIBP offers these password in SHA-1 and NTLM formats to download. There is even a API available which can integrated into any application. When I was drafting this post, HIBP contains 551 Million pwned passwords. If you check that link, you can find the download link available in NTLM format. You can either download the file directly or use torrent and download at your desired speed/time.

OSINT Tools which supports HIBP

1. DSInternals

DSInternals is a fantastic powershell module developed by Michael Graffnetter. It has multiple functionalities like hash dumping, password reset, LSA policy modification.

• Install DSInternals using the instructions here.
• Download the NTLM hash(ordered by hash) from HIBP
• Now you can query your AD using the cmdlets described here.

You will get results similar to the sample below.

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

Passwords of these accounts are stored using reversible encryption:
  smith
  doe

LM hashes of passwords of these accounts are present:
  hodge

These accounts have no password set:
  test01
  test02

Passwords of these accounts have been found in the dictionary:
  Administrator

These groups of accounts have the same passwords:
  Group 1:
    graham
    graham_admin
  Group 1:
    admin
    sql_svc01

These computer accounts have default passwords:
  DESKTOP27$

Kerberos AES keys are missing from these accounts:
  sql_svc01

Kerberos pre-authentication is not required for these accounts:
  jboss

Only DES encryption is allowed to be used with these accounts:
  sql_svc01

These administrative accounts are allowed to be delegated to a service:
  AdatumAdmin
  Administrator

Passwords of these accounts will never expire:
  admin
  sql_svc01

These accounts are not required to have a password:
  gonzales

You can automate this by creating a scheduled task and save the results in a file.

To store results in a .csv, try the below commands in your ps script.

$accounts = Get-ADReplAccount -All -NamingContext 'DC=contoso,DC=com' -Server dc1.contoso.com
$results = $accounts | Test-PasswordQuality -WeakPasswordsFile BadPasswords.txt
$riskyAccounts = $accounts | where SamAccountName -in $results.WeakPassword
$riskyAccounts | select SamAccountName,DisplayName,DistinguishedName | Export-Csv output.csv

Here are recommendations which will help to address the accounts available in different sections of DSInternals report.

Password quality analysis report recommendations.

• Passwords of these accounts are stored using reversible encryption
  Storing encrypted passwords in a way that is reversible means that encrypted passwords can be decrypted. A knowledgeable attacker who can break this encryption can then log on to network resources by using the compromised account. For this reason, never enable Store password using reversible encryption for all users in the domain unless application requirements outweigh the need to protect password information.
  https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policysettings/store-passwords-using-reversible-encryption
  
  
• LM hashes of passwords of these accounts are presentLM is a weak hashing algorithm in Windows. Windows has replaced this NTLM hashing. Microsoft recommends preventing the storing of LM hashes. https://support.microsoft.com/en-au/help/299656/how-to-prevent-windows-from-storing-a-lanmanager-hash-of-your-passwor
  
• These accounts have no password set
  Creating accounts without passwords is a serious security gap. Instead of creating accounts with no password, try fine grained password policies.
  https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and2008/cc770394(v=ws.10)?redirectedfrom=MSDN
  https://docs.microsoft.com/en-us/archive/blogs/canitpro/step-by-step-enabling-and-using-finegrained-password-policies-in-ad
  
• Passwords of these accounts have been found in the dictionary
  NIST released guidance specifically recommending that user-provided passwords be checked against existing data breaches. Accounts listed under this title are using a weak or one of the passwords exposed in data breaches. Attackers can run brute force or password spraying attack using dictionaries and break into these accounts. It is highly recommended to change the password for these accounts immediately. Verify here to find if you are using a password exposed in data breaches https://haveibeenpwned.com/Passwords
  
• These groups of accounts have the same passwords
  Some organizational units require their IT staff to have at least 2 user accounts, one for regular and one for administrative operations. Such security policies become much less effective if these 2 accounts have the same password. It’s important to manage your administrative credentials separately. Manage privileged accounts effectively using a PAM solution.
  
• These computer accounts have default passwords
  During the process of creating or resetting a computer account, its password is automatically set to its logon name. Under some circumstances, these initial passwords might not get changed by the corresponding computers and could thus be guessed by attackers to get basic permissions to access Active Directory. Do not using default computer account passwords, change them immediately.
  
• Kerberos AES keys are missing from these accounts
  Only weak encryption algorithms like DES or RC4 can be used during authentication of accounts that are missing Kerberos AES Keys. Passwords of these accounts should be changed after raising the domain functional level to Windows Server 2008 or higher.
  
• Kerberos pre-authentication is not required for these accounts
  Kerberos pre-authentication is often used to prevent offline password-guessing attacks and is implemented by default. However, it can be disabled for individual accounts to resolve some compatibility issues.
  https://social.technet.microsoft.com/wiki/contents/articles/23559.kerberos-pre-authenticationwhy-it-should-not-be-disabled.aspx
  
• Only DES encryption is allowed to be used with these accounts
  The Kerberos protocol was originally implemented using the Data Encryption Standard (DES) as a block cipher for encryption. Back in version 1.0, it was secure but since then it has proven vulnerable to brute force attacks and has been ‘retired’. It has been replaced by the Advanced Encryption Standard (AES). Use Kerberos DES encryption types for this account option.
  https://docs.microsoft.com/en-us/services-hub/health/remediation-steps-ad/remove-the-highlyinsecure-des-encryption-from-user-accounts
  
  
• These administrative accounts are allowed to be delegated to a service
  Administrator accounts should never be used as service accounts on member servers, nor should they be used to log on to local computers. Implement the least privilege model.
  https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-bestpractices/implementing-least-privilege-administrative-models
  
• Passwords of these accounts will never expire
  Setting user accounts password to never expire is not recommended and can be a security risk. There are times when this can’t be avoided such as using a service account. Microsoft recommends getting rid of password expiry configuration. https://www.microsoft.com/en-us/research/publication/password-guidance/ Instead check the password quality and weak passwords using this report.
  
• These accounts are not required to have a password
  Enabling the ‘password not required’ property is a huge security risk because it disables Windows first line of defense—user authentication. As with the Password never expires user account option, disabling the requirement for a password on a user account undermines your domain or corporatewide password policy and can create serious security holes in the AD forest

2. Lithnet Password Protection for Active Directory

Lithnet provides deep integration between HIBP Password DB and Active directory. Lithnet not only checks for pwned passwords, but blocks when a user is trying to set a new password which is part of pwned passwords or a dictionary.

These are some of the features of Lithnet

• Block compromised passwords from being used.
• Block passwords based on certain words.
• Define complexity policies based on length.
• Regular expression-based policies.
• Points-based complexity.

Lithnet supports writing logs in Windows event viewer, this will help administrators to create alerts whenever someone tries to create a pwned password.

3. Compromise Checker

Compromise is simple GUI based tool which supports HIBP database to check pwned passwords. It lets you check users from a specific OU.

4. Identifying Pwned Passwords using Microsoft/Forefront Identity Manager v2, k-Anonymity

HIBP Pwned password has a API support as well. This tool from Kloud supports checking pwned passwords in active directory by leveraging HIBP API.

This is how this tools works.

• taking the new password received from PCNS
• hashes the password to SHA-1 format
• looks up the v2 HIBP API using part of the SHA-1 hash
• updates the MIM Service with Pwned Password status

In this way you don’t have to download the pwned passwords every time it is updated in HIBP. You need a API key which was once free and now costs US$3.50 per month. After this announcement, this tool supports using downloaded database of pwned passwords. So an updated version is listed here.

Dictionaries to use in addition to HIBP

Some of the tools listed above supports checking password against any dictionary passwords list. If you are looking for such list, Seclist is a great resource I would recommend. It contains various password dictionaries used by white/black hat hackers.

Troy Hunt has done a incredible work by creating HIBP and there are so many organizations including Governments are using it. Take a look at here to find the different tools using HIBP API. There is even a domain search which allows companies to find if any of the accounts in their domain is part of a data breach.

Use these tools and identify weak or pwned passwords in your enterprise. Let me know if you are using any other tools to defend weak and pwned passwords in your environment.