The Perils of Password Reuse

In security, it’s often the simplest things that people neglect, and it’s often these things that matter most. This is certainly evident in the case of password security. 

We often tell clients to choose a strong and unique password for critical applications, and that password security education should include a reminder of the dangers of password reuse. Nonetheless, password reuse is a persistent issue we routinely find in many environments. The allure of short-term convenience is strong among systems administrators and developers for whom work efficiency and timeliness are primary concerns. The trouble is that this convenience can often be leveraged by attackers attempting to compromise the network environment.

In the enterprise context, password reuse can quickly compromise a company’s entire network infrastructure. Depending upon the instance details, password reuse can lead to lateral movement from one system to another, vertical privilege escalation within a system, application, or Active Directory domain, or even total compromise of multiple domains. Often, multiple instances can be chained together, or with other common vulnerabilities toward the ultimate goal of gaining domain administrator privileges or accessing sensitive data. 

It bears mentioning that in the personal context, consequences of password reuse can be similarly devastating, when a password used on, say, a forum or online shopping site is used again on a banking site or for a personal email account. A breach of a single site can then provide fodder for credential stuffing attacks that can ultimately lead to multiple account takeovers or even identity theft.

What follows is a set of case studies from real penetration tests, with identifying data changed or redacted, detailing various instances of password reuse that resulted in compromise of targeted assets, and a discussion of how enterprises and individuals can mitigate the risks associated with these attacks. 

Case 1: From Zero to Local Admin to Domain Admin

Here is an example of how common Windows and Active Directory configurations can be chained with credential reuse to turn a bad situation worse. The proprietary Microsoft multicast name resolution protocol, LLMNR, is still so commonly seen in Windows environments that it is usually one of the first things pentesters look for. The multicast nature of the protocol, in combination with a lack of any sort of cryptographic signing to verify identity of the communicants, makes it excellent for spoofing attacks, and a swift means of initial credential access within a network.

As such, a usual first step is running a spoofing tool like Responder.py in the target network, which sends out responses to LLMNR requests, pretending to be machines that targets wish to authenticate to, and capturing the NetNTLMv2 authentication requests. These hash-containing requests can be cracked offline, or if SMB signing is not required on target systems (another common misconfiguration), they can be forwarded to other systems for authentication (relay attacks), in some cases rapidly expanding the initial compromise. 

The following demonstrates the use of the NetNTLMv2 relaying tool impacket-ntlmrelayx, used in concert with the previously mentioned Responder.py LLMNR response spoofing tool, to relay NetNTLMv2 hashes from a victim, in this case a Lansweeper appliance, to all systems which do not require SMB signing. On systems where the relayed user is a local administrator, the SAM database is dumped, providing NTLM hashes for additional users that can be be cracked offline, or substituted for cleartext credentials in many cases.

The jdoe_adm local user seen above was also observed to be a domain user and a member of the Domain Admins group. Because the same password was used for the local and domain instances, the captured hash above provided testers with domain administrator privileges.

Finally, with these privileges, we were able to perform a DCSync against the domain controller, dumping the user hashes for the entire Vulncorp domain:

Case 2: From Config File to Domain Admin

Plaintext passwords found within configuration files are another common avenue for gaining credentialed access. In this case, a low-level computer account credential had access to multiple SMB shared drives. During the reconnaissance of these shared drives, Scorpion Labs discovered a web.config file that contained system admin (SA) credentials to two Microsoft SQL (MS-SQL) Servers. This SA account provided full access and control to both databases. This would be bad enough, but, as it turns out, this same password was reused elsewhere, resulting in total domain compromise.

Below are the contents of the web.config file that was readable from the previous relayed computer account:

Turned out that the password used for the databases was also used for the VULNCORP\Administrator user. Below is the output from the crackmapexec tool that shows the authentication process with the domain administrator username and the compromised password. The results show successful authentication and the indication of the "Pwn3d!" reflects full control over the domain controller being queried:

Case 3: Two Domains for the Price of One

In this case, testing identified six user accounts on the Vulncorp domain that also existed on the Vulncorp-Secondary.com domain, for which testers had previously gained domain administrator privileges. Testers were able to use the NTLM hashes of these users from an NTDS dump of the Vulncorp-Secondary domain to gain access to additional resources on the Vulncorp domain. The Vulncorp domain is one-way trusted by the Vulncorp-Secondary domain, but these reused credentials allowed testers to bypass the configured trust boundary by moving from the untrusted Vulncorp-Secondary domain to Vulncorp.

The following users’ NTLM hashes, gathered from an NTDS dump of the Vulncorp-Secondary domain after gaining administrative access, were found to be valid on the Vulncorp domain as well:

How to Protect Your Organization

The short and quite obvious answer is “Don’t reuse passwords,” however the allure of convenience continues to snare many an IT professional into reusing passwords, creating close variants, or just using weak, easily guessable passwords. The best strategy to protect your organization is to take a multifaceted approach that combines enforcement mechanisms with education and tools that make it convenient for users to create more-secure passwords. On the enforcement side, there is no magic bullet, as users are sometimes quite adept at creating weak passwords that nonetheless meet password policy requirements, but there are certain helpful tools.

Standard Windows AD password history enforcement prevents users from reusing the same password on the same account, but it does not prevent users with multiple accounts from using the same password across those accounts.

Azure AD Password Protection is useful to prevent the creation of known weak or breached passwords, and can be leveraged to create custom blocklists to prevent users from using common variants of the organization or department names for their passwords. For custom applications or non-Windows environments, the “Have I Been Pwned” API can similarly be leveraged to prevent the usage of known bad passwords. Again, however, these do not prevent the reuse of passwords across multiple accounts. One tool that could potentially be used for the latter purpose is the SpecOps Password Auditor tool, which can uncover accounts with identical passwords. Likely an approach featuring some such tool for auditing combined with native policies that make it more difficult for a user to reuse passwords across accounts at differing privilege levels would be the best solution. So, the password complexity, expiry time, and history requirements could be set differently according to an account’s group membership, with groups such as Domain Admins, Server Admins, and Domain Users each possessing their own unique password requirements in descending order by stringency.

Increased intensity of password policy enforcement on its own might drive people into other insecure practices if it simply makes it harder for users to authenticate, so the other side of the coin here is making security convenient. Hands down, the best way to do this for password security is to encourage the use of password managers. These typically combine an encrypted secrets vault with random password generators, and functionality to programmatically fill username and password fields within applications (an ancillary security benefit of the latter is to mitigate certain phishing attacks that rely on tricking users with similar URLs—the password manager won’t autofill unless the URL is correct). With a password manager, a user only needs to remember their master password, which should ideally be a long passphrase, then it becomes easy to use unique and cryptographically secure passwords for all other accounts. There are many good password managers with similar functionality, some which store data in the cloud, but end-to-end encrypted, and some which store data locally.

The last piece of the puzzle is user education. Making users, and especially users with technical administrative roles, starkly aware of the perils of password reuse can amplify the effectiveness of policy and security tools. No IT tech or administrator wishes for their easily-avoidable mistake to be the cause of a breach of the entire corporate network. Armed with the knowledge of how quickly things can go from bad to catastrophic via password reuse or weak passwords, users will be less likely to engage in poor password practices.

In security, time and again we find that nothing is foolproof and that defense in depth through multiple layers of security policies, practices, and tools is the best approach to facing down an ever-evolving threat landscape. In the realm of password security, this is certainly the case. The multifaceted approach outlined here is is not a silver bullet, but, if implemented, will vastly decrease the probability of successful lateral movement, privilege escalation, and total network compromise via password reuse.