Shadow Credentials and msDS-KeyCredentialLink Abuse

What Are Shadow Credentials?

Shadow credentials is the community name for an Active Directory attack path that abuses key-based authentication material on an account, usually through the msDS-KeyCredentialLink attribute. The important point is not the name. The important point is that a principal can be given an additional public-key authentication path that is separate from its password.

In a legitimate deployment, msDS-KeyCredentialLink is used by Windows Hello for Business and related key trust scenarios. Microsoft documents that, in some hybrid Windows Hello for Business deployments, the user's public key is synchronized from Microsoft Entra ID into Active Directory and written to the msDS-KeyCredentialLink attribute on the user object. Microsoft also documents Key Trust behavior for Kerberos PKINIT: a KDC that uses Active Directory as its account database must confirm that the account has the same public key in msDS-KeyCredentialLink.

A shadow credentials abuse case exists when an attacker or unauthorized administrator can add or preserve an unexpected key credential on a user or computer object, then use the corresponding private key to authenticate as that account through a key-based flow. This is not password spraying, Kerberoasting, DCSync, or a Golden Ticket. It is closer to an ACL-backed persistence and impersonation path: the account's directory object has been modified so that a different key can satisfy authentication checks.

This article uses the term Shadow Credentials because it is widely recognized by Active Directory defenders and assessors. Microsoft documentation usually discusses the underlying mechanisms as Windows Hello for Business, Key Trust, PKINIT, and msDS-KeyCredentialLink. That distinction matters: the attribute itself is not malicious. A non-null msDS-KeyCredentialLink value can be normal in environments that use Windows Hello for Business, FIDO-related flows, or key trust features. The defensive goal is to identify unauthorized, orphaned, unexpected, or privileged-account key credentials, not to delete every value blindly.

For broader identity attack-path context, see Active Directory Attack Paths to Domain Admin and ACL Abuse and DCSync: The Silent Paths to Domain Admin. Shadow credentials belong in the same family of issues because the root problem is often excessive write capability over an identity object.

How msDS-KeyCredentialLink Works

Legitimate key credential storage

msDS-KeyCredentialLink stores key credential data on an Active Directory object. Microsoft Open Specifications describe KEYCREDENTIALLINK_BLOB as the structure stored in the binary portion of the msDS-KeyCredentialLink DN-Binary attribute. Microsoft also documents constraints for adding values on computer objects, including that the binary portion must be a well-formed KEYCREDENTIALLINK_BLOB, that the usage is KEY_USAGE_NGC, and that the source is KEY_SOURCE_AD for that documented computer-account operation.

That computer-object specification should not be overgeneralized to every user-object scenario. For user objects, the clearest operational source is the Windows Hello for Business documentation: after a user provisions a Windows Hello for Business credential in certain hybrid environments, the user's public key can be synchronized into AD and written to msDS-KeyCredentialLink. Microsoft support guidance also provides a script to enumerate user objects with non-null msDS-KeyCredentialLink values and extract fields such as Source, Usage, DeviceID, and KeyID.

Key trust authentication path

The authentication side is based on public-key cryptography. RFC 4556 defines PKINIT as public key cryptography for the initial Kerberos authentication exchange. Microsoft's PKCA documentation describes how Windows implements PKINIT and Key Trust. In a Key Trust case, the KDC can look up an account by public key, and implementations using Active Directory must confirm that the same public key is present in msDS-KeyCredentialLink.

In practical defensive language, the attribute gives AD a way to associate an account with key material that can be used for authentication. The private key should remain protected on the legitimate device or credential container. The public key is what AD can use to validate that the authentication attempt corresponds to an expected key. If an unauthorized key is added to a high-value account, the account has gained an additional authentication path that defenders may not notice during normal password reviews.

Password resets are not enough

This is why Shadow Credentials are different from password-based compromise. A password reset addresses a stolen password. It does not necessarily remove an unauthorized key credential value from the account. Microsoft documents that Windows Hello for Business sign-in and unlock use a key or certificate, and that changing a user account password does not affect that sign-in or unlock behavior. For incident response, that means password rotation can be necessary but insufficient if the account object itself still contains unauthorized key material.

Why Key Trust Changes the Attack Model

Traditional Active Directory hardening often focuses on passwords, NTLM exposure, Kerberos service tickets, and privileged group membership. Those topics remain important, but key trust introduces a different question: who can modify the account object or the key material associated with the account?

