A Shadow Credentials attack abuses the msDS-KeyCredentialLink attribute, which stores public keys for certificate-based (PKINIT) authentication. An attacker who can write that attribute on a target account adds their own key, authenticates as the account via Kerberos PKINIT, and recovers its NT hash, a stealthy account takeover that needs no password reset. It requires the domain to support Key Trust (PKINIT, typically via AD CS). Defend by auditing write access to msDS-KeyCredentialLink and monitoring changes to it.
What shadow credentials are
Windows lets an account authenticate with a certificate instead of a password, and the trusted public keys live in the account's msDS-KeyCredentialLink attribute. If an attacker can write that attribute, they can register a key they control and then log in as the account, without touching its password. The attribute is rarely watched, which makes the technique quiet.
How the attack works
With write access to a target's msDS-KeyCredentialLink (often via GenericWrite or a delegation), the attacker adds a key with Whisker add /target:victim$, then requests a TGT via PKINIT with Rubeus asktgt /certificate:... /getcredentials, which returns the account's NT hash. From there they impersonate the account. It relies on the domain supporting PKINIT (Key Trust via AD CS). Payloads are shown for defensive testing.
How to defend against it
Audit which principals can write msDS-KeyCredentialLink on your accounts, especially tier-0, and remove unnecessary write access. Monitor changes to the attribute and alert on additions, and keep AD CS locked down since the attack depends on certificate authentication. Removing an unexpected key credential evicts the attacker.
References
- [1]MITRE ATT&CK Enterprise Matrix(MITRE ATT&CK)
- [2]Microsoft: Key Trust authentication (Windows Hello for Business)(Microsoft)
A single writable attribute can hand an attacker any account you have. Talk to a security expert about testing your key-credential exposure.