Ariovis

Active Directory attack path · Alternative credentials / PKINIT

Shadow Credentials: understand, detect and prevent the Active Directory attack

Shadow Credentials does not involve stealing or resetting a target's password. The attack abuses a legitimate Windows mechanism that associates cryptographic material with an Active Directory identity: the msDS-KeyCredentialLink attribute, introduced with Windows Server 2016, which can notably hold the public keys used in some Windows Hello for Business scenarios.

If an identity holds permissions to modify this attribute on a user or a computer, it can add a Key Credential it controls. In an environment supporting PKINIT, the matching private key can then be used to request a Kerberos Ticket Granting Ticket as the target, without the legitimate password being known or changed. The mechanism barely disturbs the legitimate user, but leaves detectable traces in Active Directory.

The real question

Who can write msDS-KeyCredentialLink on your sensitive objects, and which asset do those objects lead to?

Understand your Active Directory attack paths
Category
Alternative credentials / PKINIT
Central attribute
msDS-KeyCredentialLink
Abused mechanism
Key Credentials · Kerberos PKINIT authentication
Windows signal
Event ID 5136 — provided auditing is configured

The attack path, step by step

Each step depends on what the environment actually allows. Nothing in this sequence is automatic.

  1. 01Compromised identity
  2. 02Right allowing modification of the target object
  3. 03Key Credential written to msDS-KeyCredentialLink
  4. 04PKINIT authentication
  5. 05Kerberos TGT obtained as the target
  6. 06Use of that identity's privileges
  7. 07Lateral movement / possible escalation towards a critical asset

The truly dangerous point is therefore not only the existence of msDS-KeyCredentialLink. The path starts with a control relationship: an ACL, a delegation or an overly broad right allowing one identity to modify another's credential. This is exactly the logic of the parent page: an isolated technique is not yet an attack path.

Why this technique appeals to an attacker

Three properties explain its place in Active Directory attack paths.

  • High stealth

    The target's password is not reset. The user or service can therefore keep working normally while a second authentication mechanism has been added.

  • Persistence

    A password rotation does not automatically remove the added Key Credential. Persistence ends when the illegitimate value is removed or made unusable.

  • Escalation and lateral movement

    The impact depends entirely on the target. Adding a Key Credential to a low-privileged account has nothing like the impact of taking over a sensitive service account, a critical computer or a Tier 0 identity.

A technique that is not universally exploitable

Several conditions must be met, notably:

  • the Key Credential feature being present in the Active Directory environment;
  • a Kerberos environment allowing PKINIT authentication;
  • a KDC holding the cryptographic material required for PKINIT;
  • an attacking identity able, directly or indirectly, to modify msDS-KeyCredentialLink on the target.

The presence of AD CS can make PKINIT available in many environments, but a vulnerable PKI is not a prerequisite for Shadow Credentials, and neither is ESC1. AD CS and Shadow Credentials are two distinct topics that meet around PKI and Kerberos authentication.

The real topic: ACLs

A Shadow Credential is first and foremost an Active Directory object-control attack. An audit must therefore look for the identities able to modify msDS-KeyCredentialLink, directly or through broader rights.

Finding a value in msDS-KeyCredentialLink does not explain the risk: understanding who can write it, and which asset that target then leads to, is what reconstructs the attack path.

Categories of rights to analyse

  • WriteProperty on the attribute concerned;
  • GenericWrite;
  • GenericAll;
  • rights allowing the DACL to be modified or the object to be taken over;
  • historical or inherited delegations;
  • membership and governance of the groups entitled to administer keys.

This list is not exhaustive: the analysis must cover effective rights and their inheritance.

Detecting a Shadow Credential

The main signal lives in domain controller logs.

Main event

Event ID 5136 — A directory service object was modified

Filter in particular: AttributeLDAPDisplayName = msDS-KeyCredentialLink

Event ID 5136 is not automatically proof of Shadow Credentials, and it is only generated if Active Directory auditing is correctly configured.

You need in particular

  • Audit Directory Service Changes;
  • SACLs suited to the monitored objects and attributes;
  • centralised collection of domain controller events.

For each suspicious change, correlate at least

  • the identity that made the change;
  • the target object;
  • the object class;
  • the date and context;
  • the workstation or source when available;
  • the OpCorrelationID when available;
  • the Kerberos activity and authentications that follow.
Alerting on every 5136 is not enough: Windows Hello for Business, Microsoft Entra Connect and other legitimate provisioning mechanisms can modify msDS-KeyCredentialLink. Build a baseline of legitimate writers and workflows, then identify the changes that fall outside it.

Prevention: remove the conditions of the path

Prevention targets the relationships that make the write possible, not just the attribute.

  1. 01

    Review ACLs

    Identify who actually holds rights allowing msDS-KeyCredentialLink to be modified on users and computers.

  2. 02

    Reduce delegations

    Remove unnecessary GenericWrite, GenericAll and WriteProperty, especially on privileged accounts and sensitive objects.

  3. 03

    Govern key administrators

    Check the uses and memberships of the groups or accounts legitimately allowed to manage Key Credentials, without blindly removing rights needed by Windows Hello for Business or synchronisation mechanisms.

  4. 04

    Inventory Key Credentials

    Check the values present on sensitive accounts and on objects that should not normally use key-based authentication.

  5. 05

    Monitor over time

    Log changes and distinguish operations from known enrolment workflows from unexpected modifications.

To extend this reading to your own directory, a free Active Directory security diagnostic is available.

If a Shadow Credential is discovered

A simple password change is not enough. The response must include:

  • identifying the unauthorised Key Credential;
  • preserving the evidence needed for the investigation;
  • removing the malicious value concerned;
  • analysing the authentications and actions performed since it was added;
  • finding the right or delegation that allowed the write;
  • fixing that permission path;
  • checking that other objects have not undergone the same kind of change.

These two levels are not the same: removing the Shadow Credential closes the persistence, while fixing the ACL that allowed it breaks the attack path and prevents the same identity from writing another key tomorrow.

Never blindly clear every msDS-KeyCredentialLink value: some may be legitimate.

Break the paths leading to critical assets

Shadow Credentials shows why an Active Directory analysis cannot be limited to hunting for one isolated technique. Our approach covers the whole path, within the Identity and Active Directory security service.

  • audit of accounts, groups, delegations and sensitive rights;
  • attack path mapping;
  • prioritisation by the assets actually reachable;
  • hardening;
  • monitoring;
  • remediation.
Understand and remove your Active Directory attack pathsBack to Active Directory attack paths

Related techniques

Other techniques from the same collection. They are not necessarily successive steps: each fits into an attack path depending on what the environment allows.

Technical sources

References used to support this page.