Shadow Credentials Defence Guide: Detecting and Preventing msDS-KeyCredentialLink Abuse

Any principal that can write the msDS-KeyCredentialLink attribute on an Active Directory account can add its own public key to that account and then authenticate as it, without knowing or changing the password. This technique, published in 2021 under the name Shadow Credentials, turns a single misplaced write permission into account takeover and quiet persistence that survives password resets. This guide is for Active Directory administrators, identity security engineers and detection engineers. It explains how key trust works, which permissions create the exposure, how to audit and alert on changes, how to prevent abuse without breaking Windows Hello for Business, and how to respond when an unexpected key credential appears. It goes deeper than the general permission review in the Active Directory ACL and Delegation Hygiene Guide and is written for defenders only.

Key takeaways

• The attribute is a credential store. msDS-KeyCredentialLink holds public keys that domain controllers accept for Kerberos PKINIT sign-in, so a write to it is equivalent to setting a password on the account.
• The exposure is a permission problem. GenericAll, GenericWrite or a scoped write on the attribute, held by the wrong principal on a privileged user or computer, is what makes the technique possible.
• Legitimate writers are few and known. In most estates only Microsoft Entra Connect Sync, AD FS device registration and device self-enrolment write key credentials, which makes anomaly detection practical.
• Detection needs a SACL first. Event 5136 is only generated when the object has an audit entry for writes to the attribute, and the default policy does not cover user objects.
• Clean-up must be selective. Clearing the whole attribute breaks Windows Hello for Business enrolments; remove only the entries you cannot tie to a known device and enrolment.

How key trust and Shadow Credentials work

msDS-KeyCredentialLink is a multi-valued attribute on user and computer objects, added with the Windows Server 2016 schema. Each value is a key credential: a public key with metadata such as a creation time, an owner and a device identifier. Windows Hello for Business uses it in the key trust model. In hybrid key trust, Microsoft Entra Connect Sync writes the public key of the user's Windows Hello credential to the user's msDS-KeyCredentialLink attribute in Active Directory, and domain controllers use that public key mapping when the user signs in, with no user certificate involved.

When a client signs in with a key credential, it uses Kerberos public key cryptography for initial authentication (PKINIT). The domain controller finds the matching public key on the account and issues a ticket-granting ticket. The original SpecterOps research describes the conditions the technique depends on: at least one domain controller running Windows Server 2016 or later, a domain controller certificate suitable for server authentication (environments with AD CS usually issue one automatically), and the Windows Server 2016 functional level. The same research notes that a PKINIT sign-in also causes NTLM credential material for the account to be returned in the ticket, so an attacker who plants a key can recover the account's NT hash as well.

The defensive reading is simple. Whoever can add a value to this attribute can mint a working credential for the account. The credential is independent of the password, so a password reset does not remove it, and it does not need AD CS certificate templates, so it is outside most certificate template reviews. See the Kerberos PKINIT and Certificate Mapping Guide for the certificate side of PKINIT.

Which permissions create the exposure

The technique needs no exploit, only a write path. Rights that grant it on a target account include the following.

Microsoft's group reference lists Key Admins (RID 526) and Enterprise Key Admins (RID 527) as having no default members, protected by AdminSDHolder and not safe to delegate to non-service administrators. Treat both as Tier 0. Computer objects matter as much as users: a planted key on a server's computer account gives the attacker that machine's identity, and on a domain controller's account it is a path to domain compromise. Attack path tools surface these relationships; see the BloodHound and Active Directory Attack Path Guide for how to use them defensively.

Know your legitimate writers

Detection and prevention both depend on an accurate list of the principals that are expected to write key credentials. Build it before writing any alert.

• Microsoft Entra Connect Sync: writes Windows Hello public keys to user objects in hybrid key trust. Its connector account usually has a name beginning MSOL_, which the Elastic rule uses as an exclusion.
• AD FS: the AD FS service account can act as the key provisioning service in on-premises deployments, which both the SpecterOps research and the SigmaHQ rule name as an expected writer.
• Device self-enrolment: Elastic lists Windows Autopilot or Windows Hello for Business enrolment, where a computer writes its own key credential, as a known benign source.
• Device registration objects: objects of class msDS-Device are excluded in the Elastic rule because device registration legitimately uses key credentials.
• Nothing else, by default: if you do not run Windows Hello for Business key trust at all, the expected number of writes is zero, and any write is worth an investigation.

