Short Version for Blue Teamers:

The way I simplify (probably oversimplify) this when talking to people about it is:

There’s an Active Directory attribute called msDS-KeyCredentialLink
If an adversary or malicious insider is able to write to the attribute for a principal they want to use they can add their own self-generated key material and authenticate with that material.
Meaning, an adversary could be logging on as you or anyone in the domain, without your password, without you knowing anything about it IF they had write access to this attribute. The other note I call out explicitly on this one is that there is no need to do anything with the corporate certificate server. The adversary can create their own keypair. The attribute: The permission: Bloodhound is calling out the attack path where Olly happens to have write to the msDS-KeyCredentialLink attribute on Sally and Sally has domain admin privileges. In practice though, domain admin might not even be the goal, we might just be looking for accounts to take over. One horrible situation I think about is a rouge admin who might have these permissions by nature of creating lots of user accounts and is looking for a way to do sneaky things or access materials they shouldn’t:
How does this happen in practice though?

If your first reaction was that it should be rare for someone to just have that weird permission on it’s own, you’d be right. What usually happens in practice is that a principal will have one of: GenericAll, GenericWrite, Owns or WriteOwner permissions and with any of those, they can write the msDS-KeyCredentialLink in one or two steps. And to further drive home how this can happen in practice: if you create a user, you usually become the owner (unless you are a domain admin in which case ‘domain admins’ become the owner). So in practice if someone is creating a lot of users, and especially if they are creating privileged accounts, that user will have write permissions to the msDS-KeyCredentialLink attribute. Here’s a quick picture: The testOwner account was created by sally with net user /add testOwner P@ssw0rd123 /domain

How easily can this be abused?

Very. If the red team, or adversary is able to compromise an account that has the ability to write msDS-KeyCredentialLink on another principal they can do it with a small amount of effort. Bloodhound even provides instructions:

Simple Abuse Example:

Keep in mind, we discovered that “olly” has the ability to write the msDS-KeyCredentialLink attribute on the “sally” principal.
Download and Compile Whisker: https://github.com/eladshamir/Whisker
Run: whisker.exe add /target:sally /domain:jmpesp.xyz /dc:dc1.jmpesp.xyz /path:file.pfx /password:pass
Download and Compile Rubeus: https://github.com/GhostPack/Rubeus
Run the command provided in the output of whisker: rubeus.exe /asktgt /user:sally /certificate:file.pfx /password:"pass" /domain:jmpesp.xyz /dc:dc1.jmpesp.xyz /getcredentials /show
We now have both a TGT and the NTLM hash for Sally and can now use this principal for whatever we need. On Sally’s end, not much has changed, she just goes about her day unaware that Olly has added this credential to her Active Directory object and can leverage it for whatever he needs. As a red-teamish example just to close this out with a screenshot abusing Sally’s account: But in reality the type of things that has me most worried about this attack is the malicious insider who is just using this from time to time to access other users things undetected. // more on detections to come…