Diving Deeper Into Pre-created Computer Accounts

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:

 

  1. The account will have a user account control (UAC) attribute of 4128
  2. The account will have a logoncount attribute value of 0
  3. The account can be used for authentication following a password change or via Kerberos without a password change.

 

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:

 

  1. Why are these accounts behaving as pre-Windows 2000 compatible machines, but they are live on the network?
  2. Why are they valid for Kerberos authentication without a password change?

 

 

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.

 

Figure 1 - Broken Trust.png

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.

 

Figure 2 - DEMO Account Doesn't Exist.png

Figure 2: DEMO Account Doesn't Exist

 

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

 

Figure 3 - Domain Join.png

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.

 

Figure 4 - Invalid Credentials.png

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.

 

Figure 5 - Reset Account.png

Figure 5: Reset Account

 

Figure 6 - Valid Credential Following Reset.png

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.

 

Figure 7 - Authentication Errors.png

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.

 

Figure 8 - Pre-created Computer Account.png

Figure 8: Pre-created Computer Account

 

Figure 9 -Compared UAC Attributes.png

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.

 

Figure 10 - Duplicate Error Response.png

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

 

Figure 11 - Netdom ReadOnly Flag.png

Figure 11: Netdom ReadOnly Flag

 

Figure 12 - Netdom PasswordM Flag.png

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.

 

Figure 13 - Pre-Created Demo Account.png

Figure 13: Pre-created Demo Account

 

Figure 14 - Netdom ReadOnly Domain Join.png

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.

 

Figure 15 - Netdom Join Packet Capture.png

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.

 

  1. Kerberos authentication
  2. Computer password reset
  3. Computer service principal names added
  4. Computer UAC updated from 4128 to 4096

 

Figure 16 - Event Los During Domain Join.png

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.

 

Figure 17 - Default ACL.png

Figure 17: Default ACL

 

Figure 18 - Security Controls.png

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.

 

Figure 19 - Attempted Domain Join with Low Privileged User.png

Figure 19: Attempted Domain Join with Low Privileged User

 

Figure 20 - Attempted Join with Machine Account.png

Figure 20: Attempted Domain Join with Machine Account

 

Figure 21 - Access Denied.png

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:

 

  1. October 27, 2022 – Reported to MSRC
  2. October 28, 2022 – Acknowledged by MSRC
  3. November 30, 2022 – Disclosure #1: Vulnerability report assigned moderate severity
  4. December 29, 2022 – Disclosure #2: Vulnerability report was closed by MSRC
Garrett Foster
By:
Garrett Foster
Security Consultant Threat Management Team | Optiv
Garrett Foster is a Security Consultant in Optiv’s Threat Management Team (Attack and Penetration specialization) with three years of industry experience. His primary roles include execution of perimeter and internal network penetration tests.

Optiv Security: Secure greatness.®

Optiv is the cyber advisory and solutions leader, delivering strategic and technical expertise to nearly 6,000 companies across every major industry. We partner with organizations to advise, deploy and operate complete cybersecurity programs from strategy and managed security services to risk, integration and technology solutions. With clients at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can. At Optiv, we manage cyber risk so you can secure your full potential. For more information, visit www.optiv.com.

Related Insights

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.