Record each legitimate writer by SID, not by name, and record which object classes and OUs it is expected to touch. Writers should be treated as privileged non-human identities: the Entra Connect connector account and the AD FS service account sit in Tier 0 because they can mint credentials. See the Tiered Administration and Enterprise Access Model Guide.

Prevention: removing the write paths

Work from the most valuable targets outwards. The aim is that no principal outside Tier 0 and the documented provisioning services can write the attribute on any Tier 0 user or computer.

1. Inventory exposure: enumerate every ACE on privileged users, privileged groups' members, domain controllers, AD CS servers, Entra Connect and AD FS servers that grants GenericAll, GenericWrite, WriteDacl, WriteOwner or a write to msDS-KeyCredentialLink. Include inherited ACEs from OUs.
2. Remove or scope broad rights: replace GenericWrite delegations with attribute-scoped writes that exclude authentication-controlling attributes. The Active Directory Delegation page covers delegation design.
3. Empty the key groups: confirm Key Admins and Enterprise Key Admins contain only the provisioning service where one is needed, and nothing at all where key trust is not used.
4. Add a deny ACE where key trust is not used: the SpecterOps research recommends an explicit deny for Everyone on writing msDS-KeyCredentialLink for accounts that are not enrolled in key trust, especially privileged accounts. Test on a pilot OU first, and remember that a principal with WriteDacl or WriteOwner can remove the deny, so pair it with auditing.
5. Protect the provisioning servers: Entra Connect and AD FS servers hold credentials that can write key credentials at scale, so manage them as Tier 0 assets with their own admin accounts.
6. Re-check after changes: schema updates, new delegations and migration projects reintroduce broad rights. Run the exposure inventory monthly and after every directory project.

Rollback: deny ACEs and removed delegations are easy to restore if documented. Export the security descriptor of each object before changing it, and keep the export with the change record. If Windows Hello sign-in fails for a pilot group, remove the deny ACE from that OU first and confirm the user's key appears on the account again after the next sync.

Detection: auditing and alert logic

Two event streams cover most of the technique: the write of the key and the sign-in that uses it.

Microsoft's 5136 documentation notes that the event is only produced when the object's SACL audits writes, that a change often produces a Value Deleted and a Value Added pair linked by a Correlation ID, and that Value Added carries the new value. The SigmaHQ rule "Possible Shadow Credentials Added" adds that the default audit policy does not cover user objects, so a custom audit entry is often needed. The Elastic rule "Potential Shadow Credentials added to AD Object" matches 5136 for the attribute where the value begins with the B:828 key credential prefix, excludes MSOL_ writers and msDS-Device objects, and runs at high severity. Both are useful starting points in any SIEM; build exceptions from stable identifiers (writer SID, object GUID, host) rather than names.

For 4768, Microsoft lists pre-authentication types 15, 16 and 17 as the smart card types and documents Certificate Issuer Name, Serial Number and Thumbprint fields that are populated for certificate sign-in. Baseline which accounts normally sign in this way before alerting, and treat certificate-based TGT requests for service accounts, administrators and domain controller computer accounts as high value. The Active Directory Security Monitoring and Event IDs Guide covers SACL deployment and event collection across the wider directory.

Periodic sweeps

Alerts only catch new writes. Run a scheduled read-only query that lists every account with a non-empty msDS-KeyCredentialLink, the number of values, and each value's creation time and device identifier. Compare device identifiers with your Entra ID or device inventory. Accounts that should never have key credentials (service accounts, break-glass accounts, Tier 0 administrators who do not use Windows Hello, domain controllers outside known enrolment) should return no values.

Decision guidance

• If you do not use Windows Hello for Business key trust: the strongest position is a deny ACE on the attribute for privileged accounts, empty Key Admins groups and an alert on any write at all. False positives should be near zero.
• If you use hybrid key trust: allow the Entra Connect connector account only, alert on everyone else, and keep administrators on separate accounts that do not enrol Windows Hello so that a deny ACE can protect them.
• If you use cloud Kerberos trust instead: run the key credential sweep below to find key trust enrolments left from earlier deployments, and remove them once the users have moved. The Windows Hello for Business Guide covers trust model choice.
• Small organisations: start with the two events and the monthly sweep; a native SIEM rule or the Sigma rule is enough.
• Large or multi-forest estates: add exposure inventory per forest, a correlated 5136 to 4768 analytic, and include Enterprise Key Admins in forest root reviews. Trust boundaries matter; see the Active Directory Trusts and SID Filtering Guide.

