Exploiting the Active Directory Machine Account Quota (MAQ): RBCD, Privilege Escalation, and Backdoor Account Creation

Background

In an Active Directory (AD) domain, there are computer objects. When joined to a domain, computers become AD objects and have their very own "machine account" just as a user would have an AD account. Computer accounts are similar to user accounts, however there are some key differences in how they are implemented within the environment.

When changing a target environment in any capacity, it is critical to ensure the attackers have operational security (OPSEC) when conducting the techniques discussed in this article. In this instance, OPSEC is primarily going to be concerned with setting the password of the AD machine account created. It is critical to ensure a randomized and secure password is set for the machine account created.

The Machine Account Quota (MAQ)

The Machine Account Quota (MAQ) (ms-DS-MachineAccountQuota) is an Active Directory configuration value represented as an integer that determines the number of machine accounts an individual user can create within the domain. A user would need to create a machine account when adding a new device that they will use to access Active Directory resources. Threat Actors commonly take advantage of a non-zero MAQ to perform delegation attacks or create backdoor accounts within the domain. Microsoft has published some information about this configuration within a security context here.

Enumerating the MAQ

The MAQ value can be accessed through an LDAP query, so it is simple to obtain and is non-intrusive. A variety of common tools have the ability to request the domain's MAQ.

netexec can enumerate the MAQ from any authenticated user within the domain using the following command. If the value is greater than 0, ideally the default 10, then these attacks will work against the domain.

ldapdomaindump can enumerate information about the domain in HTML, greppable, and JSON format. This information includes the MAQ by default. The HTML output provides a nice screenshot for reporting purposes.

Attack Example - Resource Based Constrained Delegation

One of the most prevalent attack techniques involving an attacker-controlled machine account is Resource-Based Constrained Delegation (RBCD). This method exploits vulnerabilities in Active Directory (AD) configurations by leveraging unusual permissions on machine accounts. Specifically, RBCD attackers exploit scenarios where an AD object has inappropriate or unintended write permissions on a machine account, enabling them to modify delegation settings. This typically involves configuring delegation rights that allow an attacker-controlled object to impersonate or interact with a vulnerable object, ultimately facilitating unauthorized access. The ability to impersonate a user then typically leads to administrative access to the remote host.

The primary goal of Resource-Based Constrained Delegation (RBCD) is to gain access to a remote host by manipulating delegation permissions of an attacker-controlled resource for a specific Service Principal Name (SPN). In most cases, the Common Internet File System (CIFS) service is the target of choice. By targeting CIFS, attackers can gain access to the C drive of the remote system, enabling them to abuse administrative privileges. This exploitation path often leads to full compromise of the host, as administrative permissions provide the attacker with extensive control over the system.

1. Create or Use a Machine Account

The MS-DS-Machine-Account-Quota attribute must be greater than 0 for this attack to work. To perform this attack, there must be an attacker-controlled machine account. Let's use the Impacket 'Add Computer' script to add the computer.

2. Confirm the Machine Account's Access to the DC

3. Modify the Delegation Permissions of the new Machine Account

The target object must be configured with the permissions of the initially compromised identity (like a user account) so the attacker-controlled computer can be delegated to it. Impacket can be used to perform this, but other tools like Certipy have built-in utilities to perform this type of RBCD.

4. Create an Arbitrary Service Ticket

A service ticket for the desired SPN on the remote host can then be crafted using the attacker-controlled machine account.

5. Export the Ticket and Use it

The Kerberos CCache file is then exported as an environment variable within the shell session and used in a variety of supported tooling.

Attack Example - Obtain new Privileges

If the Domain Computers group has specialized permissions beyond the default provided by AD, then creating a machine account would grant an attacker those permissions. This would be unusual, however system administrators will add unusual permissions to AD objects on occasion when configuring software or new permissions within the domain.

An example of this might be some specialized permission that could come from particular pieces of software with unique AD requirements that permit particular access to AD resources. In this example, the Domain Computers group has local administrator permissions on a particular remote host.

1. Create or Use a Machine Account

The MS-DS-Machine-Account-Quota attribute must be greater than 0 for this attack to work. To perform this attack, there must be an attacker-controlled machine account.

2. Use the Account to Exploit the Special Permissions

The screenshot below demonstrates that machine accounts have administrative access to the target01.d33r.local host. These privileges can be abused to obtain adminsitrative access to the host and compromise cached credentials in memory.

Attack Example - Create a Backdoor Account

Occasionally during penetration tests, an account that was previously compromised may be burned for a variety of reasons. By creating a new machine account, persistence can be obtained within the environment. While this machine account typically might have less privileges than the initially compromised user account, some access is better than no access in the event the originally compromised user account is burned.

1. Create or use a machine account

As stated previously, the MS-DS-Machine-Account-Quota attribute must be greater than 0 for this attack to work.

2. Confirm the Machine Account's Access to the DC

To confirm the account was successfully created and can be used within the domain, a simple SMB share listing with netexec can be performed.

Additionally, the screenshot below demonstrates the new PENTEST$ machine account created and listed in "Active Directory Users and Computers." For OPSEC purposes, it is best to follow the schema of the existing computers within the network to avoid detection. The schema can be enumerated through Domain Computer LDAP queries or similar methods.

3. Use the Account

The newly created account can be used to access any AD resource it has permissions to use. Attacks like Kerberoasting, AS-REP Roasting, legacy Group Policy Preferences (GPP) Password access, or other common AD lateral movement and privilege escalation techniques can be performed.

Recommendations

To mitigate the risks associated with the Machine Account Quota (MAQ) attribute and the attacks detailed in this post, it is recommended to set the MAQ to 0. This ensures that only Domain Administrators can join machines to the domain, preventing unauthorized users from creating machine accounts for exploitation. It is also possible to create a special group of users that can add machines to the domain beyond the Domain Administrators such as "help desk" to mitigate this issue. Microsoft has published some information on this topic here.

Steps to Set MAQ to 0 in Active Directory Service Interface (ADSI) Edit

• 1. Open ADSI Edit.
• 2. Connect to the Domain Controller (DC).
• 3. Right-click on the domain Organization Unit (OU) bar on the left hand side and select Properties.
• 4. Find the ms-DS-MachineAccountQuota value and set it to the desired value.

Once the MAQ has been set to 0 the impacket-addcomputer tool fails due to the MAQ value exceeded.
 

Conclusion

The MAQ is a surprisingly significant Active Directory feature that can make-or-break an assessment. The ability to create additional machine accounts is a powerful permission that creates multiple opportunities for an adversary to exploit. From backdoor accounts to RBCD, there are many opportunities to expand or persist access within an AD domain.