Shadow Credentials: Attack & Defense Guide (msDS-KeyCredentialLink)

Category: Active Directory | Credential Access | Kerberos Abuse
Audience: Blue Team / Defenders
Severity: High – enables domain privilege escalation without password knowledge

---

TL;DR

Shadow Credentials is an Active Directory attack that lets an adversary authenticate as any user or computer account by writing a rogue cryptographic key to the msDS-KeyCredentialLink attribute – no password required. Detection hinges on auditing Event 5136 (AD attribute modification) and Microsoft Defender for Identity alerts. Mitigation requires tightening write-access ACLs on msDS-KeyCredentialLink for all privileged accounts.

---

Prerequisites

• Environment: Active Directory domain running Windows Server 2016 or later; DS Access auditing enabled on domain controllers
• Detection tools: Microsoft Sentinel (for KQL queries), Microsoft Defender for Identity (MDI), and an EDR with .NET/CLR telemetry
• Attacker tools referenced: Whisker (KeyCredential injection), Rubeus (PKINIT / TGT acquisition)
• Familiarity: Basic Kerberos authentication concepts; Active Directory ACL model

---

Part 1: Understanding the Attack

What Are Shadow Credentials?

Shadow Credentials is an attack technique that exploits the msDS-KeyCredentialLink attribute in Active Directory to add a rogue cryptographic key to a user or computer account. Once planted, this key allows an attacker to authenticate as the victim account via PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) – without ever knowing the account’s password.

The technique was publicly documented by Elad Shamir in 2021 and has since become a reliable post-exploitation path in environments running Windows Server 2016 or later with Azure AD hybrid configurations.

The msDS-KeyCredentialLink Attribute

msDS-KeyCredentialLink stores a list of NGC (Next Generation Credentials) key objects tied to an account. These are normally written by legitimate Windows Hello for Business (WHfB) infrastructure – enrolled devices add entries here during passwordless authentication setup. Each entry is a DER-encoded KeyCredential structure containing:

• A public key (RSA or EC)
• A device ID
• Creation timestamps
• Usage flags (NGC, FIDO, etc.)

Because this attribute is just data in AD, any principal with write access to it can append their own malicious key – no certificate authority, no domain admin privilege required.

Attack Path

Attacker has write access to target principal's msDS-KeyCredentialLink
          │
          ▼
1. Generate RSA key pair (attacker controls private key)
2. Craft KeyCredential structure with attacker's public key
3. PATCH msDS-KeyCredentialLink on target account (append entry)
          │
          ▼
4. Authenticate via PKINIT using attacker's private key
   → AD issues a Kerberos TGT for the victim account
          │
          ▼
5. Use U2U (User-to-User) Kerberos exchange to decrypt the PAC
   → Extract victim's NTLM hash from the PAC
          │
          ▼
6. Pass-the-Hash or Overpass-the-Hash for full account takeover

Critical prerequisite: The attacker needs write permission on the target’s msDS-KeyCredentialLink attribute. This arises from:

• Ownership of the object (e.g., creator of a computer account)
• GenericWrite / GenericAll ACEs granted to an attacker-controlled principal
• Delegation misconfigurations or over-permissive GPOs
• ACL inheritance from OU-level permissions

Tools Used by Attackers

