Skip to main content
  • EN

MachineAccountQuota (Rise of the Unwanted Machines)

To everyone attending the Veeam Summit, have a great one! 😊 I'm sad I'm missing it but hope to be there for the next one. 

Right, back to this vulnerability.

By default, Active Directory has a setting enabled that allows a standard domain user to create up to 10 computer objects in the domain. This is due to the ‘ms-DS-MachineAccountQuota’ attribute in AD. Allowing standard users to join computer objects to the domain can be exploited by attackers to escalate privileges in a domain.

When a new computer object is added, it is by default added to the Domain Computers Security group, which then inherits the privileges that have been assigned to that group. This can then be used to interact with the domain, user objects, and other systems and services in the domain.

This can also be used as part of another compromise, KrbRelayUp, to perform privilege escalation.

 

Mitigations
- Prevent users from adding new devices to the domain by setting the `ms-DS-MachineAccountQuota` attribute in Active Directory to zero. Only those who need to, i.e., IT staff, should be able to add a new device when required.
- The Domain Computers Security group should not be a member of privileged security groups to prevent malicious actors from escalating their privileges.
- Additionally, the security group should not have write privileges to any objects in AD to prevent the gain or control of other AD objects.
- Enable LDAP signing for Domain Controllers, which also helps mitigate against KrbRelayUp. https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server

 

Monitoring
The following Event IDs should be monitored on Domain Controllers:
- 4624 - Object successfully logged on. Can be correlated with Event ID 4741.
- 4724 - Generated when an attempt is made to reset an object's password. If generated at or near the same time as Event ID 4741, a compromise has occurred.
- 4741 - Computer object created in Active Directory. If created by a 'normal' user, there is a chance a compromise has occurred.
 

Very informative @dips! I actually have a blogpost that is over 60% complete on this topic in my draft and you just made me get back to it. This will be published next Friday definitely after the summit and will be shared here as well. The good thing is that, this value can be changed via PowerShell or ADSIEDIT. But the operation requires Domain Admin privilege as well. 

Very informative @dips! I actually have a blogpost that is over 60% complete on this topic in my draft and you just made me get back to it. This will be published next Friday definitely after the summit and will be shared here as well. The good thing is that, this value can be changed via PowerShell or ADSIEDIT. But the operation requires Domain Admin privilege as well. 

I’m looking forward to that! This could be within the “checklist” during the domain deployment in future projects!

Thank you @dips for sharing your though in this matter, it is very concise and often forgotten by default.

and @Iams3le , I look forward to your posting😃.

As @Iams3le has mentioned above, this value can be changed via PowerShell or ADSI Edit. 

PowerShell being the easy option and can be done as follows:

#Get the current value

Get-ADObject -Identity ((Get-ADDomain).distinguishedname) -Properties ms-DS-MachineAccountQuota

#Set to 0

Set-ADDomain -Identity <YourDomainName> -Replace @{"ms-DS-MachineAccountQuota"="0"}

 

Comment


Terms & Conditions