Why You Should Implement a Banned Password List

During a recent engagement I got hold of a juicy ntds.dit file from a domain controller backup. This file contains all password hashes of the domain. For obvious reasons we stay away from dumping hashes and doing analysis on them. But since the company has employees around the globe and is fairly large, I could not resist and ask the customer for permission to analyze the hashes. Luckily they agreed and here is the reason why you should implement a banned password list.

Premise

Cleaning Up

The original ntds.dit contains roughly 8500 user accounts. Since this also includes disabled and service accounts I built a small filter solution to get two groups. One includes all enabled user accounts the other only accounts belonging to an actual employee.

Group	Accounts	Unique Hashes
All enabled	6058	4924
All enabled employee only	3450	3208

As you can see from these numbers it looks like that employee accounts mostly have a unique password. But if we include the service accounts a lot share the same password.

The Password Policy

As you can see the password policy is fairly secure. With a length requirement of 10 characters it is mostly stricter than what we usually encounter.

Important to understand is, that “Complexity” in a Windows environment is fulfilled when 3 out of 4 of the following characters groups are used.

• Latin uppercase letters (A through Z)
• Latin lowercase letters (a through z)
• Base 10 digits (0 through 9)
• Non-alphanumeric characters such as: exclamation point (!), dollar sign ($), number sign (#), or percent (%).

So Password123 would happily fit the password policy. But nobody would choose this password right?!

Analysis

To crack the NTLM hashes I choose a combination of wordlists and rulesets mainly. This approach was chosen since I was mostly interested in the easy to crack passwords.

Group	Cracked Unique Hashes	Cracked Accounts	% of accounts in group
All enabled	2129	2787	46%
All enabled employee only	1758	1954	57%

Passwords in Wordlists

Out of the 4924 unique hashes 395 could be recovered by looking it up directly from a wordlist without any mutation. This is roughly ~6% of all enabled accounts that have a known bad password set.

Top 5 Cracked Employee Passwords

In the list below are the mostly chosen employees passwords. “Company” is a place holder for the company name that, for obvious reasons, has been redacted.

Occurrence	Password
77	Company2022
22	Company2021
12	abcd_12345
12	20Company22
6	Company@2022

As you can see most of the passwords include the company name plus a year in some form. In fact, if I check all enabled accounts, there are 609 accounts that include the company name in their password. This is approximately ~10% of all enabled accounts.

Passwords Not Cohering to the Password Policy

Just for fun I wanted to know how good the password policy is enforced. For that I tried to write a regex pattern, which was no fun at all 🙊.

Anyway, around 247 enabled accounts have a password set which does not cohere to the password policy. So that’s another ~4%.

tl;dr

• Out of all unique hashes (4924) it was possible to crack ~46% with wordlists and rulesets.
• 6% of the accounts have a password which occur in public wordlists.
• 10% of the accounts have a password which includes the company name.
• 4% of the accounts have a password that does not cohere to the password policy.

That’s ~20% of accounts that an attacker might be able to take over with a simple password spraying attack.

How to do Better?

I highly recommend that you implement a banned password list in your organization. In my opinion it will add more to the overall password quality than forcing your users to have even longer passwords.

If you are a Microsoft Azure AD customer and happen to have a P1 or P2 license, you might want to implement Azure Active Directory Password Protection.

Additionally to a global banned password list, managed by Microsoft, you can specify a custom banned passwords list. Microsoft recommends to add following words to the list:

• Brand names
• Product names
• Locations, such as company headquarters
• Company-specific internal terms
• Abbreviations that have specific company meaning.

You might also want to add some of the current years to the list.

For non Microsoft Azure AD customers there are also other commercially available products on the market.