Establishing a foothold during internal engagements has become increasingly difficult, as organizations are more aware of security threats and have taken measures to protect their systems from unauthorized access. As a pentester, this predicament challenges you to test your critical thinking skills to come up with new approaches. Back in May of 2022, Oddvar Moe published a blog detailing cases where pre-created or staged computer accounts may be configured with a default password and potentially leveraged for initial access. Researching this further revealed these types of accounts are a systemic issue observed in numerous different environments.

This article provides a high-level summary of pre-Windows 2000 machine accounts, a technical deep dive into scenarios where administrators inadvertently configure accounts with a default password, and a demonstration of how these accounts can be used to bypass restrictions to join a rogue host to a domain.

Pre-Windows 2000 Compatible Computers

In an Active Directory (AD) network, Administrators will often stage computer accounts to ensure the host is in the proper organizational unit or security group prior to joining the host(s) to the domain. If the staged computer account is configured as pre-Windows 2000 compatible, they are set with a password that matches the hostname in all lowercase. For example: HOSTNAME$:hostname.

Oddvar’s blog highlights some specifics on how these accounts could be identified and used:

Across multiple engagements, nearly every account discovered matched these details. However, accounts were observed with different UAC values and/or with logoncount values numbering in the thousands. Even more interesting, some of these hosts were still live in the clients’ network. This resulted in two questions:

Insecure Default Configuration

As mentioned previously, several accounts were observed configured with default passwords that were active on the network. This went against common understanding of computer account passwords. Typically, a machine joined to a domain would possess a randomized 120-character password that rotates every 30 days. If the account were rotating correctly, the password should have been different from the original default value. For example, one machine was running a version of Windows Server and had a logon count over 4,000, which indicated it was actively in use. The account was added in April 2015 and likely followed the default 30-day password rotation until the final password change in November 2017. The first scenario that comes to my mind with a gap in password changes this long is that this machine would likely have a broken trust relationship with the domain controller (DC). In some cases, a trust relationship breaks between a host and a DC when the machine resets its password but has lost contact with the DC and the change is not replicated. This creates a conflict between what is stored in AD for the machine’s password and what is stored on the host, ultimately breaking authentication. This suspicion was confirmed following attempts to authenticate to the identified hosts that were met with a broken trust relationship error.

Image

Figure 1: Broken Trust

At this point, researchers tested their theories of what might have happened in a lab environment—specifically, scenarios where hosts would break trusts with the domain. To set the stage, and to highlight the domain join process, the DEMO workstation does not exist in the fictitious corp.local domain.

Image

Figure 2: DEMO Account Doesn't Exist

Next, the DEMO account host is joined to the domain via the control panel.

Image

Figure 3: Domain Join

Rather than wait for the host to lose trust, the computer account was reset in Active Directory Users and Computers to simulate the broken trust relationship. Prior to resetting, the Pre2k tool was run for every host in the test environment to set a baseline. Pre2k is a tool I created that can identify pre-Windows 2000 compatible accounts. As seen in the screenshot below, none of the hosts in the domain are configured with a default password.

Image

Figure 4: Invalid Credentials

Next, the computer account for the DEMO$ host was reset to break the trust relationship and Pre2k was ran again. Following the reset, the DEMO$ account was now configured with a default password.

Image

Figure 5: Reset Account

Image

Figure 6: Valid Credential Following Reset

From a Linux operating system, the first command below was used to demonstrate a typical logon failure as the corp\demo$ machine account using an intentionally invalid password. The second command was used to identify that the account was configured with a default password.

Image

Figure 7: Authentication Errors

The error response for the second login returned a “NT_STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT” or a UAC value of 4128. This response indicates the account was configured as pre-Windows 2000 compatible. However, when the DEMO$ account was reset, the UAC value persisted as “WORKSTATION_TRUST_ACCOUNT” or a UAC value of 4096, which conflicted with the previous error response. To demonstrate this conflict, the machine account “PRE$” was created and configured as pre-Windows 2000 compatible and then compared to the DEMO$ account following the reset.

Image

Figure 8: Pre-created Computer Account

Image

Figure 9: Compared UAC Attributes

