Every Solution You Can Imagine – and More
What cybersecurity solution do you need? From Zero Trust to ADR, IAM, risk/privacy, data protection, AppSec and threat, securing digital transformation, to resiliency and remediation, we can build the right program to help solve your challenges.
A Single Partner for Everything You Need
Optiv works with more than 450 world-class security technology partners. By putting you at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can.
We Are Optiv
Greatness is every team working toward a common goal. Winning in spite of cyber threats and overcoming challenges in spite of them. It’s building for a future that only you can create or simply coming home in time for dinner.
However you define greatness, Optiv is in your corner. We manage cyber risk so you can secure your full potential.
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.
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:
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.
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.
Next, the DEMO account host is joined to the domain via the control panel.
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.
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.
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.
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.
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.
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.
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
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.
The process was repeated while running a packet capture, which revealed the domain join process with Netdom utilizes Kerberos for authentication.
Additionally, the event logs on the DC during this process reveal there were few changes when performing a self-service 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.
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.
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.
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.
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.
These issues would not have been discovered without the collaboration and support of the Attack & Pen team.
Both issues were reported to MSRC with the following timeline:
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.
June 02, 2021
Optiv highlights the attack strategy of using forged Kerberos tickets to compromise a domain, and provides ways to defend against it.
February 02, 2021
This post identifies systemic endpoint detection and response issues and examines how attackers can bypass any EDR product.
May 12, 2021
This article explores gaps that allow for the undetected execution of code on systems protected by Microsoft Defender Advanced Threat Protection.
Let us know what you need, and we will have an Optiv professional contact you shortly.