Kerberos delegation has been in the spotlight for some time now and the risks behind it have been outlined in quite a few blogs and conference presentations - I particularly recommend reading https://adsecurity.org/?p=1667 and https://www.harmj0y.net/blog/redteaming/another-word-on-delegation/. For some time, it was my incorrect understanding that unconstrained delegation is a massive problem while constrained/resource-based is less destructive. That is however not the case, and the exploitation that is to follow absolutely blew my mind the first time I saw it in "action"
When a service account is set for "Use any authentication protocol" delegation, it means that the service account is allowed to delegate without being required to prove that a user authenticated to it! In normal words, just saying "I shall pass because I am the administrator, trust me!" opens the door with no questions asked and no one verifying that you are in fact the administrator. Sounds crazy, right? Let's have a walk through.
In a test environment, we have 2 machines -> A Domain Controller (DC01) and a member server (Server01). We create a test1 account, register an spn and assign it for delegation set to "Use any authentication protocol" to an ldap service running on the Domain Controller (AFAIK this delegation is directly deadly if the SPN is for LDAP or CIFS):
The user is a member only of "Domain users" with no other permissions assigned to it:
Using kekeo, we create tickets for test1 (we are logged in as the local administrator on Server01), and then request a ticket for the Domain's builtin Administrator account (without providing any credentials or what so ever):
We successfully obtained a ticket - the file "TGS_Administrator@PROD.LOCAL_ldap~dc01.prod.local@PROD.LOCAL.kirbi"
We then use mimikatz to pass the ticket and dcsync to get the NTLM hash for krbtgt:
One of the many reasons why this is also bad is because it may "hide" shadow admins in the environment - in this case that would be accounts that have control over service accounts with SPNs while at the same time not being members of any privileged groups. I often see OU admins that have been assigned limited permissions but the presence of SPN account that they can control (eg change the delegation type and reset its password) provides them them with an escalation path.
You can find these user/computer accounts by looking for "TrustedToAuthForDelegation" = True
To protect privileged accounts being abused by this, ensure that they are members of the "Protected Users" group. If that is not an option (since the group has its limitations), all accounts with privileges should be set to "This account is trusted and cannot be delegated".
This madness was pointed out recently (as a reminder) by Benjamin Delpy here.