That’s Not How Kerberos Works…

A while back, I read an interesting blog by Oddvar Moe about Pre-created computer accounts in Active Directory. In the blog, Oddvar also describes the option to configure who can join the computer to the domain after the object is created. This sets an interesting ACL on computer accounts, allowing the principal who gets those rights to reset the computer account password via the “All extended rights” option. That sounded quite interesting, so I did some more digging into this and found there are more ACLs set when you use this option, which not only allows this principal to reset the password but also to configure Resource-Based Constrained Delegation. BloodHound was missing this ACL, and I dug into why, which I’ve written up in this short blog.

If an environment is sufficiently large (and/or old), someone at some point likely added a few systems to the domain with this option set to “Everyone” or “Authenticated Users”, allowing all users in the domain to join the computer to the domain. Whoever configured this probably did not realize this would also give everyone specific permissions on the object after it is joined to the domain. The logic to analyze this is now included in the BloodHound. py data gatherer, as well as a Pull Request for SharpHound. If this misconfiguration is present in a domain, it may give you access to servers from any user.

This makes for an easy first step in lateral movement. Along the way, I discovered more cases in which these ACEs were present, so in any larger environment, there’s a good chance that unintended users have some lingering permissions on computer objects. This post includes some queries to use in BloodHound, as well as some recommended mitigations.