Shadow Credentials in Active Directory Explained

If you can write to msDS-KeyCredentialLink, you may be able to create a new way to authenticate as the target account without changing its password.

Shadow Credentials abuses a legitimate Active Directory mechanism tied to key trust. The attacker adds key material to the target object and then tries to use that key for PKINIT authentication.

The original password stays unchanged.

The examples below assume a lab or an authorized penetration test.

The attribute that changes the trust model

msDS-KeyCredentialLink stores key information associated with an Active Directory object.

The attribute has existed since Windows Server 2016.

In legitimate deployments, it participates in key-based authentication, including Windows Hello for Business.

From an offensive perspective, the useful question is:

Can my account write this attribute on another account?

If the answer is yes, that control relationship deserves validation.

The prerequisite usually comes from an ACL

Shadow Credentials rarely appear by themselves.

The path usually starts with an ACL.

It may be GenericAll.

It may be GenericWrite.

It may be an object-specific right that allows msDS-KeyCredentialLink to be modified.

BloodHound can reveal relationships that lead to this condition.

The target can be a user or a computer.

A computer account can be just as valuable if it holds access elsewhere or participates in another delegation chain.

The technique in one flow

Conceptually:

controlled account
      |
      | writes msDS-KeyCredentialLink
      v
target object
      |
      | now trusts a key
      v
PKINIT
      |
      v
TGT as the target

The attacker does not need to reset the password.

The attacker does not need to add the target to a group either.

A new way to prove possession of a credential has been created.

Why PKINIT matters

PKINIT allows initial Kerberos authentication using public key cryptography.

Instead of proving knowledge of a password, the client proves possession of a private key associated with an identity the domain accepts.

Shadow Credentials creates that trusted key material.

Once the key is linked to the object, a tool can attempt to obtain a TGT using the new credential.

The environment still needs PKINIT support.

The Domain Controller must have a suitable certificate for this flow.

If PKINIT is unavailable, the attribute write may succeed while authentication still fails.

Testing with Certipy

Certipy supports Shadow Credentials automation.

A lab flow may look like this:

certipy shadow auto \
  -u 'gabriel@lab.local' \
  -p 'Password123!' \
  -account 'svc_backup' \
  -dc-ip 10.10.10.10

The auto mode attempts to add the credential, authenticate, and restore the previous state.

I still record the original attribute before testing.

Automation saves time.

It does not remove the need to understand what changed.

What I want to prove

A strong finding shows the entire chain.

The initial account has a permission.

That permission allows msDS-KeyCredentialLink to be changed.

The new key material allows authentication as the target.

The target has additional access.

If svc_backup controls nothing sensitive, the impact remains limited.

If it administers servers or has another privilege relationship, the chain grows.

The technique name sounds dramatic. The report still needs to show what the target identity can actually do.

Why this can be quieter than a password reset

Changing a user’s password can create obvious disruption.

A service may stop authenticating.

A user may lose access.

An application may break.

Adding a Key Credential can preserve the existing password.

That makes the technique useful in red team operations.

It also explains why monitoring only password-reset events leaves a gap.

Changes to authentication-related attributes deserve attention.

Users and computers create different paths

Against a user, the goal is often to authenticate as that identity.

Against a computer, the result may feed into a different attack chain.

Computer accounts have passwords, SIDs, groups, and permissions.

In Active Directory, computers are security principals.

Treating them as ordinary assets hides useful control relationships.

Cleanup is part of the test

If you add a Key Credential during a pentest, remove it after validation.

Tools can automate that.

I still confirm the final attribute value.

A test that leaves an alternative credential behind has created a new security problem.

That matters even more on sensitive accounts.

Detection

Changes to msDS-KeyCredentialLink deserve monitoring.

A defensive team can correlate the modification with the principal that wrote it, the target object, and later authentication activity.

Context matters.

Windows Hello for Business can generate legitimate changes.

A detection rule should ask who changed the attribute, which object was changed, and whether that principal normally manages it.

Remediation

Fix the ACL that allowed the write.

Removing the malicious Key Credential restores the immediate state.

If the attacking account still holds GenericWrite or an equivalent right, the process can be repeated.

Review delegation on users and computers.

Reduce broad rights.

Monitor authentication attributes.

Then repeat the test with the original low-privileged account.

A useful mental model

Think of Shadow Credentials as adding another credential to an identity.

A password is only one way to authenticate.

Certificates and keys can prove identity too.

If an ACL lets another principal register that material, the trust relationship is already broken.

Password rotation does not remove a Key Credential

This detail explains part of the technique’s persistence.

The password and msDS-KeyCredentialLink represent different authentication material.

Resetting the user’s password does not automatically delete Key Credentials registered on the object.

If incident response handles only the password, the alternative credential may remain available.

Containment therefore needs to review authentication attributes as well as traditional credentials.

PKINIT depends on the Domain Controller

Writing the attribute and authenticating are separate stages.

The KDC needs PKINIT support and a suitable certificate.

In a lab without AD CS or without a compatible DC certificate, the attribute change may work while TGT acquisition fails.

That does not make the test meaningless.

It proves control over a sensitive attribute while showing that the authentication chain did not complete in that environment.

The report should separate those two pieces of evidence.

DeviceID can help investigations

Key Credentials carry metadata that can help forensic review.

Offensive tooling commonly creates fresh DeviceID values and key material.

Comparing recent changes with legitimate provisioning patterns can be useful.

Defenders gain much better signal when they understand how Windows Hello for Business normally creates those records.

References

Microsoft Open Specifications, msDS-KeyCredentialLink.

Microsoft Open Specifications, Public Key Cryptography for Initial Authentication in Kerberos.

Certipy, Project documentation.