Shadow credentials: understanding and controlling the msDS-KeyCredentialLink attribute
Windows Hello for Business key-based authentication introduced an Active Directory attribute that binds a public key to an account. That attribute has become a target: an attacker able to write to it can add their own key and obtain a Kerberos ticket as the victim, without touching the password. These are known as "shadow credentials".
What msDS-KeyCredentialLink is for
In the Windows Hello for Business key trust model, the device generates a key pair when the user enrols. The public key is stored in the account's msDS-KeyCredentialLink attribute, either directly or through synchronisation from Entra ID. At sign-in, the user proves possession of the private key and the domain controller issues a TGT through the Kerberos PKINIT extension.
This requires Windows Server 2016 or later domain controllers with a certificate suitable for Kerberos authentication. Computer accounts can carry keys too, notably in device registration scenarios.
How the abuse works
The attribute only holds a public key: reading it reveals nothing. The risk lies in writing. An account with write access to this attribute on a user or computer can add a key whose private part it holds, then authenticate through PKINIT as the victim. In that context the protocol can also return the account's NT hash, which opens further options.
The technique is stealthy: the victim's password does not change, the legitimate user notices nothing, and the added key can stay in place for a long time as persistence. It relies on the same weaknesses as other ACL abuses: GenericAll, GenericWrite or property write on the target object. It can also follow from an NTLM relay to LDAP if the domain controller accepts unsigned LDAP connections.
Who can write the attribute
By default, the Key Admins and Enterprise Key Admins groups have rights on this attribute, for the domain and the forest respectively. The account used by hybrid directory synchronisation also receives write access when certain features are enabled. Finally, a computer account can, under certain conditions, write its own key.
On top of these intended rights come all rights inherited from overly broad delegations: a helpdesk group with GenericWrite on a user OU can, unknowingly, attach shadow credentials to every account in it.
Even without Windows Hello. The technique works as long as domain controllers accept PKINIT, whether or not you use Windows Hello for Business. Not using the feature does not protect you.
Detection
- Inventory. List accounts with a populated
msDS-KeyCredentialLink. A key on an administrative account, a service account or a user who does not use Windows Hello is suspicious. - Consistency. Legitimate keys are tied to a registered device. A key with no matching device, or created on a date unrelated to any rollout, deserves investigation.
- Logging. Configure directory service change auditing and a SACL on the attribute so every modification generates an event. Any write by an account other than the expected ones should raise an alert.
Hardening
- Reduce write rights on sensitive accounts, starting with Tier 0 accounts and domain controllers.
- Keep Key Admins and Enterprise Key Admins empty or limited to strictly necessary accounts, and monitor them like privileged groups.
- Protect the hybrid synchronisation account as Tier 0.
- Require LDAP signing and channel binding to close the relay path.
- Clean up orphaned keys after checking with the teams responsible for devices.
What an audit checks
- privileged accounts carrying a value in
msDS-KeyCredentialLink; - holders of write rights on this attribute for sensitive objects;
- membership of the Key Admins groups;
- whether changes to the attribute are logged;
- LDAP signing and channel binding configuration.