Northbridge Systems: Bypassing MAQ and Leveraging RBCD in the Hack Smarter Lab

TL;DR:

• I show how to create attacker-controlled computer accounts even when the domain is hardened with a zero Machine Account Quota (MAQ).
• I walk through setting the target OU for each computer and applying Resource-Based Constrained Delegation (RBCD) with Core Impact.
• I explain how to use Bloodhound and Bloody AD to discover delegation paths and verify GPO changes.
• I give practical scripts and command snippets you can copy-paste into your own lab.
• I discuss the common pitfalls that tripped me up during the original video series.

Why this matters When a lab sets the Machine Account Quota to zero, any non-admin user is blocked from adding new machine accounts. That looks like a security hardening, but for a red-teamer it removes a powerful foothold. I was stuck for hours trying to create a new computer account for lateral movement. The “machine quota exceeded” error kept popping up. I discovered that the automation account could still add accounts only to a specific OU – a feature that many testers overlook. Once I learned how to target that OU and use RBCD, I could pivot from the jump box to a Domain Admin account in a single chain.

Core concepts

How to apply it

1. Confirm the MAQ setting

   # Query current MAQ on the domain object
   Get-ADObject ((Get-ADDomain).distinguishedname) -Properties ms-DS-MachineAccountQuota
   

   Source: Microsoft — Machine Account Quota attribute (2020)

2. Set MAQ to 0 in the lab (if you have admin rights)

   Set-ADDomain -Identity (Get-ADDomain).distinguishedname -Replace @{ 'ms-DS-MachineAccountQuota' = 0 }
   

   Source: ProjectBlack — Set ms-DS-MachineAccountQuota to 0 (2024)

3. Pick a target OU

   • Open ADSI Edit, navigate to the domain root, and create a sub-OU named ProvTest.
   • Record the full DN: OU=ProvTest,DC=northbridge,DC=corp.

4. Add a new computer via Impact

   • Use the add computer command and specify the OU.

   impact add computer -d northbridge.corp -u ServerAutomationServiceAccount -p <pwd> -n testbox$ -o "OU=ProvTest,DC=northbridge,DC=corp"
   

   • Impact internally calls Impacket’s addcomputer.py (see Impacket — impacket-addcomputer).
   • The new computer will have a password you set with the -p flag.

5. Configure RBCD on the new computer

   • From the automation account run the rbcd command to delegate to the target server.

   impact rbcd -d northbridge.corp -u ServerAutomationServiceAccount -p <pwd> -c testbox$ -t TargetServer$
   

   • This writes to msDS-AllowedToActOnBehalfOfOtherIdentity on the target machine. Source: Medium — A Practical Guide To RBCD Exploitation (2024)

6. Verify delegation paths with Bloodhound

   • Export data: SharpHound.exe -c All -f json -o ./bloodhound.json
   • Import into Bloodhound: Open Bloodhound UI, click “Import Data”, and load the JSON.
   • Run the query:

     MATCH q=(u)-[:AllowedToAct]->(:Computer) RETURN q
     

   This shows any computer that can impersonate another. Source: Bloodhound — BloodHound (2025)

7. Enumerate the new computer’s attributes with Bloody AD

   bloodyAD --host testbox$ -d northbridge.corp -u ServerAutomationServiceAccount -p <pwd> get object testbox$ --attr msDS-AllowedToActOnBehalfOfOtherIdentity
   

   Source: Bloody AD — BloodyAD Cheatsheet (2024)

8. Leverage Kerberos service tickets

   • Use kinit or Impacket’s getTGT.py to obtain a service ticket for the target server.
   • Pass-the-ticket with pth or gsecdump to gain a session that runs as Domain Admin. Source: Microsoft — Kerberos Constrained Delegation Overview (2025)

9. Create a local admin account during provisioning

   • Impact’s add computer command can also set the userPassword attribute and add the machine account to the Domain Admins group, making it a local admin on the target.
   • Verify with Get-ADComputer -Identity testbox$ -Properties memberOf.

Pitfalls & edge cases

• Wrong account – The first time I ran the script I used the jump-box user instead of the automation account. That caused an “Access denied” on the add computer command.
• OU mismatch – If you forget to specify the full DN in the -o flag, Impact creates the computer in the default Domain Computers container, and the subsequent rbcd fails because the machine can’t be found.
• GPO permissions – The GPO that could modify MAQ requires “Modify” on the domain object. If you’re not a Domain Admin, you can’t change the quota, so the script will keep failing.
• RBCD restrictions – Some domains enforce the “Protected Users” group, which blocks RBCD even if the attribute is set.
• Service tickets – If the target server has a firewall that blocks Kerberos requests from the automation account, the kinit step will fail, and you’ll need to enable the “Allow service ticket forwarding” setting.

Quick FAQ

1. How do I set the OU when adding a computer via Impact? Use the -o flag with the full distinguished name, e.g. -o “OU=ProvTest,DC=northbridge,DC=corp”
2. Can I bypass MAQ when it’s set to zero? Not directly. The only way is to target an OU that still allows the automation account to create a machine (by virtue of delegated permissions).
3. Why is the automation account limited to 10 machine accounts? The limit comes from the default ms-DS-MachineAccountQuota of 10. Even if the account has delegated rights, it can only create up to the quota.
4. What permissions are required to modify the MAQ via GPO? You need “Modify” permission on the domain object and membership in Domain Admins or a custom group with that permission.
5. How do I use RBCD to delegate to a target computer? Set the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target computer to the SID of the machine you created, using the impact rbcd command or bloodyAD –host.
6. Why did the automation account not initially use the correct account? I mistakenly ran the script with the jump-box credentials; the automation account is the only one with the delegated rights needed.
7. Why does the script create a local admin account during provisioning? Adding the machine to Domain Admins grants it local admin rights on the target, which is essential for post-exploitation steps like privilege escalation or persistence.

Conclusion I spent hours staring at a “machine quota exceeded” error. Once I understood that the automation account could create machines in a specific OU, I could bypass the zero MAQ and unlock the full RBCD chain. If you’re new to the Hack Smarter lab, watch part one for background on the environment, then jump straight into the “Machine Account Quota” section. Red-teamer checklist:

• Verify MAQ and OU permissions early.
• Use Impact’s add computer with the -o flag.
• Configure RBCD with impact rbcd or Bloody AD.
• Map delegation paths with Bloodhound.
• Use Kerberos tickets to elevate.

Happy hunting!