Whisker (C#) – github.com/eladshamir/Whisker
The primary tool for this attack. Whisker automates key generation, KeyCredential construction, and attribute patching. Basic usage:

Whisker.exe add /target:<victim_account> /domain:corp.local /dc:DC01.corp.local

On success, Whisker outputs the Rubeus command to use the certificate.

Rubeus (C#) – github.com/GhostPack/Rubeus
Handles the PKINIT authentication step after Whisker plants the key:

Rubeus.exe asktgt /user:<victim_account> /certificate:<base64> /password:<pfx-pass> /domain:corp.local /dc:DC01.corp.local /getcredentials /show

The /getcredentials flag triggers the U2U exchange that yields the NTLM hash.

Note on Certify: Certify is an AD Certificate Services (AD CS) enumeration and abuse tool. While AD CS misconfigurations can enable related Kerberos-based attacks (e.g., ESC1-ESC8), Certify is not part of the Shadow Credentials attack chain. The two attack surfaces are distinct; do not conflate them.

Why This Is Dangerous

• No password required – evades password spray detections and lockout policies
• Leaves minimal footprint compared to DCSync or Kerberoasting
• Works on both user and computer accounts
• Persistent: the rogue KeyCredential survives password resets (it’s key-based, not password-based)
• Can target high-value accounts: Domain Admins, service accounts, or LAPS computer objects

---

Part 2: Detection and Defense

This section covers the detection signals, mitigation controls, and incident response steps defenders should implement to protect against Shadow Credentials abuse.

Detection Strategy

Windows Event ID 5136 – Directory Service Object Modified

This is the primary detection signal. Event 5136 is generated whenever an AD attribute is modified. Shadow Credentials abuse always writes to msDS-KeyCredentialLink, so:

Filter criteria:

• EventID = 5136
• AttributeLDAPDisplayName = msDS-KeyCredentialLink
• OperationType = Value Added

KQL (Microsoft Sentinel – pseudo-code, validate field mappings against your Sentinel table schema before deploying):

// Note: field names below reflect common Sentinel AD connector schemas.
// Verify EventData field extraction paths against your actual SecurityEvent table.
SecurityEvent
| where EventID == 5136
| where EventData has "msDS-KeyCredentialLink"
| where EventData has "%%14674"  // Value Added operation type
| parse EventData with * '<Data Name="SubjectUserName">' SubjectAccount '</Data>'
                      * '<Data Name="ObjectDN">' ObjectName '</Data>'
                      * '<Data Name="AttributeLDAPDisplayName">' AttributeName '</Data>' *
| where AttributeName == "msDS-KeyCredentialLink"
| project TimeGenerated, SubjectAccount, ObjectName, AttributeName, Computer
| order by TimeGenerated desc

Key triage questions:

1. Is the modifying account (SubjectAccount) a legitimate WHfB enrollment service (e.g., Azure AD Connect, key provisioning service)?
2. Is the modified object (ObjectName) a privileged account (Domain Admin, service account)?
3. Was this modification preceded by any lateral movement indicators for the subject account?

Note: 5136 events require DS Access auditing to be enabled. Verify this is active across all domain controllers:

auditpol /get /subcategory:"Directory Service Changes"

Expected: Success and Failure (or at minimum Success).

Microsoft Defender for Identity (MDI)

MDI has a built-in alert: “Suspicious modification of the msDS-KeyCredentialLink attribute”. This alert fires when:

• A non-WHfB service modifies msDS-KeyCredentialLink on a privileged account
• The modification is immediately followed by a PKINIT authentication attempt

MDI alert severity: High. Triage via the MDI portal at security.microsoft.com → Identity → Alerts. For MDI alert documentation, see Microsoft’s Shadow Credentials detection guidance.

PKINIT Authentication Anomalies

Monitor for Kerberos AS-REQ with PKINIT preauthentication (padata type 16) on accounts that:

• Are not enrolled in Windows Hello for Business
• Have never previously used certificate-based authentication

Event 4768 (Kerberos TGT request) combined with certificate-based pre-authentication for user accounts not in your WHfB enrolled population is a high-confidence indicator.

Behavioral Baselines

Establish baseline of which service accounts normally write msDS-KeyCredentialLink. In most environments, this should be a very small set (Azure AD Connect, device provisioning services). Any write from outside this allowlist warrants immediate investigation.

---

Mitigation

1. Restrict Write Access to msDS-KeyCredentialLink

Audit and tighten ACLs on high-value accounts to prevent unauthorized writes:

# Enumerate who has write rights to msDS-KeyCredentialLink on privileged accounts
Import-Module ActiveDirectory
$acl = Get-Acl "AD:\CN=AdminUser,OU=Privileged,DC=corp,DC=local"
$acl.Access | Where-Object {
    $_.ActiveDirectoryRights -match "WriteProperty" -and
    $_.ObjectType -eq "5b47d60f-6090-40b2-9f37-2a4de88f3063"  # msDS-KeyCredentialLink schema GUID
}

Remove any ACEs that grant write access to non-administrative principals. Pay special attention to:

• GenericWrite ACEs on OU containing privileged accounts
• Inheritance from parent containers
• Service accounts with over-scoped AD rights

2. Audit Existing KeyCredentials

Periodically review all accounts with entries in msDS-KeyCredentialLink to identify any unexpected or orphaned credentials:

# LDAPFilter avoids parsing issues with the hyphenated attribute name
Get-ADUser -LDAPFilter "(msDS-KeyCredentialLink=*)" -Properties msDS-KeyCredentialLink |
    Select-Object Name, DistinguishedName, @{
        Name="KeyCredentialCount"
        Expression={$_."msDS-KeyCredentialLink".Count}
    }

Any entry that cannot be attributed to a known WHfB enrollment should be removed and investigated.

3. Protect Privileged Accounts with Tiering

Ensure Domain Admins and Tier 0 service accounts are isolated such that no Tier 1 or Tier 2 principal has write rights to their objects. Apply Protected Users group membership to prevent delegation-based abuse.

4. Enable Auditing

Ensure DS Access auditing is enabled via Default Domain Controllers Policy or a dedicated Audit Policy GPO:

• Audit Directory Service Changes: Success
• Audit Directory Service Access: Success and Failure

Without this, Event 5136 will not be generated.

---

Incident Response

If Shadow Credentials abuse is suspected or confirmed:

Step 1 – Contain

• Immediately reset the affected account’s password (invalidates active TGTs)
• Disable the account if it is a service account that can be taken offline temporarily
• Block the attacker-controlled principal (rotate credentials, disable account)

Step 2 – Remove the Rogue Key

# Clear all KeyCredentials from compromised account
Set-ADUser -Identity <victim_account> -Clear msDS-KeyCredentialLink

Verify the attribute is empty before re-enabling the account.

Step 3 – Scope the Compromise

• Review all accounts the attacker had write access to – check each for unauthorized msDS-KeyCredentialLink entries
• Pull Event 5136 logs for the preceding 30 days to identify all modifications
• Check 4768 logs for PKINIT-based TGT requests from affected accounts

Step 4 – Review ACLs

• Run BloodHound or similar to map all ACL paths leading to privileged account objects
• Remediate any GenericWrite / WriteProperty paths that should not exist

Step 5 – Hunt for Persistence

• Shadow Credentials survives password resets – ensure msDS-KeyCredentialLink was explicitly cleared, not just left in place after a reset
• Check for other persistence mechanisms that may have been planted during the same access window (SPNs, ACE modifications, scheduled tasks on compromised hosts)

Step 6 – Report and Harden

• Document the write-access ACE that enabled the attack
• File a remediation ticket for the ACL misconfiguration
• Update detection rules with any new attacker account identifiers discovered during triage

---

Quick Reference

Signal	Source	Threshold
5136 – msDS-KeyCredentialLink modified	Windows Security Log (DC)	Any write from non-WHfB service
MDI Alert – Suspicious KeyCredentialLink modification	Defender for Identity	Alert fires automatically
4768 + PKINIT pre-auth on non-WHfB account	Windows Security Log (DC)	Investigate any occurrence on privileged accounts
Whisker / Rubeus execution	EDR (process creation, .NET CLR events)	Block or alert on known tool hashes/signatures

---

Conclusion

Shadow Credentials abuse is a stealthy, password-independent attack path that exploits a legitimate AD feature. The attack requires only write access to msDS-KeyCredentialLink – a condition that is surprisingly common in misconfigured enterprise environments due to over-broad ACL inheritance. Defenders should prioritize DS Access auditing, MDI deployment, and regular ACL reviews on privileged accounts. Because rogue KeyCredentials survive password resets, IR teams must explicitly clear the attribute and audit all accounts the attacker could have touched before declaring an incident resolved.

---

References

1. Elad Shamir – Shadow Credentials: Abusing Key Trust Account Mapping for Account Takeover (2021): https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab
2. Whisker (C# tool for Shadow Credentials): https://github.com/eladshamir/Whisker
3. Rubeus (Kerberos toolkit, PKINIT / TGT acquisition): https://github.com/GhostPack/Rubeus
4. Microsoft Docs – msDS-KeyCredentialLink attribute: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-ada2/31906a60-e4a3-4d43-b5ad-d1d1f5e02059
5. Microsoft Defender for Identity – Shadow Credentials detection: https://learn.microsoft.com/en-us/defender-for-identity/credential-access-alerts

---