Shadow Credentials is a common name for an Active Directory attack path involving unauthorized key credential material on a user or computer object. Shadow Credentials exists when an attacker can add a key credential to an Active Directory object and later use that credential to authenticate as that object. This matters because the attacker may not need the account’s password. Instead, the attacker abuses certificate-based or key-based authentication behavior by adding key material to an attribute that Active Directory can use during authentication.
Shadow Credentials is especially important because it connects several sensitive areas:
- Active Directory object permissions
- Kerberos authentication
- Certificate-based authentication
- Windows Hello for Business
- Computer account security
- Privileged account protection
- Persistence
It is not only an AD CS issue, but it often overlaps with AD CS and certificate-based authentication concepts.
What are Shadow Credentials?
Shadow Credentials refers to an abuse path where unauthorized key credential material is added to an account object.
The account may be:
- A user
- A computer
- A service account
- A privileged account
- A domain controller computer account
If the added key credential can be used for authentication, the attacker may be able to authenticate as that account without knowing the account password. This can create persistence because password resets may not remove the added key credential.
What is msDS-KeyCredentialLink?
msDS-KeyCredentialLink is an Active Directory attribute associated with key credential information. In legitimate scenarios, this attribute may be used by features such as Windows Hello for Business. That means the attribute is not suspicious by itself, the problem is unauthorized modification.
Why Shadow Credentials matter
Shadow Credentials matter because they can create an authentication path that does not depend on the account’s current password. If an attacker can write to the right attribute on a target object, they may be able to add their own key credential material. If that key material is accepted for authentication, the attacker can use it as another way to authenticate as the target.
Potential impact includes:
- User impersonation
- Computer account impersonation
- Persistent access
- Privileged account compromise
- Bypass of password resets
- Abuse of weak object permissions
- Lateral movement through computer accounts
- Domain escalation if a high-value object is affected
The risk depends heavily on which object can be modified. A Shadow Credentials issue on a low-privilege test account is very different from the same issue on a domain admin account, server computer account, certificate authority, or domain controller.
Why object permissions create the risk
Shadow Credentials usually depends on Active Directory permissions. The core issue is not that msDS-KeyCredentialLink exists. The issue is that an account has enough rights to modify sensitive attributes on another object.
High-risk rights may include:
GenericAll
GenericWrite
WriteDacl
WriteOwner
WriteProperty
Validated write permissions
Full ControlIf a user can write to a target object, that access may be more powerful than it first appears.
For example, write access over a computer object may support multiple abuse paths, including:
- Resource-based constrained delegation
- SPN modification
- Group membership changes in some cases
- Shadow Credentials
- Other object attribute manipulation
This is why object permissions should be reviewed as part of Active Directory security assessments.
Shadow Credentials vs password theft
Shadow Credentials is different from stealing or cracking a password.
| Issue | What the attacker abuses |
|---|---|
| Password theft | The user’s plaintext password or reusable secret |
| Pass-the-hash | The NTLM hash |
| Kerberoasting | A crackable Kerberos service ticket |
| AS-REP Roasting | A crackable Kerberos AS-REP response |
| Shadow Credentials | Unauthorized key credential material on an AD object |
In Shadow Credentials, the attacker is not necessarily changing the password. They are adding another way to authenticate. This is why password resets may not fully remediate the issue. Defenders need to review and remove unauthorized key credential material and fix the permissions that allowed the change.
How this relates to certificate-based authentication
Shadow Credentials is closely related to certificate-based or key-based authentication. Microsoft’s KB5014754 covers certificate-based authentication changes on Windows domain controllers and strong certificate binding behavior. That guidance matters because domain controllers are responsible for validating certificate-based authentication in Active Directory environments. Shadow Credentials is not the same as a misconfigured certificate template. It does not necessarily require a vulnerable AD CS template.
The overlap is conceptual:
- AD CS issues certificates.
- Certificate-based authentication can authenticate users or computers.
- Key credentials can provide another authentication path.
- Domain controllers validate authentication.
- Weak object permissions can allow unauthorized identity material to be added.
This is why defenders should understand Shadow Credentials alongside AD CS, certificate templates, ESC paths, and Kerberos.
How this relates to Windows Hello for Business
Windows Hello for Business can legitimately use key-based authentication. In hybrid key trust scenarios, Microsoft documents that a user’s public key can be written to msDS-KeyCredentialLink in Active Directory after provisioning. That means defenders should not assume every populated msDS-KeyCredentialLink value is malicious.
Instead, review context:
- Is Windows Hello for Business deployed?
- Is key trust or cloud trust being used?
- Which users or computers are expected to have key credentials?
- When were the values added?
- Who modified the attribute?
- Are the affected accounts privileged?
- Do the values align with expected provisioning activity?
A populated value may be normal. An unexpected change to a sensitive object is the concern.
Common exposure paths
Shadow Credentials exposure often starts with excessive object permissions.
Common exposure paths include:
- Help desk groups with broad write access
- Legacy delegated administration
- Application service accounts with object write permissions
- Misconfigured OU delegation
- Excessive permissions on computer objects
- Over-permissive permissions inherited from parent OUs
- Weak permissions on service accounts
- Old migration or provisioning accounts
- Compromised accounts with write access to users or computers
- Attack paths where one object can control another object
Defenders really need to determine who can modify sensitive attributes on this account. If the answer includes accounts or groups that do not need that level of control, the object may be exposed.
High-value targets
Shadow Credentials risk is highest when the affected object has meaningful access.
Prioritize review for:
- Domain Admins
- Enterprise Admins
- Schema Admins
- Privileged service accounts
- Domain controller computer accounts
- Certificate authority computer accounts
- Backup servers
- Management servers
- Jump servers
- Tier 0 systems
- Servers with local administrator rights over many systems
- Accounts used by identity or endpoint management platforms
A low-privilege object can still matter if it has a path to something more important.
Why computer accounts matter
Computer accounts are often overlooked. A computer account is a security principal. It has a password, can authenticate, can access resources, and may have permissions in Active Directory. Computer object permissions should be reviewed carefully, especially when users or low-privilege groups have write access.
What defenders should look for
A practical Shadow Credentials review should focus on two things:
- Objects with unexpected
msDS-KeyCredentialLinkvalues. - Principals that can modify sensitive user or computer objects.
The first identifies possible existing exposure. The second identifies paths that could allow exposure in the future.
PowerShell: Find objects with msDS-KeyCredentialLink
Use this to find users and computers where the attribute is populated.
Get-ADObject -LDAPFilter "(msDS-KeyCredentialLink=*)" `
-Properties msDS-KeyCredentialLink, objectClass, whenChanged |
Select-Object Name, objectClass, DistinguishedName, whenChangedThis is not automatically a finding. Some environments legitimately use this attribute. Treat the output as a review list.
PowerShell: Find users with msDS-KeyCredentialLink
Get-ADUser -LDAPFilter "(msDS-KeyCredentialLink=*)" `
-Properties msDS-KeyCredentialLink, Enabled, whenChanged |
Select-Object Name, SamAccountName, Enabled, whenChanged, DistinguishedNamePay special attention to privileged users, service accounts, and users that should not have key-based authentication configured.
PowerShell: Find computers with msDS-KeyCredentialLink
Get-ADComputer -LDAPFilter "(msDS-KeyCredentialLink=*)" `
-Properties msDS-KeyCredentialLink, Enabled, OperatingSystem, whenChanged |
Select-Object Name, DNSHostName, Enabled, OperatingSystem, whenChanged, DistinguishedNameReview sensitive servers first.
PowerShell: Review permissions on a user or computer object
Use this to inspect permissions on a specific object.
$ObjectDn = "CN=TargetUser,OU=Users,DC=example,DC=com"
Get-Acl "AD:\$ObjectDn" |
Select-Object -ExpandProperty Access |
Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, IsInherited |
Sort-Object IdentityReferenceLook for unexpected write, owner, or permission-modification rights.
PowerShell: Find potentially dangerous rights on an object
$ObjectDn = "CN=TargetComputer,OU=Servers,DC=example,DC=com"
Get-Acl "AD:\$ObjectDn" |
Select-Object -ExpandProperty Access |
Where-Object {
$_.ActiveDirectoryRights -match "GenericAll|GenericWrite|WriteDacl|WriteOwner|WriteProperty"
} |
Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, IsInheritedThis helps identify permissions that deserve review. Do not assume every result is malicious. Some delegated permissions may be intentional. The goal is to confirm whether they are justified.
PowerShell: Export populated key credential objects
Get-ADObject -LDAPFilter "(msDS-KeyCredentialLink=*)" `
-Properties msDS-KeyCredentialLink, objectClass, whenChanged |
Select-Object Name, objectClass, DistinguishedName, whenChanged |
Export-Csv .\objects-with-keycredentiallink.csv -NoTypeInformationUse the export to compare against expected Windows Hello for Business, device registration, or key trust deployment behavior.
GUI: Review the attribute in Active Directory Users and Computers
Enable Advanced Features:
Active Directory Users and Computers
View
Advanced FeaturesThen open the user or computer object:
Object Properties
Attribute Editor
msDS-KeyCredentialLinkThis can help confirm whether the attribute is populated. For large environments, PowerShell is usually more practical.
GUI: Review object permissions
In Active Directory Users and Computers:
Object Properties
Security
AdvancedReview who has permissions such as:
- Full control
- Write all properties
- Write permissions
- Modify owner
- Modify permissions
- Validated writes
Be careful with inherited permissions from OUs. A risky permission may not be directly assigned to the object.
Detection opportunities
Shadow Credentials detection should focus on changes to sensitive attributes and permissions.
Monitor for:
- Changes to
msDS-KeyCredentialLink - Changes to privileged user objects
- Changes to sensitive computer objects
- Changes to domain controller computer objects
- Changes to certificate authority computer objects
- Changes to object ACLs
- New delegated permissions on OUs
- Unexpected write rights over users or computers
- Key credential changes outside expected Windows Hello for Business provisioning
- Changes made by unusual accounts or from unusual systems
Useful Windows event sources include:
| Event ID | Purpose |
|---|---|
| 4662 | Directory Service object operation when auditing is configured |
| 4738 | User account changed |
| 4742 | Computer account changed |
| 5136 | Directory service object modified |
| 4670 | Permissions on an object were changed |
Event ID 5136 is especially useful when Directory Service Changes auditing is enabled because it can show modified object attributes.
How to reduce exposure
Reducing Shadow Credentials exposure usually means improving object permission hygiene.
Important controls include:
- Limit write access over user and computer objects.
- Review delegated permissions on OUs.
- Remove unnecessary GenericAll, GenericWrite, WriteDacl, WriteOwner, and WriteProperty rights.
- Protect privileged accounts from lower-tier administration.
- Keep Tier 0 users and computers in tightly controlled OUs.
- Monitor changes to
msDS-KeyCredentialLink. - Monitor object ACL changes.
- Validate legitimate Windows Hello for Business usage.
- Review service accounts with delegated write access.
- Avoid broad help desk permissions over privileged objects.
- Review computer object permissions for sensitive servers.
The most important remediation is to remove the permission path that allowed unauthorized modification.
How to respond if Shadow Credentials are suspected
A safe response should include both containment and root cause review.
Practical steps include:
- Identify the affected object.
- Confirm whether the
msDS-KeyCredentialLinkvalue is expected. - Determine when the attribute changed.
- Identify which account changed it.
- Remove unauthorized key credential material.
- Reset the affected account password if appropriate.
- Review active sessions and authentication logs.
- Review object permissions.
- Remove the permission path that allowed the change.
- Review other objects controlled by the same principal.
- Monitor for repeated changes.
Do not stop at removing the attribute value. If the permissions remain, the issue can return.
Common mistakes
Treating every populated value as malicious
msDS-KeyCredentialLink can be legitimate, especially in environments using Windows Hello for Business or related key trust scenarios.
Resetting the password and stopping there
A password reset may not remove unauthorized key credential material. Review the attribute and permissions.
Ignoring computer objects
Computer accounts can be high-value targets, especially servers, domain controllers, certificate authorities, and management systems.
Only checking privileged users
Privileged users matter, but attackers may target computer accounts or lower-privilege accounts that have a path to privilege.
Ignoring inherited permissions
Risky write permissions may come from OU delegation rather than direct object permissions.
Failing to monitor object changes
Shadow Credentials relies on directory object modification. Without Directory Service Changes auditing, visibility may be limited.
Assuming this is only an AD CS problem
Shadow Credentials overlaps with certificate-based authentication, but it is mainly about key credentials and object permissions. It does not necessarily require a vulnerable certificate template.
Practical recommendation
A practical Shadow Credentials review should include:
- Identify objects with
msDS-KeyCredentialLinkpopulated. - Determine whether those values are expected.
- Prioritize privileged users and sensitive computer accounts.
- Review object permissions for high-value users and computers.
- Review OU delegation that grants write access over users or computers.
- Monitor changes to
msDS-KeyCredentialLink. - Monitor changes to object ACLs.
- Validate Windows Hello for Business and key trust behavior.
- Remove unnecessary write permissions.
- Protect Tier 0 accounts and systems from lower-tier control.
- Investigate unexpected key credential changes quickly.
The key is not only finding existing values. The key is understanding who can create or modify them.
Summary
Shadow Credentials is an Active Directory attack path where unauthorized key credential material is added to a user or computer object. If accepted for authentication, that key credential can become another way to authenticate as the target account. The most important attribute is msDS-KeyCredentialLink, which Microsoft documents as containing key material and usage information. The attribute can be used legitimately, including by Windows Hello for Business, but unexpected changes to sensitive objects should be investigated.
Defenders should focus on object permissions, privileged accounts, sensitive computer accounts, Windows Hello for Business expectations, Directory Service Changes auditing, and monitoring for changes to msDS-KeyCredentialLink. Shadow Credentials is ultimately a reminder that write access to Active Directory objects can be equivalent to control of identity.