ADTRADE-006: Shadow Credentials (msDS-KeyCredentialLink) on Privileged Principals

Platform
Active Directory
Category
AD Adversary Tradecraft Indicators
Severity
Critical
Zero Trust pillar
Identity (weight 2)
Golden fixtures
3
Branch coverage
Observed: fixtures prove the verdicts they exercise
Provenance
baseline

What it checks

The msDS-KeyCredentialLink attribute holds public keys used for Windows Hello for Business / passwordless PKINIT logon. An attacker with write access to this attribute on a target can add their OWN key pair (Whisker / pyWhisker) and then request a Kerberos TGT as that account using the matching private key — a stealthy persistence and impersonation technique known as 'shadow credentials'. Any unexpected key credential on a Tier-0 object (a domain admin, a domain controller, or any adminCount=1 account) should be treated as a potential backdoor until proven to be a legitimate WHfB enrollment.

Recommended value

No unrecognised msDS-KeyCredentialLink values on privileged/Tier-0 principals; every key maps to a known WHfB/passwordless enrollment.

Remediation

For each flagged principal, inspect the key credentials (Get-ADObject -Properties msDS-KeyCredentialLink, or the DSInternals Get-ADKeyCredential cmdlet) and correlate each device key with a legitimate Windows Hello for Business enrollment. Remove any entry you cannot attribute to a sanctioned enrollment. Restrict who can write msDS-KeyCredentialLink (audit Key Admins / Enterprise Key Admins and OU/object DACLs granting that write). Reset the affected accounts if compromise is suspected.

Fixture-proven verdicts

Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.

Verdict scenarios for ADTRADE-006
ScenarioExpected verdict
cleanPASS
known-badFAIL
throttledNot Assessed

Framework mappings

NIST SP 800-53
IA-5, AC-6, AU-6
ANSSI
vuln1_permissions_keycredentiallink
CIS AD Benchmark
6.2.1
MITRE ATT&CK
T1556, T1098