If a user or service has effective permission to write msDS-KeyCredentialLink, or can change the object's DACL or owner to obtain that write capability, the risk is no longer just account login. It becomes identity object control. Windows Event 4662 highlights Write Property, WRITE_DAC, and WRITE_OWNER as access types that are important to monitor on AD objects. Those rights are not automatically malicious, but on privileged users, service accounts, domain controllers, or administration OUs, they deserve much more scrutiny.

This is also why Shadow Credentials are an attack-path issue. The starting point might be a delegated helpdesk group, a service account with broad object rights, an inherited permission on an OU, or a stale administrative delegation. The end state can be a persistent authentication path against a privileged account. If the defender only reviews group membership, they can miss the object-level permission that made the path possible. Group nesting can also hide who effectively receives delegated control, so review Dangerous Group Nesting: Hidden Paths to Domain Admin when inherited permissions are involved.

Compare this with Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse. Delegation abuse depends on delegation settings and service identity relationships. Shadow credentials depend on key material and object write control. Both are Kerberos-adjacent, but they are not the same failure mode and should not be collapsed into one generic Kerberos article.

Preconditions for Abuse

A Shadow Credentials scenario generally requires all of these conditions:

Condition	Defensive meaning
A target account supports a relevant key-based authentication path	The environment uses or accepts key trust, certificate-backed authentication, or Windows Hello for Business patterns that rely on public-key validation.
An unauthorized principal can add or preserve key credential material	The dangerous permission may be direct write access to the attribute or broader object control that can lead to that write access.
The attacker controls the corresponding private key	AD stores the public side. Authentication succeeds only if the client can prove possession of the corresponding private key.
The activity is not detected or remediated	The value remains on the object and can survive password-only cleanup.

What is not a vulnerability by itself

These preconditions should be read carefully. The presence of Windows Hello for Business does not mean the environment is vulnerable by itself. The presence of msDS-KeyCredentialLink does not mean compromise by itself. The risk appears when account-object permissions, key credential inventory, and authentication telemetry show that an unexpected key credential was added or is being used.

Computer object caveat

Computer objects deserve a separate caveat. Microsoft documents domain-joined device public key authentication and explains that modern Windows devices can provision a bound public key for their computer account when supported by a Windows Server 2016 or later domain controller. That means defenders should expect legitimate key material on some computer accounts. The control is not "zero key credentials everywhere." The control is accurate ownership, expected device mapping, and restricted write capability.

Privileged account caveat

Privileged accounts deserve a stricter standard. Microsoft Windows Hello for Business dual enrollment guidance discusses Key Admins permissions on msDS-KeyCredentialLink and notes AdminSDHolder behavior for protected privileged users and groups. That is a strong signal for defenders: any workflow that intentionally enables key-based sign-in for privileged credentials must be documented, scoped, and monitored, because it touches the same control surface that attackers would abuse.

The Attack Chain

A safe defensive attack-chain model looks like this:

Stage	What happens	What defenders should verify
1. Permission discovery	The attacker identifies an account or OU where they can affect the target object's attributes or security descriptor.	Review effective permissions on high-value users, computer accounts, service accounts, and admin OUs.
2. Key credential addition	An unexpected key credential value is added to `msDS-KeyCredentialLink`.	Monitor Event 5136 for the LDAP display name `msDS-KeyCredentialLink`, especially `Value Added` operations.
3. Key-based authentication	The attacker attempts authentication with the private key corresponding to the added public key.	Correlate 4768 events, PKINIT or smart-card-like pre-authentication patterns, source hosts, and account sensitivity.
4. Lateral movement or persistence	The account is used for access, privilege escalation, or persistence while password rotation alone may not remove the key path.	Remove unauthorized key credentials, fix object permissions, and validate no further key-based authentication occurs.

The article intentionally does not provide tool-specific exploitation commands. Defenders do not need a copy-paste exploit path to understand the control failure. The key point is that a directory-object modification can create an authentication path that normal password hygiene does not remove.

This attack chain also explains why Shadow Credentials often sit next to other AD risks. A stale privileged account, a dangerous inherited ACL, or a weak delegation model can create the conditions for the key credential write. For related account exposure, see Stale Privileged Accounts: Hidden Risk in Active Directory. For Kerberos persistence context, compare the different mechanics in Golden Ticket Attack: The Keys to Your Kingdom.

