Shadow Credentials: Abusing msDS-KeyCredentialLink for Silent AD Takeover

Most Active Directory takeover techniques still revolve around stealing a secret: a password hash, a Kerberos ticket, a cached credential. Shadow Credentials is different, and that is precisely what makes it dangerous. Instead of stealing a secret, an attacker plants one. By writing a single attribute on a target object, they mint a certificate-backed identity that Kerberos will happily trust — no password required, and no password reset will ever revoke it.

The attribute that started it all

Windows Hello for Business and passwordless logon rely on public-key credentials. When you enroll a device or key, Windows stores the public portion of that key material on the account object in an attribute called msDS-KeyCredentialLink. During logon, the Key Distribution Center (KDC) uses PKINIT — public-key initial authentication for Kerberos — to validate that the client holds the matching private key, then issues a Ticket-Granting Ticket (TGT). No password ever enters the exchange.

The problem: msDS-KeyCredentialLink is just an LDAP attribute. If you can write it on another account, you get to define a key pair you control. From that point, PKINIT will authenticate you as that account. This is the core of the attack that Elad Shamir documented in "Shadow Credentials" and that tools like Whisker and Certipy operationalized.

Why write access is more common than you think

You do not need Domain Admin to pull this off. You need write access to the target's msDS-KeyCredentialLink — which usually means one of these edges:

• GenericWrite / GenericAll / WriteProperty on the target object, granted directly or through nested group membership.
• AddKeyCredentialLink extended right, sometimes delegated far too broadly.
• Control of a computer account or service account that a delegation or ACL misconfiguration lets you pivot from.
• Chained abuse — e.g., an RBCD or AD CS path that first grants you write access, then this technique to cash it in.

BloodHound has surfaced these relationships for years. Any account with an AddKeyCredentialLink or generic-write edge to a high-value target is a Shadow Credentials waiting to happen.

What the attack looks like

The mechanics are deliberately simple. An operator generates a certificate/key pair, writes it into the victim's key credential list, then authenticates with PKINIT to recover a TGT — and often the NT hash via the U2U + PAC trick:

# Add a controlled key to the target, then authenticate as it
Certipy shadow auto -u attacker@corp.local -p 'Passw0rd!' \
    -account target-svc

# Whisker equivalent
Whisker.exe add /target:target-svc$ /domain:corp.local \
    /dc:dc01.corp.local

The result is a Kerberos TGT for target-svc and, frequently, its NT hash — recovered without ever knowing or cracking the account's password.

Resetting the victim's password does nothing. The planted key lives in a separate attribute, so the attacker's access survives every credential rotation until someone clears the key itself.

Detecting it

Shadow Credentials leaves fingerprints if you are watching the right places:

• Directory change auditing on msDS-KeyCredentialLink. Enable auditing of directory service changes and alert on writes to this attribute, especially on privileged users, computer accounts, and service accounts that do not use Windows Hello for Business.
• Event 4768 / 4769 with certificate-based pre-authentication for accounts that have no business using PKINIT.
• Baseline the attribute. Enumerate every object that currently populates msDS-KeyCredentialLink and reconcile it against your known WHfB/passwordless enrollment. Anything unexplained is suspect.

A quick inventory of populated key credentials is a healthy periodic check:

Get-ADObject -LDAPFilter '(msDS-KeyCredentialLink=*)' \
    -Properties msDS-KeyCredentialLink |
  Select-Object Name, DistinguishedName

Hardening the ACLs that enable it

Detection is the backstop; the real fix is removing the write edges attackers rely on:

1. Audit ACLs on high-value objects. Tier-0 accounts (Domain Admins, DCs, ADFS/PKI service accounts) should have no unexpected principals with generic-write or AddKeyCredentialLink.
2. Collapse over-broad delegation. Legacy "helpdesk can manage all users" ACEs are a classic source of writable key credential links.
3. Enforce strong certificate mapping. Microsoft's KB5014754 changes push toward strong, explicit certificate-to-account mapping — apply them so a planted key cannot silently impersonate a mismatched identity.
4. Protect Tier-0 with Authentication Policies / Protected Users where compatible, and monitor for any change to their key credential attribute as a high-severity event.

Where WinSentinel fits

On a single machine, WinSentinel Free gives you the full local picture: it audits the host's Kerberos and PKINIT posture, credential-exposure surface, certificate trust, and the local ACL and privilege configuration that an attacker would abuse as a foothold — all 33 modules, no limits. That is exactly the reconnaissance a defender wants on any domain-joined endpoint that could be the attacker's entry point.

For organizations, WinSentinel Pro turns this into fleet posture. The central node aggregates findings across every managed machine, rolls up Kerberos, certificate, and credential-hygiene results into compliance views, and raises drift alerts when a node's security posture regresses — so a newly weakened endpoint that becomes a viable staging point for a Shadow Credentials chain surfaces immediately instead of months later. Managing 50 or 100 domain-joined machines by hand is how these ACL edges accumulate unseen; centralized agents are how you keep them from doing so.

The takeaway

Shadow Credentials is a reminder that in Active Directory, who can write to an object is often more powerful than who knows its password. Audit the write paths to your Tier-0 accounts, watch msDS-KeyCredentialLink like the credential store it effectively is, and treat any unexplained key on a privileged account as an active incident.