In parts one and two we discussed how to dump password hashes from a Domain Controller and how to crack these hashes to obtain a list of clear text passwords. In this blog post, we’ll learn how to obtain useful metrics from cracked password hashes in order to determine improvements to a password policy.
pwdumpstats
While a large list of cracked password hashes can be interesting to glance through, it can be difficult to identify patterns or systemic issues with an organisation’s password policy. In order to acquire useful and actionable information then, we may need to perform some processing on the John the Ripper (John) pot file that contains the cracked password hashes.
For this purpose we have developed a python script, pwdumpstats, that is available on Dionach’s GitHub repository. pwdumpstats allows auditors and IT staff to obtain useful metrics from a pwdump.txt file (ideally one generated using NtdsAudit) and a John the Ripper pot file.
At the most basic level, pwdumpstats can be run as follows:
$ pwdumpstats.py --pot=john.pot pwdump.txt
The output will look something like this:
############## # Statistics # ############## Users: 7359 LM Hashes (current): 360 (4.89%) LM Hashes (history): 0 History hashes: 0 Total hashes: 7359 Cracked passwords: 5857 (79.59%) Non-complex passwords: 494 (6.71%) Empty passwords: 0 Duplicate passwords: 1509 (20.51%) Highest duplicate: 167 (2.27%) Top 20 passwords: 747 (10.15%) Username as password: 23 (0.31%) Total admin accounts: 99 Cracked admin passwords 68 (68.69%) Administrators: 99 Domain Admins: 61 Top 20 hashes 310 64F12CDDAA88057E06A81B54E73B949B Password1 131 30C3F921B4A69289FE7E752E0E3BAEAB Monday10 49 31D6CFE0D16AE931B73C59D7E0C089C0 [empty] 38 DA7A992199887B5652528077CDD049CC October2017 35 A4258E2B5D7D7FBB04531A89177B5E22 November2017 <...>
Weak Passwords and Password Storage
The statistics most likely to stand out immediately from the pwdumpstats results are “Cracked passwords” and “Cracked admin passwords”. These respectively describe the total number and percentage of password hashes and administrator password hashes cracked by John. In the example case above, nearly 80% of total passwords and nearly 70% of administrator passwords were cracked. This indicates a serious problem with the example organisation’s password policies or security culture, as it shows that the majority of staff, including high-privileged administrators, set weak and easily guessable passwords.
The full list of administrator accounts whose password hashes were cracked by John can be listed by running pwdumpstats with the “-A” flag. These accounts should have their passwords changed immediately, as an attacker attempting a brute force attack or obtaining an administrator password hash using a tool such as Responder will be significantly more likely to compromise the accounts and immediately gain a high level of privilege on the internal network.
“Non-complex passwords” refers to cracked password hashes that do not adhere to the default Windows password policy. This includes passwords that are shorter than eight characters and/or do not include three of the following four features: lowercase letters, uppercase letters, numbers, and special characters. If password complexity and a minimum password length of eight are enabled on the domain, this statistic will be very low.
In some cases, password complexity or length requirements cannot be set on the domain due to requirements of legacy software. If this is the case, a plan should be made to migrate away from this software, as users with the ability to set short or non-complex passwords are very likely to do so. However, even if password complexity and a minimum length of eight characters are enabled on the domain, it is possible that some users will still not conform to this policy. These are worth investigating, as they may be inactive accounts or users who have not had to reset their password in a long time. Accounts with non-complex passwords can be listed by running pwdumpstats with the “-n” flag.
Note that simply enabling password complexity on the domain is not sufficient for a robust security policy. In the example above, less than 7% of passwords were non-complex, yet nearly 70% of passwords were cracked. This is because very weak passwords such as “Password1” can still adhere to the default Windows password policy. Other measures, such as increasing the password length beyond eight characters or using password filters, will likely be required.
“Empty passwords” indicates user and service accounts that are not required to use a password when logging in. This should never be the case on a properly secured domain, and if any empty passwords are present the issue should be investigated and rectified immediately.
It is possible that legacy software may require empty passwords; however, it is more likely that empty passwords are caused by a misconfigured password reset or account creation process. Microsoft has published some guidance on removing the “PASSWD_NOTREQD” flag from affected user accounts to resolve this issue. Accounts with empty passwords can be listed by running pwdumpstats with the “-E” flag.
“LM Hashes” indicates passwords stored using Lan Manager (LM) hashing as opposed to the more modern and secure NT Lan Manager (NTLM) hashing. As mentioned in the previous blog post, LM passwords hashes are highly vulnerable to cracking. An attacker can take advantage of this issue if they capture an LM hash during an internal network attack.
If LM password hashes are discovered on the domain, it is worth investigating why this is the case (for example, if legacy software is in place) and whether the hash format can be upgraded. Microsoft has published some guidance on investigating and rectifying this configuration.
Finally, the output of NtdsAudit (though not pwdumpstats) lists an additional metric to consider: “Passwords stored using reversible encryption“. This setting should always be disabled on the domain, as it allows attackers to trivially decrypt captured encrypted passwords without any hash cracking.
Some legacy systems using authentication protocols such as HTTP Digest Authentication or CHAP may require this setting, as they will need access to clear text passwords (rather than password hashes) to function. These systems should be upgraded as a priority to allow reversible encryption to be disabled and to improve the organisation’s security.
Password Reuse
At a default level, pwdumpstats provides a “Duplicate passwords” statistic to indicate how many users on the domain are using the same password as another user. As Windows does not use salts, this can be determined by simple comparison of the password hashes, no cracking required.
The tool also provides a list of the twenty most common passwords in use on the domain. If a large number of users share a single password, it may indicate that there are problems with the account creation and/or password reset processes – for example, if staff are not required to change their password on first login, or if passwords are always reset to the same value.
A high number of duplicate passwords can aid an attacker attempting to compromise an organisation’s internal network. If an attacker is successful in cracking a hash, they will often try to use the resulting password in a password spraying attack against a large number of accounts on the domain. In the example above, the ability to crack the weak password “Password1” immediately gains the attacker access to over 300 accounts. The attacker is therefore not only able to access sensitive information belonging to hundreds of different users, but also potentially able to escalate their privileges on the domain if one of these accounts belongs to an administrator. This significantly reduces the attacker’s workload in compromising the internal network.
Running pwdumpstats with the “-s” flag provides the entire list of reused passwords and their corresponding users. This output can then be parsed for useful metrics. For example, the following command searches the pwdumpstats output for administrators (listed in the file “admins.txt”) who use the same passwords as normal users. Note that a list of administrators can be gained by running pwdumpstats with the “-a” flag.
$ while read username; do awk "NR==1,/[+]/" pwdumpstats_output.txt | awk "/$username/" RS= ; done <admins.txt
The output will look something like this:
64F12CDDAA88057E06A81B54E73B949B : Password1 [310] ... JohnSmithAdmin JohnSmith ...
This indicates that the user John Smith is using the same password (in this case, the aforementioned “Password1”) for both his standard user account and his administrator account.
Password History Hashes
One feature of NtdsAudit not discussed in part one of this series is the “–history-hashes” flag. If the tool is run with this option, the pwdump file it generates will not only contain users’ current password hashes, but also the hashes of passwords they have previous used if password history enforcement is configured on the domain.
This may not seem particularly useful at first, as attackers cannot compromise accounts with old passwords. However, examining a series of cracked history hashes provides insight into the ways that users set their passwords. For example, when required to change their password, many users will simply iterate through a pattern such as the following:
- Incrementing or decrementing a number (Password1, Password2, Password3…)
- Incrementing the month or season (January2019, February2019, March2019…)
- Appending a character (Password1, Password11, Password111…)
This reduces the security benefit of changing a password significantly, as an attacker who had previously compromised a user’s account may simply be able to identify the pattern in use and guess the new password.
John will display all cracked passwords, including historical passwords, with the following command:
$ john --show --pot=pwdump.pot --format=NT pwdump.txt | cut -d : -f 1,2 | sort
This output can be analysed and grepped for certain keywords and users. This will enable easily viewing users’ passwords over time and observing the conventions or patterns they use. For example, an auditor can search for passwords containing the word “Oxford”:
$ john --show --pot=pwdump.pot --format=NT pwdump.txt | cut -d : -f 1,2 | sort | grep Oxford
This will give a result such as the following, revealing that the user Jane Doe appends an incrementing character to her (already weak) password when asked to change it:
... organisation.local\JaneDoe:Oxford12345 organisation.local\JaneDoe_history_0:Oxford1234 organisation.local\JaneDoe_history_1:Oxford123 organisation.local\JaneDoe_history_2:Oxford12 organisation.local\JaneDoe_history_3:Oxford1 ...
Users with Weak Passwords
The full list of users whose password hashes have been cracked can be obtained with the following command:
$ john --show --pot=pwdump.pot --format=NT pwdump.txt | cut -d : -f 1 | grep -v _history_ | sort
If this list is small, users can easily be encouraged individually to change their weak passwords to more secure ones. On the other hand, if this list contains hundreds of users across a large organisation, it can be difficult to track down each individual and ensure that they are aware of the problem.
However, monitoring changes in this list over time can allow IT staff to determine which users or groups of users (for example, a particular department) consistently set weak passwords. This can potentially allow staff to target password training and other policy measures more efficiently.
Recommendations
By now you may understand a little bit more about your organization’s password culture, as well as some potential areas for improvement. Where do you go from here?
The UK National Cyber Security Centre (NCSC) provides some guidance on creating good practice password policies that work well for users and organisations. One of the most important takeaways from the guide is that many end users experience “password overload” from being forced to remember (and frequently change) large numbers of passwords. To avoid hindering their work, they may become more likely to set passwords that are weak and easily memorable – and, as a result, easily guessable.
The NCSC proposes tackling this problem in a number of ways, many of which are already well known among security-conscious system administrators. For example, encouraging the use of password managers can allow users to set long, complex passwords without writing them down in an insecure location (such as a sticky note) or forgetting them. Additionally, offering password training as part of onboarding or annual meetings and accepting feedback on ways to reduce “password overload” can go a long way toward investing end users in an organisation’s security.
Other recommendations in the guide are highly effective but perhaps slightly less well known. One suggestion is that organisations do not enforce regular password expiry policies, but instead focus on implementing strong account lockout and behaviour monitoring processes. As discussed in the “history hash” review above, frequently requiring password changes without evidence of compromise can cause users to set weaker passwords or simply revert to iterations of a base pattern. If this pattern is easily guessable, any security benefit gained by changing the password is likely negated.
NCSC also recommend relaxing password complexity requirements in favour of a much longer minimum password length. This encourages users to set long passphrases. These often have the advantage of being both difficult to guess (unlike “Password1”) and easy to remember (unlike “Ba62*k4g&I”).
The US National Institute of Standards and Technology guide, while primarily focused on web and mobile applications rather than Active Directory, carries similar recommendations. Organisations are encouraged to avoid requiring periodic password changes and implementing arbitrarily difficult password rules, such as prohibiting the consecutive repetition of characters (e.g., “aa” or “11”).
Other tactics to consider from an administrative perspective include updating account creation and password reset policies, especially if many of the discovered duplicate passwords are standard one-time passwords created by IT for new or locked-out accounts. One-time passwords should be strong and unique for each user, and they should be changed on first login as a requirement. Additionally, all service accounts – often a quick way for attackers to gain additional privileges on the domain – should be investigated to ensure that default passwords, which are often weak and publicly known, have been changed before deployment. Any accounts discovered with empty passwords, as discussed above, should be investigated and corrected.
Enforcing the use of multifactor authentication with authenticator applications, RSA tokens, or other secure mechanisms can also help to reduce the risk of users setting insecure passwords on the most critical or sensitive systems. Adding a “something you have” or “something you are” to the “something you know” of passwords can significantly increase the difficulty for attackers, who will now need to compromise at least one additional authentication factor in order to gain access to the system.
Finally, undertaking regular password auditing following the steps of the three blog posts in this series can allow IT staff to monitor organisation progress and quickly identify (and resolve) issues relating to weak passwords.
Conclusion
This blog post has discussed some ways for system administrators to gain useful and actionable metrics from cracked password hashes, as well as recommendations for effectively responding to the results of a password audit. By performing regular password auditing, an organisation can identify misconfigurations within Active Directory, locate strategic issues in IT departments, and better understand and improve their organisation’s security culture.