Shadow Credentials (msDS-KeyCredentialLink)

Writing a key credential to a victim account — a TGT via PKINIT without the password.

Theory

Shadow Credentials is an attack technique where the attacker does not steal or change the password. Instead they write a single value to the victim account: a Key Credential inside an attribute called .

Background: the attribute is meant for Windows Hello for Business and FIDO2 — it links an account to a cryptographic key. When the value exists, a can be requested via using the key — without knowing the victim's password.

The attacker writes a Key Credential to the victim's msDS-KeyCredentialLink attribute, then requests a TGT via PKINIT without a password. The left column shows the vertical attack chain; the right panel lists detection events (5136, 4768) and mitigation steps.

Short and clear

The attacker never touches the password — only writes a Key Credential to msDS-KeyCredentialLink.
PKINIT allows a TGT via certificate without a password.
Detection: 5136 (attribute change) followed immediately by 4768 (certificate-based TGT).
Without Windows Hello for Business, any change to the attribute is suspicious.

Real-life exampleComputer account SRV-BACKUP$ received a new value in msDS-KeyCredentialLink. A minute later, a 4768 request with a certificate for SRV-BACKUP$: a strong Shadow Credentials signal.

Why it is dangerous

Stealthy: no password change, no lockout, the victim does not notice.
Persistent: the is valid like any normal TGT and can be renewed over and over.
Targets: users and computers — especially computers with , where compromising a computer equals compromising the domain.

Required permission: write access to the attribute of the account/computer (WriteProperty or a specific ACE). In the relevant edge is called AddKeyCredentialLink.

Practice — lab only

# 1. Adding Key Credential with pywhisker (Linux)
pywhisker.py -d "corp.local" -u "attacker" -p "Password123" \
  --target "SRV-BACKUP$" \
  --action "add" \
  --filename backup_srv
# Output: backup_srv.pfx with the private key

bash

# 2. Same thing from Windows with Whisker
Whisker.exe add /target:SRV-BACKUP$ /domain:corp.local /dc:dc01.corp.local

powershell

# 3. Using PFX to get TGT for the computer with Rubeus
Rubeus.exe asktgt /user:SRV-BACKUP$ /certificate:backup_srv.pfx /password:pass /ptt

powershell

Now you have a as SRV-BACKUP$ — and if the computer had , the domain has fallen.

Detection

Event ID 5136 — change to the attribute (attribute GUID: 5b47d60f-6090-40b2-9f37-2a4de88f3063).
Event ID 4768 — request authenticated by certificate, especially for accounts not enrolled in Windows Hello for Business.
Correlation: a new value in followed immediately by a 4768 with a certificate for the same account — a strong Shadow Credentials signal.
Dedicated Sigma rules exist — search for "Shadow Credentials" in the catalog.

Mitigation

Audit who can write to — in : MATCH p=()-[r:AddKeyCredentialLink]->() RETURN p.
Remove unnecessary WriteProperty from service accounts and groups.
Protect Tier 0 with PAW and Tiering rules — the attack's primary target.
If the organization does not use Windows Hello for Business — any change to the attribute should be zero; full monitoring is an easy audit.
Defender for Identity: there is a built-in Shadow Credentials alert — enable it.