Responding to an unexpected key credential

1. Preserve evidence first: export the target object's current msDS-KeyCredentialLink values, its security descriptor and the related 5136 and 4768 events with their Correlation IDs and Logon IDs.
2. Identify the writer: resolve the subject SID, its logon session (4624 by Logon ID) and source host. The writer is a compromised principal until shown otherwise.
3. Remove only the rogue entry: delete the key credential whose device identifier and creation time do not match a known enrolment. The SpecterOps research cautions that clearing all values breaks legitimate Windows Hello enrolments.
4. Treat the account's secrets as exposed: because PKINIT can return NTLM material, reset the target account's password following your normal procedure and review its recent sign-ins and ticket requests.
5. Close the write path: remove the right that allowed the write, then hunt for the same writer's activity on other objects.
6. Escalate where the target is Tier 0: a planted key on a domain controller, administrator or AD CS server is a domain compromise scenario; follow the Active Directory Domain Compromise Response Playbook.

Where identity fits

Computer accounts and service accounts are non-human identities with their own credentials, and they are frequent targets because nobody signs in as them interactively, so an extra key goes unnoticed. The provisioning accounts that write key credentials are high-privilege non-human identities as well. Include both groups in your service account inventory, with owners and expected authentication methods. See How to build a service account inventory from Active Directory.

Measuring progress

• Exposure count: number of non-Tier 0 principals with a write path to msDS-KeyCredentialLink on Tier 0 objects (target zero).
• Audit coverage: percentage of Tier 0 users and computers whose SACL audits writes to the attribute (target 100%).
• Unexplained keys: key credential values with no matching device or enrolment record at the last sweep (target zero).
• Alert precision: share of key credential alerts that are true positives or confirmed unapproved changes after tuning.
• Time to remove: median time from an unexpected key being written to its removal.
• Key group hygiene: members of Key Admins and Enterprise Key Admins beyond the documented provisioning service (target zero).

Framework mapping

Common failure patterns

• Alert rule with no SACL: the SIEM rule exists but domain controllers never generate 5136 for user objects, so it never fires.
• Allow-listing by name: exceptions for any account named like MSOL_ let an attacker who creates a similarly named account write freely; allow-list by SID.
• Template reviews only: teams that audit AD CS templates assume certificate abuse is covered, but key credentials need no template; see the AD CS Security Guide for the template side.
• Forgotten computer accounts: protections are applied to administrators, but write rights over server and domain controller computer objects are left in place.
• Clearing the attribute wholesale: responders wipe every value, break Windows Hello sign-in for the user and lose evidence of which key was rogue.
• Password reset as the fix: a reset does not remove a planted key, so the attacker keeps access unless the key itself is removed.

Practitioner checklist

• List every legitimate writer of msDS-KeyCredentialLink by SID, with the objects it should touch.
• Inventory GenericAll, GenericWrite, WriteDacl, WriteOwner and attribute writes on all Tier 0 users and computers.
• Confirm Key Admins and Enterprise Key Admins hold only the provisioning service, or nothing.
• Add a deny ACE on the attribute for privileged accounts that do not use key trust, after a pilot.
• Deploy SACLs so 5136 is generated for writes to the attribute on user and computer objects.
• Alert on Value Added writes by non-standard writers and on any write to Tier 0 objects.
• Baseline and alert on PKINIT TGT requests (4768 types 15 to 17, certificate fields) for accounts that should not use them.
• Run a monthly sweep of accounts with key credentials and reconcile device identifiers.
• Document a response runbook that removes only rogue entries and resets the target account.

Standards and references

• Microsoft Learn: 5136(S) A directory service object was modified
• Microsoft Learn: 4768(S, F) A Kerberos authentication ticket (TGT) was requested
• Microsoft Learn: Active Directory security groups
• Microsoft Learn: Windows Hello for Business hybrid key trust deployment
• Microsoft Learn: Microsoft Defender for Identity security alerts
• SpecterOps: Shadow Credentials, Abusing Key Trust Account Mapping for Account Takeover
• Elastic: Potential Shadow Credentials added to AD Object
• SigmaHQ: Possible Shadow Credentials Added

Related NHI Mgmt Group resources: Active Directory ACL and Delegation Hygiene Guide · Kerberos PKINIT and Certificate Mapping Guide · Windows Hello for Business Guide · Active Directory Security Monitoring and Event IDs Guide · BloodHound and Active Directory Attack Path Guide