MachineAccountQuota

Theory

MachineAccountQuota (MAQ) is a domain level attribute that by default permits unprivileged users to attach up to 10 computers to an Active Directory (AD) domain (source)

Practice

There are multiple ways attackers can leverage that power.

Force client authentications, relay those authentications to domain controllers using LDAPS, and take advantage of authenticated sessions to create a domain computer account. This account can then be used as a foothold on the AD domain to operate authenticated recon (i.e. with BloodHound for example)
Create a computer account and use it for Kerberos RBCD attacks when leveraging owned accounts with sufficient permissions (i.e. ACEs like GenericAll, GenericWrite or WriteProperty) against a target machine
Create a computer account and use it for a Kerberos Unconstrained Delegation attack when leveraging owned accounts with sufficient permissions (i.e. the SeEnableDelegationPrivilege user right)
Profit from special rights that members of the Domain Computers group could inherit
Profit from special rights that could automatically be applied to new domain computers based on their account name

Check the value

The MachineAccountQuota module (for NetExec) can be used to check the value of the MachineAccountQuota attribute.

netexec ldap $DOMAIN_CONTROLLER -d $DOMAIN -u $USER -p $PASSWORD -M maq

Alternatively, it can be done manually with the following Python code.

import ldap3

target_dn = "DC=domain,DC=local" # change this
domain = "domain" # change this
username = "username" # change this
password = "password" # change this

user = "{}\\{}".format(domain, username)
server = ldap3.Server(domain)
connection = ldap3.Connection(server = server, user = user, password = password, authentication = ldap3.NTLM)
connection.bind()
connection.search(target_dn,"(objectClass=*)", attributes=['ms-DS-MachineAccountQuota'])
print(connection.entries[0])

In order to run the following commands and tools as other users, testers can check the user impersonation part.

The following command, using the PowerShell ActiveDirectory module's cmdlets Get-ADDomain and Get-ADObject, will help testers make sure the controlled domain user can create computer accounts (the MachineAccountQuota domain-level attribute needs to be set higher than 0. It is set to 10 by default).

Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

Create a computer account

The Impacket script addcomputer (Python) can be used to create a computer account, using the credentials of a domain user the the MachineAccountQuota domain-level attribute is set higher than 0 (10 by default).

addcomputer.py -computer-name 'SHUTDOWN$' -computer-pass 'SomePassword' -dc-host $DomainController -domain-netbios $DOMAIN 'DOMAIN\anonymous:anonymous'

Testers can also use ntlmrelayx instead with the --add-computer option, like this

When using Impacket's addcomputer script for the creation of a computer account, the "SAMR" method is used by default (instead of the LDAPS one). At the time of writing (10th of December, 2021), the SAMR method creates the account without SPNs.

The Powermad module (PowerShell) can be used to create a domain computer account.

$password = ConvertTo-SecureString 'SomePassword' -AsPlainText -Force
New-MachineAccount -MachineAccount 'PENTEST01' -Password $($password) -Verbose

While the machine account can only be deleted by doman administrators, it can be deactivated by the creator account with the following command using the Powermad module.

Disable-MachineAccount -MachineAccount 'PENTEST01' -Verbose

Testers need to be aware that the MAQ attribute set to a non-zero value doesn't necessarily mean the users can create machine accounts. The right to add workstations to a domain can in fact be changed in the Group Policies. Group Policy Management Console (gpmc.msc) > Domain Controllers OU > Domain Controllers Policy > Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assigments > Add workstations to domain

Resources

Last updated 1 year ago

Was this helpful?

Practice

There are multiple ways attackers can leverage that power.

Force client authentications, relay those authentications to domain controllers using LDAPS, and take advantage of authenticated sessions to create a domain computer account. This account can then be used as a foothold on the AD domain to operate authenticated recon (i.e. with BloodHound for example)

Create a computer account and use it for Kerberos RBCD attacks when leveraging owned accounts with sufficient permissions (i.e. ACEs like GenericAll, GenericWrite or WriteProperty) against a target machine

Create a computer account and use it for a Kerberos Unconstrained Delegation attack when leveraging owned accounts with sufficient permissions (i.e. the SeEnableDelegationPrivilege user right)

Profit from special rights that members of the Domain Computers group could inherit

Profit from special rights that could automatically be applied to new domain computers based on their account name