Detection

Shadow Credentials detection should be correlation-based. No single Windows event proves the full technique. A useful detection combines directory modification evidence, object permission context, authentication behavior, and legitimate Windows Hello for Business inventory.

Signal	Source	What it can prove	Limitation
`msDS-KeyCredentialLink` value added or changed	Event 5136, Directory Service Changes	The object attribute changed, and the event can expose LDAP display name, operation type, object DN, and correlation ID.	It does not prove the change is malicious. WHfB enrollment or device flows can be legitimate.
Write access to sensitive objects	Event 4662, SACL on AD objects	A principal performed or attempted operations such as `Write Property`, `WRITE_DAC`, or `WRITE_OWNER` on monitored objects or properties.	Requires correct auditing and SACL coverage. Without SACLs, evidence may be absent.
TGT request with public-key style pre-authentication	Event 4768 on domain controllers	A TGT was requested; the event exposes pre-authentication type and certificate-related fields for relevant scenarios.	It is authentication telemetry, not proof that a malicious key was added. Correlate with 5136/4662 and account context.
Non-null key credential inventory	AD query or Microsoft support-style parsing	Which users have `msDS-KeyCredentialLink` values and what fields such as source, usage, DeviceID, and KeyID show.	Inventory must be compared against known WHfB/FIDO/device enrollment records.
Unexpected effective permissions	AD ACL review	Which users, groups, or services can write the attribute or change object security.	Permission findings are exposure, not evidence of exploitation.

Directory modification telemetry

For 5136, Microsoft recommends monitoring the LDAP Display Name field when tracking modifications to a specific AD attribute. For this topic, the relevant display name is msDS-KeyCredentialLink. Prioritize Value Added events, then correlate by object DN, account performing the change, source workstation where available, and nearby directory operations with the same correlation ID.

For 4662, prioritize high-value users, privileged groups, admin OUs, service accounts, and computer objects that represent sensitive infrastructure. Microsoft highlights access types such as Write Property, WRITE_DAC, and WRITE_OWNER as important to monitor. For a Shadow Credentials hunt, these are especially relevant when they involve a privileged identity object or a property GUID mapped to msDS-KeyCredentialLink.

Authentication correlation

For 4768, treat the event as authentication context. Microsoft documents that 4768 is generated when the KDC issues a TGT and that the event includes a Pre-Authentication Type field. Types associated with smart-card or public-key authentication can help identify key-based authentication patterns, but they must be correlated with directory changes and expected login behavior. If a privileged account suddenly shows key-based authentication after an unexpected attribute modification, the combined story is much stronger than either event alone.

Inventory questions

A practical hunt should answer these questions:

Which privileged users, service accounts, and computer accounts have non-null msDS-KeyCredentialLink values?
Are the values expected for a documented Windows Hello for Business, FIDO, or device authentication deployment?
Does each entry map to a known device, expected user, expected KeyID, and expected source?
Who can write the attribute or change the object's DACL or owner?
Were any key credential values added shortly before unusual Kerberos authentication or administrative activity?

For broader event coverage, use Active Directory Monitoring: Security Event IDs That Matter as a companion checklist, but keep the Shadow Credentials correlation specific. Generic Kerberos monitoring is not enough.

Remediation

Remediation should be targeted. Blindly clearing msDS-KeyCredentialLink across the domain can break legitimate Windows Hello for Business or device authentication scenarios. The safer approach is to validate ownership, remove unauthorized values, and fix the permissions that allowed the value to appear.

Inventory and triage

Start with inventory. Enumerate users and computers with non-null msDS-KeyCredentialLink, then parse values into fields such as Source, Usage, DeviceID, and KeyID where possible. Microsoft support guidance shows this type of analysis for user objects and explains that the matching certificate should be found in the user's personal certificate store on the computer with the matching device identifier. In a managed environment, that inventory should also be compared against Microsoft Entra device records, Windows Hello for Business enrollment records, and your privileged access process.

Then separate expected from unexpected. Expected values should map to known users, devices, and authentication designs. Unexpected values include entries on accounts that should not use key-based authentication, entries that do not map to an approved device, entries added by an unapproved principal, entries appearing after suspicious administrative activity, or values found on privileged accounts without a documented dual-enrollment or privileged workstation process.

