Active Directory 03 Aug 2026 // 8 min read

Shadow Credentials: The AD Attack Path Your SOC Isn't Watching

The msDS-KeyCredentialLink attribute continues to be overlooked by blue teams while remaining a powerful lateral movement primitive. Here's what it is, how we exploit it, and how to detect it.

Windows Hello for Business introduced a certificate-based authentication mechanism called Key Trust, built on PKINIT (Public Key Cryptography for Initial Authentication in Kerberos). Under this model, a user or computer object can have one or more public keys stored in the msDS-KeyCredentialLink attribute on their AD object. When the user authenticates, they present proof of possession of the corresponding private key, and the domain controller issues a TGT without requiring a password.

Shadow Credentials is the name given to the attack that abuses this mechanism. If an attacker has write access to a target's msDS-KeyCredentialLink attribute, they can add their own key credential — effectively registering a "shadow" authentication credential on the target account. They then authenticate as that account using the corresponding private key, without knowing the account's password and without changing it.

It is one of the cleaner privilege escalation and lateral movement primitives in Active Directory: stealthy, reversible, and requiring no service restart or password reset. Despite this, it remains poorly covered by most SOC detection stacks.

Prerequisites and Conditions

The attack requires two things:

Write access to the target's msDS-KeyCredentialLink attribute. This can come from a number of AD permissions: GenericAll, GenericWrite, WriteProperty on the specific attribute, or in some cases WriteDACL (which can be used to grant yourself WriteProperty). These permissions are more common than they should be — particularly on service accounts and machine accounts where delegated permissions have accumulated over time.
A domain controller running Windows Server 2016 or later, with PKINIT support enabled. Most modern AD environments meet this requirement. If the domain is still on 2012 R2 DCs, the attack fails at the authentication step.

Machine accounts are particularly interesting targets. By default, every machine account has write access to its own msDS-KeyCredentialLink attribute. If an attacker has compromised a machine account (for example, via NTLM relay, or from a service running as a machine account), they can add a key credential to the account itself, retrieve its NT hash, and use it for Pass-the-Hash.

The Attack in Practice

The primary tool for this attack is Whisker, a C# tool that adds, lists, and removes key credentials from AD objects. The workflow is straightforward:

Step 1 — Add a key credential to the target

# Add a shadow credential to a target user
Whisker.exe add /target:targetuser /domain:corp.local /dc:dc01.corp.local /path:C:\temp\cert.pfx /password:P@ssw0rd

Whisker generates a key pair, writes the public key to the target's msDS-KeyCredentialLink, and outputs a .pfx file containing the private key along with a Rubeus command for the next step.

Step 2 — Authenticate using the key credential

# Request a TGT using the certificate (PKINIT)
Rubeus.exe asktgt /user:targetuser /certificate:cert.pfx /password:P@ssw0rd /nowrap

This requests a TGT from the DC using PKINIT. The DC validates that the private key corresponds to the public key stored in msDS-KeyCredentialLink and issues the TGT.

Step 3 — Retrieve the NT hash

The TGT from PKINIT includes a PAC (Privilege Attribute Certificate), which contains the user's group memberships and SIDs. It also supports User-to-User (U2U) Kerberos, which Rubeus can use to retrieve the target account's NT hash:

# Get NT hash via PKINIT U2U
Rubeus.exe asktgt /user:targetuser /certificate:cert.pfx /password:P@ssw0rd /getcredentials /nowrap

This yields the NT hash of the target account, which can then be used for Pass-the-Hash, Pass-the-Ticket, or further Kerberoasting if the account has SPNs.

Step 4 — Clean up

# List credentials on the target (get the DeviceID)
Whisker.exe list /target:targetuser /domain:corp.local /dc:dc01.corp.local

# Remove the shadow credential
Whisker.exe remove /target:targetuser /domain:corp.local /dc:dc01.corp.local /deviceid:<GUID>

Removing the credential leaves no lasting modification to the account and avoids triggering password-reset detections.

Why BloodHound Surfaces This

BloodHound (particularly Community Edition with newer ingestors) will mark relationships such as GenericWrite → target as a valid attack path. Running a shortest-path query from any compromised account to Domain Admins will frequently surface msDS-KeyCredentialLink write access as a hop in that chain.

On a recent internal assessment: a service account used by a monitoring tool had GenericWrite over a tier-0 administrative account, granted years earlier for a now-defunct integration. The chain: compromise monitoring server → extract service account credential → add shadow credential to tier-0 admin → authenticate as tier-0 admin. Total time from initial foothold to Domain Admin: 22 minutes.

Detection

The attack generates two primary detection opportunities:

1. Directory Service Changes (Event ID 4662 / 5136)

Writing to msDS-KeyCredentialLink generates a Directory Service Change event (5136 on the DC, or 4662 depending on audit policy). You need to have Advanced Audit Policy → DS Access → Audit Directory Service Changes enabled — it is off by default on most deployments.

Filter for:

Event ID 5136
LDAP Display Name: msDS-KeyCredentialLink
Operation Type: %%14675 (Value Added)

Alert on any modification to this attribute that does not originate from your Windows Hello for Business provisioning service or a known device management system. In environments not using Windows Hello for Business, any write to this attribute is immediately suspicious.

2. PKINIT authentication from unexpected accounts

Kerberos pre-authentication using a certificate (PKINIT) generates Event ID 4768 with Pre-Authentication Type 16 or 17. If an account that has never previously used certificate-based authentication suddenly does, that warrants investigation.

This detection is noisier in environments using Windows Hello for Business or smart cards, where PKINIT is expected. In password-only environments, any PKINIT authentication event is anomalous.

Remediation

Enable DS Change auditing — turn on Audit Directory Service Changes under Advanced Audit Policy and create an alert for modifications to msDS-KeyCredentialLink.
Audit write permissions on high-value accounts — use BloodHound or Get-ObjectAcl (PowerView) to enumerate who has GenericWrite, WriteProperty, or GenericAll on tier-0 and tier-1 accounts. Remove permissions that cannot be justified.
Implement AD tiering — ensuring that service accounts operating at lower tiers cannot reach high-value accounts is the structural control that prevents this class of attack from being a single-hop to Domain Admin.
Monitor PKINIT usage — baseline which accounts use certificate authentication and alert on deviations. In environments without Windows Hello for Business, any PKINIT event is worth investigating.

Summary

Shadow Credentials is not a new technique — it was first documented by Elad Shamir in 2021 — but it remains consistently under-detected. The combination of low operational noise (no password change, no service disruption), clean reversibility, and frequent availability of GenericWrite permissions in enterprise AD environments makes it a reliable primitive in our assessment toolkit.

If your SOC is not alerting on modifications to msDS-KeyCredentialLink, it is not detecting this attack. If you want to understand where these write paths exist in your environment before an attacker finds them, an Active Directory security assessment will surface them.