Additionally, the above rpcclient command was executed for the PRE$ account and returned the same error response as the reset DEMO$ account, confirming the reset command reverts to pre-Windows 2000 compatible.

Image

Figure 10: Duplicate Error Response

From here the domain join process was repeated using multiple methods—including PowerShell modules and command line tools—and each had the same result. By resetting the machine account, the account is configured with a default password, regardless of how the account was originally created. Since the UAC value persists through the reset, there is no identifier to associate the reset account to be configured as pre-Windows 2000 compatible. Nor is there any warning to the administrator performing this action that indicates the password is being set to a default value.

Broken Access Control

Mentioned previously, the domain join process was performed using command line tools—one of which was Netdom. Using the Netdom help menu for the join subcommand returned two interesting flags: “ReadOnly” and “PasswordM”. These flags indicated it was possible to perform a domain join using known machine account credentials.s

Image

Figure 11: Netdom ReadOnly Flag

Image

Figure 12: Netdom PasswordM Flag

To test this functionality, the DEMO account was created with pre-Windows 2000 compatibility and then Netdom was used following the help descriptions to perform the “ReadOnly” domain join, and the process was successful.

Image

Figure 13: Pre-created Demo Account

Image

Figure 14: Netdom ReadOnly Domain Join

The process was repeated while running a packet capture, which revealed the domain join process with Netdom utilizes Kerberos for authentication.

Image

Figure 15: Netdom Join Packet Capture

Additionally, the event logs on the DC during this process reveal there were few changes when performing a self-service join.

Image

Figure 16: Event Logs During Domain Join

From these events, it appears this is expected and normal activity. However, something stood out that did not make sense. When pre-creating the machine account, there is an option to specify which principal(s) have the right to join the machine to the domain. By default, this is set to the Domain Administrators group. Yet the machine account was not a member of that group and was able to perform a self-service join. So, it appeared that this ACL was not applying correctly. Furthermore, the group policy was configured to allow only members of the Domain Administrators group to join workstations to the domain. The ms-DS-MachineAccountQuota attribute was set to 0, which should prevent this from occurring.

Image

Figure 17: Default ACL

Image

Figure 18: Security Controls

To determine if the controls were applying at all, a domain join was attempted for the DEMO workstation using a low privileged user account through the control panel. That resulted in an “Access Denied” error due to the account being previously created with a different set of credentials. Additionally, a domain join was attempted using the machine account credentials that received the same error.

Image

Figure 19: Attempted Domain Join with Low Privileged User

Image

Figure 20: Attempted Domain Join with Machine Account

Image

Figure 21: Access Denied

Based on these results, a user with knowledge of an existing pre-Windows 2000 machine account can bypass deployed and expected security controls to arbitrarily join a Windows operating system to a domain by performing a “ReadOnly” domain join with Netdom. This action triggers common events that can make detection a challenge.

Conclusion

By resetting a computer account in Active Directory, administrators are unknowingly configuring the accounts with a default password. Upon disclosure to Microsoft, this issue was assigned a moderate severity rating and was scheduled to be fixed at a later date. Moreover, accounts configured in this manner can be used to bypass security controls in a hardened environment that limit the ability to perform domain join operations. In response to this disclosure, Microsoft reviewed it and closed the case.

Mitigations

At the time of writing, I am unaware of an elegant way to identify these accounts. Due to the variances in attribute values, defenders can use Pre2k to perform an authenticated scan of their environment. If accounts are discovered, then the accounts can be disabled if not in use or deleted if not needed. My conclusion is that the only identifying trait for these accounts is the password itself.

In terms of prevention, the best mitigation against exploitation of Pre-Windows 2000 authentication in general is typically considered to be the removal of Anonymous, Everyone, and Authenticated Users from the Pre-Windows 2000 Compatible Access group. That group continues to be included in deployments of new Active Directory forests, even on Windows Server 2022. Removal of Authenticated Users from the group in an existing domain may be a potential challenge in some organizations and should be thoroughly tested. Preferred practice in this context would be to only grant Pre-Windows 2000 compatibility explicitly to specific hosts or users, rather than all authenticated users.

Acknowledgments

These issues would not have been discovered without the collaboration and support of the Attack & Pen team.

Disclosure Timeline

Both issues were reported to MSRC with the following timeline: