Dangerous Defaults: Add Workstations to the Domain

Welcome to a new series of blog posts entitled Dangerous Defaults. In this series of posts, I wanted to cover default settings that could lead an attacker to achieving domain access or escalating their privileges in an Active Directory domain. The first default setting I wanted to talk about is the “Add workstations to the domain” Group Policy setting.

What is This Setting?

Simply put, the “Add workstations to the domain” policy in an Active Directory (AD) domain defines which users can add machines to the AD domain. By default, this value is set to the “Authenticated Users” group which means that every domain user, including unprivileged users, can add a set number of machines to the domain. The default number any user can add is 10 machine accounts and is determined by the MachineAccountQuota (MAQ). Failure to harden the “Add workstations to the domain” Group Policy setting could allow an attacker to gain access to the AD domain and potentially elevate their privileges.

Why is This a Dangerous Default?

So now that we know what the “Add workstations to the domain” policy is, how can attackers abuse this default setting? The attack path that we use most often during our penetration tests allows an attacker to go from network access to domain access without the need for a password or NT-hash. I briefly covered this in a previous blog post, but if LDAP over TLS (LDAPS) is enabled on the domain controller and hashes can be relayed using the Impacket script ntlmrelayx, this attack is possible. Ntlmrelayx can be used to relay hashed network credentials to the LDAPS service to create a machine account if the Group Policy setting is not hardened:

Figure 1 – ntlmrealyx add computer

Since the attacker was the one to create the machine account via relaying, they will now know the password for the machine account (see the bottom of Figure 1 above). With the machine account password, the attacker now has domain access via the machine account. This access can then be used to perform additional recon, escalate their privileges, deploy malware, etc. This attack is even more impactful when combined with Kerberos delegation allowing an attacker to escalate privileges in the domain. Dirk-jan Mollema has a great write-up on this attack path.

Remediation

To mitigate the risk of the default Group Policy setting, organizations should review and adjust the setting in their Active Directory domains based on their specific security requirements and business needs. Often standard domain users do not need to add machine accounts, so we like to recommend that the policy be set to only administrative users. Additionally, the Windows Event “4741(S): A computer account was created” can be monitored and logged to help track the creation of unauthorized machine accounts.

In conclusion, while default settings may offer convenience, they should never be relied upon without consideration, especially in the realm of security. It is important to understand the implications of default settings in AD domains and, where necessary, take appropriate action to mitigate the associated risks.

We also have a related Backdoors & Breaches card for this blog post, check it out here!

Figure 2 – Backdoors & Breaches Card