You've got a foothold on an internal engagement, a low-privilege domain user, and you run BloodHound like you always do. No unconstrained delegation. No Kerberoastable service account with a password worth cracking. No obvious ACL misconfiguration handing you GenericAll on anything useful. The shortest path query comes back empty, or comes back showing edges you've already burned. The instinct at this point is to write "no clear path to domain admin found" in your notes and move on to the next box.
That instinct skips the one check almost every default AD environment fails without anyone noticing: can your current user create a computer object.
By default, ms-DS-MachineAccountQuota is set to 10. That means any authenticated domain user, no group membership required, no delegated rights, nothing an admin explicitly granted, can join up to ten computers to the domain. Most environments never touch this setting after the domain is stood up, because nobody thinks of it as a privilege. It's treated as plumbing. But creating a computer object makes you its owner, and owning a computer object means you can write to one specific attribute on it: msDS-AllowedToActOnBehalfOfOtherIdentity. That attribute is what Resource-Based Constrained Delegation reads to decide who's allowed to impersonate other users when authenticating to that computer.
Here's the chain that default quota opens up. You create a computer account, call it whatever, you fully control its credentials because you just set them. You then find a target machine where you have write access to that same attribute, sometimes another self-created computer, sometimes an existing machine account with an ACL misconfiguration nobody caught, and you set the target's msDS-AllowedToActOnBehalfOfOtherIdentity to trust your computer account. From there it's a standard Kerberos S4U flow: S4U2Self gets your controlled account a service ticket "as" any user you want, including a domain admin, and S4U2Proxy redeems that ticket against the target machine, because the RBCD trust you just configured says your account is allowed to act on that user's behalf for that specific service. You end up holding a valid service ticket to the target as a domain admin, with SYSTEM on the box as the practical result.
Nothing in that chain required existing delegation rights, a crackable password, or a misconfigured ACL someone forgot to lock down. It required a default quota setting that ships enabled and a target you can write to. That's why RBCD abuse (research first published by Elad Shamir in 2019) keeps showing up in real assessments years later: it doesn't depend on a mistake, it depends on a default nobody revisited.
This is also exactly where the free path stops and the deeper one starts. Enumeration with BloodHound, credential dumping with Mimikatz, mapping trust and group membership, that gets you to the point where you can see the graph. Reading the graph for RBCD, Shadow Credentials, and AD CS template abuse (ESC1 through ESC8), plus how the same trust logic extends into hybrid Entra ID environments, is a different skill entirely, and it's the one that actually separates "I ran BloodHound" from "I found the path BloodHound didn't draw for me."
Codelivly's Advanced Active Directory Attacks Book: Red Team L2 picks up exactly there, past Mimikatz and credential dumping, into Kerberos delegation abuse, AD CS, and Entra ID attacks that a clean BloodHound query alone won't hand you.
Top comments (0)