Adding a key to someone else's account (Shadow Credentials)
With write access to one attribute on a target account, an attacker can add their own key and then authenticate as that account, no password reset, no noise. Here is Shadow Credentials, and the fix.
You do not need someone’s password to become them. You just need to write one attribute on their account.
What it is
Windows Hello for Business and certificate-based authentication let an account carry public keys in the msDS-KeyCredentialLink attribute. An attacker who has write access to that attribute on a target (often via a delegated or misconfigured ACL) adds their own key credential, then uses PKINIT to request a Kerberos ticket and authenticate as the target, recovering its hash along the way. No password was reset and nothing obvious changed. This is T1098 (account manipulation) into T1649 (steal or forge certificates).
Why it works
The change is a single attribute write that looks legitimate, and a password reset does not remove the attacker’s key. It is a quiet takeover of any account whose key attribute you can write.
How to detect it
Watch for writes to msDS-KeyCredentialLink on accounts (especially privileged ones) from principals that do not manage device registration, and for PKINIT authentication shortly after.
The fix that holds
Audit and tighten who can write msDS-KeyCredentialLink (and broad ACLs generally), monitor and alert on changes to it, and protect Tier-0 accounts from delegated write. Where Windows Hello for Business is not used, watch the attribute closely. Remove attacker-added keys during response.
Practice it
We built a Shadow Credentials scenario in GraphLattice Range so teams learn to spot the attribute write and clean up injected keys.