Remove only unauthorized values

For confirmed unauthorized entries, remove the specific unauthorized value from the object. Do not rely on password reset alone. Password reset may still be required if the account was otherwise compromised, but it does not by itself prove that key-based authentication material has been removed from AD.

Fix the permission path

After value cleanup, fix permissions. Review direct and inherited rights that allow writing msDS-KeyCredentialLink, writing broad object properties, changing the object's DACL, or changing object ownership. Remove broad delegations from privileged accounts, admin OUs, service-account OUs, and computer accounts where they are not required. If a helpdesk or automation workflow legitimately needs to manage Windows Hello for Business enrollment, scope it narrowly and monitor it explicitly.

For privileged accounts, review Key Admins and related groups. Microsoft dual enrollment guidance describes Key Admins permissions on msDS-KeyCredentialLink and AdminSDHolder considerations for protected accounts. If privileged Windows Hello for Business enrollment is allowed, document which devices are approved, which accounts are allowed, and how new key credential values are authorized. If it is not allowed, privileged accounts should not silently accumulate key credentials.

Finally, harden the operating model. Use tiered administration or equivalent admin isolation so that lower-trust workstations and broad delegated groups cannot modify high-value identity objects. Keep privileged identity administration separate from daily productivity accounts. Review attack paths periodically, because this issue is usually caused by a chain of rights rather than a single obvious group membership.

Validation After Cleanup

Validation should prove both cleanup and control recovery.

Validation step	Success criteria
Re-run key credential inventory	Only expected `msDS-KeyCredentialLink` values remain, and each maps to a documented user, device, source, usage, and KeyID.
Re-check object permissions	No unauthorized principal can write the attribute, write broad object properties, change DACL, or change owner on high-value accounts.
Review 5136 after cleanup	No unexpected `Value Added` operations occur for `msDS-KeyCredentialLink` on privileged accounts or sensitive computers.
Review 4662 after cleanup	Write-property and security-descriptor activity on monitored objects matches approved admin workflows.
Review 4768 after cleanup	Key-based authentication for sensitive accounts occurs only from expected users, devices, and scenarios.
Test legitimate WHfB/FIDO flows	Approved users can still sign in where the business intentionally relies on key trust.

If an incident involved a privileged account, validation should also include review of downstream activity. Check administrative logons, group membership changes, service configuration changes, GPO edits, new certificates, and any later movement that could have used the recovered identity. Shadow Credentials can be the access method, but not necessarily the final objective.

EtcSec should not label this article with an inaccurate vulnerability type if the catalogue does not contain a direct Shadow Credentials or msDS-KeyCredentialLink entry. The related exposure still fits EtcSec's Active Directory audit model: dangerous object permissions, privileged-account exposure, inherited ACL paths, and missing monitoring around AD object changes.

In practice, an EtcSec review can help identify the conditions that make this attack path viable: principals with excessive write control over user or computer objects, privileged accounts that are not isolated, dangerous ACL paths to administrative identities, and monitoring gaps around directory object changes. That is the right framing. Shadow Credentials are not a generic Kerberos weakness; they are a key-trust abuse path created by object control.

Shadow Credentials controls should be tied to identity ownership, not only to Kerberos monitoring.

Control	Why it matters
Inventory `msDS-KeyCredentialLink` on users and computers	Establishes what key-based authentication paths exist before an incident.
Restrict write access to key credential attributes	Prevents unauthorized principals from adding new authentication material.
Monitor 5136 on `msDS-KeyCredentialLink`	Captures attribute-level changes when Directory Service Changes auditing and SACLs are configured.
Monitor 4662 on sensitive identity objects	Exposes write-property, DACL, and ownership operations when SACLs are in place.
Correlate 4768 with directory changes	Helps connect key-based authentication behavior to recent object modification.
Protect privileged accounts with admin isolation	Reduces the chance that lower-tier compromise can modify high-value identity objects.
Review Key Admins and AdminSDHolder behavior	Prevents legitimate WHfB administration paths from becoming uncontrolled privileged key-write paths.

These controls also support broader AD hardening work. If you are building a structured review, combine this article with How to Audit Active Directory Security: Practical Checklist for Internal Teams, then prioritize privileged identity objects and OUs first.

Shadow Credentials: Abusing msDS-KeyCredentialLink in Active Directory

What Are Shadow Credentials?