Writing yourself the right to impersonate (RBCD)
If an attacker can edit one delegation attribute on a computer object, they can tell it to trust an account they control, then impersonate any user to that machine. Here is resource-based delegation abuse, and the fix.
One attribute on a computer object decides who is allowed to impersonate users to it. If you can write it, you decide.
What it is
Resource-based constrained delegation (RBCD) lets a resource declare which accounts may impersonate users to it, stored in the target’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute. An attacker with write access to a computer object, often via a weak ACL plus a controlled or newly created machine account, sets that attribute to an account they control, then uses Kerberos S4U to impersonate any user, including an admin, to the target. This is T1098 (account manipulation) into T1558.
Why it works
It is a single attribute write that grants impersonation, often reachable through over-broad ACLs and the default ability for users to create machine accounts.
How to detect it
Look for writes to msDS-AllowedToActOnBehalfOfOtherIdentity, machine-account creation by unusual principals, and S4U ticket requests.
The fix that holds
Tighten write access to computer objects, set MachineAccountQuota to 0, monitor and alert on changes to the delegation attribute, and protect Tier-0 assets from delegated write.
Practice it
We built an RBCD abuse scenario in GraphLattice Range so teams learn how one ACL becomes impersonation, and how to close it.