How to find weak passwords in your organization’s Active Directory

Introduction

Confidentiality is a fundamental information security principle. According to ISO 27001, it is defined as ensuring that information is not made available or disclosed to unauthorized individuals, entities or processes. There are several security controls designed specifically to enforce confidentiality requirements, but one of the oldest and best known is the use of passwords.

In fact, aside from being used since ancient times by the military, passwords were adopted quite early in the world of electronic information. The first recorded case dates to the early 1960s by an operating system created at MIT. Today, the use of passwords is commonplace in most people's daily lives, either to protect personal devices such as computers and smartphones or to prevent unwanted access to corporate systems.

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

With such an ancient security control, it’s only natural to expect it has evolved to the point where passwords are a completely effective and secure practice. The hard truth is that even today, the practice of stealing passwords as a way to gain illegitimate access is one of the main techniques used by cybercriminals. Recent statistics, such as Verizon's 2020 Data Breach Investigations Report leave no space to doubt: 37% of hacking-related breaches are tied to passwords that were either stolen or used in gaining unauthorized access.

 

For instance, in a quite recent case, Nippon Telegraph & Telephone (NTT) — a Fortune 500 company — disclosed a security breach in its internal network, where cybercriminals stole data on at least 621 customers. According to NTT, crackers breached several layers of its IT infrastructure and reached an internal Active Directory (AD) to steal data, including legitimate accounts and passwords. This lead to unauthorized access to a construction information management server.

Figure 1: Diagram of the NTT breach (source: NTT)

As with other directory services, Microsoft Active Directory remains a prime target for cybercriminals, since it is used by many businesses to centralize accounts and passwords for both users and administrators. Well, there’s no point in making cybercrime any easier, so today we are going to discuss how to find weak passwords in Microsoft Active Directory.

Active Directory: Password policy versus weak passwords 

First, there is a point that needs to be clear: Active Directory indeed allows the implementation of a GPO (Group Policy Object) defining rules for password complexity, including items such as minimum number of characters, mandatory use of specials characters, uppercase and lowercase letters, maximum password age and even preventing a user from reusing previous passwords. Even so, it is still important to know how to find weak passwords, since the GPO may (for example) not have been applied to all Organizational Units (OUs). 

But this is not the only problem. Even with the implementation of a good password policy, the rules apply only to items such as size, complexity and history, which is not a guarantee of strong passwords. For example, users tend to use passwords that are easy to memorize, such as Password2020! — which, although it technically meets the rules described above, cannot be considered safe and can be easily guessed by a cybercriminal.

Finding weak passwords in Active Directory can be simpler than you think. The first step is to know what you are looking for when auditing password quality. For this example, we will look for weak, duplicate, default or even empty passwords using the DSInternals PowerShell Module, which can be downloaded for free here.

DSInternals is an extremely interesting tool for Microsoft Administrators and has specific functionality for password auditing in Active Directory. It has the ability to discover accounts that share the same passwords or that have passwords available in public databases (such as the famous HaveIBeenPwned) or in a custom dictionary that you can create yourself to include terms more closely related to your organization.

Once installed, the password audit module in DSInternals Active Directory is quite simple to use. Just follow the syntax below:

Test-PasswordQuality [-Account] <DSAccount> [-SkipDuplicatePasswordTest] [-IncludeDisabledAccounts]

 [-WeakPasswords <String[]>] [-WeakPasswordsFile <String>] [-WeakPasswordHashesFile <String>]

 [-WeakPasswordHashesSortedFile <String>] [<CommonParameters>]

The Test-PasswordQuality cmdlet receives the output from the Get-ADDBAccount and Get-ADReplAccount cmdlets, so that offline (ntds.dit) and online (DCSync) password analyses can be done. A good option to obtain a list of leaked passwords is to use the ones provided by HaveIBeenPwned, which are fully supported in DSInternals. In this case, be sure to download the list marked "NTLM (sorted by hash)".

For example, to perform an audit based on the passwords listed in the HaveIBeenPwned database, your PowerShell command should look something like this:

As a result, the following information will be presented:

Active Directory Password Quality Report

----------------------------------------

 Passwords of these accounts are stored using reversible encryption:

  CLAUDIODODT.COMclaudio

  CLAUDIODODT.COMludo

 

LM hashes of passwords of these accounts are present:

  CLAUDIODODT.COMmilla

 

These accounts have no password set:

  CLAUDIODODT.COMisabelle

  CLAUDIODODT.COMlucas

 

Passwords of these accounts have been found in the dictionary:

  CLAUDIODODT.COMAdministrator

 

These groups of accounts have the same passwords:

  Group 1:

    CLAUDIODODT.COMclaudio

    CLAUDIODODT.COMadmin.claudio

  Group 2:

    CLAUDIODODT.COMadmin

    CLAUDIODODT.COMsql_oracle

 

These computer accounts have default passwords:

  CLAUDIODODT.COMNOMAD26

  CLAUDIODODT.COMNOMAD67

 

Kerberos AES keys are missing from these accounts:

  CLAUDIODODT.COMsql_oracle

 

Kerberos pre-authentication is not required for these accounts:

  CLAUDIODODT.COMclaudio

 

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

  CLAUDIODODT.COMsql_oracle

 

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

  CLAUDIODODT.COMadmin

  CLAUDIODODT.COMAdministrator

 

Passwords of these accounts will never expire:

  CLAUDIODODT.COMadmin

  CLAUDIODODT.COMsql_oracle

 

These accounts are not required to have a password:

  CLAUDIODODT.COMisabelle

 

These accounts that require smart card authentication have a password:

  CLAUDIODODT.COMfarello

  CLAUDIODODT.COMludo

#>

There are many interesting variations that you can test with DSInternals. For example: if, in addition to the HaveIBeenPwned database, you want to use a customized list of weak passwords such as 123456, qwerty, password, Pa$$w0rd, June2020, or your company name, just use the following syntax:

Of course, once you find the weak passwords, the next step is to take the necessary actions to have them changed, but it is also important to understand why they were being used in the first place. 

For example, the password policy applied to your Active Directory may need adjustments. If you allow passwords of low complexity, it is almost certain that one of your users will choose 123456; if you implement very strict rules, some of your users will create complex passwords that are easy to remember, consequently becoming easier to discover with a dictionary attack, as we did in the examples above.

It is also important to remember that even when using strong complex passwords, there are users who tend to write down the password and “hide it” in obvious places like under the keyboard or even stuck to the monitor. Therefore, whenever possible, consider additional technical controls, such as the use of multi-factor authentication and, of course, never fail to invest in security awareness.

Concluding thoughts

The use of passwords is a common, but fundamental security control. And like any good control, its effectiveness must be periodically validated. If your company uses Active Directory, finding weak passwords is simple, free of charge and fast, so there is no excuse for it not being a routine periodically performed by your AD administrators.

Of course, you must go beyond Active Directory. Every organization should apply password good practices in all systems and services, ensuring that they are complex, strong and for individual use. A good way to ensure this is creating a corporate password policy and ensuring that the rules adopted by your organization are properly explained to users.

Passwords are one of the oldest information security controls and we’re unlikely to stop using them in the near future. Thus, if you want to prevent incidents and leaks, it is vital to address all vulnerabilities related to this issue.

 

Sources

2020 Data Breach Investigations Report, Verizon

Test-PasswordQuality, DSInternals

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

NTT Com confirms possible information leak due to unauthorized access, NTT