Shadow Credentials et abus de msDS-KeyCredentialLink

Que sont les Shadow Credentials ?

Shadow Credentials est le nom courant, dans la communauté Active Directory, d’un chemin d’attaque qui abuse du matériel d’authentification par clé associé à un compte, le plus souvent via l’attribut msDS-KeyCredentialLink. Le point important n’est pas le nom. Le point important est qu’un principal peut recevoir un chemin d’authentification supplémentaire par clé publique, distinct de son mot de passe.

Dans un déploiement légitime, msDS-KeyCredentialLink est utilisé par Windows Hello for Business et par des scénarios de confiance par clé. Microsoft documente que, dans certains déploiements hybrides Windows Hello for Business, la clé publique de l’utilisateur peut être synchronisée depuis Microsoft Entra ID vers Active Directory et écrite dans l’attribut msDS-KeyCredentialLink de l’objet utilisateur. Microsoft documente aussi le comportement Key Trust pour Kerberos PKINIT : un KDC qui utilise Active Directory comme base de comptes doit confirmer que le compte possède la même clé publique dans msDS-KeyCredentialLink.

Un cas d’abus Shadow Credentials existe lorsqu’un attaquant ou un administrateur non autorisé peut ajouter ou conserver une key credential inattendue sur un objet utilisateur ou ordinateur, puis utiliser la clé privée correspondante pour s’authentifier comme ce compte via un flux fondé sur les clés. Ce n’est pas du password spraying, du Kerberoasting, du DCSync ou un Golden Ticket. C’est plus proche d’un chemin de persistance et d’usurpation adossé aux ACL : l’objet directory du compte a été modifié afin qu’une autre clé puisse satisfaire les contrôles d’authentification.

Cet article utilise le terme Shadow Credentials parce qu’il est largement reconnu par les défenseurs et auditeurs Active Directory. La documentation Microsoft décrit plutôt les mécanismes sous-jacents comme Windows Hello for Business, Key Trust, PKINIT et msDS-KeyCredentialLink. Cette distinction est importante : l’attribut lui-même n’est pas malveillant. Une valeur non nulle dans msDS-KeyCredentialLink peut être normale dans des environnements qui utilisent Windows Hello for Business, des flux liés à FIDO ou des fonctions de confiance par clé. L’objectif défensif est d’identifier les key credentials non autorisées, orphelines, inattendues ou présentes sur des comptes privilégiés, pas de supprimer aveuglément toutes les valeurs.

Pour le contexte plus large des chemins d’attaque identité, consultez Chemins d'Attaque AD : Mauvaises Configurations en Chaîne et Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin. Les Shadow Credentials appartiennent à la même famille de problèmes, car la cause racine est souvent une capacité d’écriture excessive sur un objet d’identité.

Fonctionnement de msDS-KeyCredentialLink

Stockage légitime des key credentials

msDS-KeyCredentialLink stocke des données de key credential sur un objet Active Directory. Les Microsoft Open Specifications décrivent KEYCREDENTIALLINK_BLOB comme la structure stockée dans la partie binaire de l’attribut DN-Binary msDS-KeyCredentialLink. Microsoft documente aussi des contraintes pour l’ajout de valeurs sur des objets ordinateur, notamment le fait que la portion binaire doit être un KEYCREDENTIALLINK_BLOB bien formé, que l’usage doit être KEY_USAGE_NGC et que la source doit être KEY_SOURCE_AD pour cette opération documentée sur compte ordinateur.

Cette spécification concernant les objets ordinateur ne doit pas être généralisée à tous les scénarios sur objets utilisateur. Pour les objets utilisateur, la source opérationnelle la plus claire est la documentation Windows Hello for Business : après le provisionnement d’un credential Windows Hello for Business par un utilisateur dans certains environnements hybrides, la clé publique de l’utilisateur peut être synchronisée vers AD et écrite dans msDS-KeyCredentialLink. La documentation de support Microsoft fournit aussi un script pour énumérer les objets utilisateur ayant des valeurs msDS-KeyCredentialLink non nulles et extraire des champs comme Source, Usage, DeviceID et KeyID.

Chemin d’authentification Key Trust

Le côté authentification repose sur la cryptographie à clé publique. La RFC 4556 définit PKINIT comme l’usage de la cryptographie à clé publique pour l’échange initial d’authentification Kerberos. La documentation PKCA de Microsoft décrit l’implémentation Windows de PKINIT et de Key Trust. Dans un cas Key Trust, le KDC peut rechercher un compte par clé publique, et les implémentations utilisant Active Directory doivent confirmer que cette même clé publique est présente dans msDS-KeyCredentialLink.

En langage défensif pratique, l’attribut donne à AD un moyen d’associer un compte à du matériel de clé utilisable pour l’authentification. La clé privée doit rester protégée sur l’appareil légitime ou dans le conteneur de credential. La clé publique est ce qu’AD peut utiliser pour vérifier que la tentative d’authentification correspond à une clé attendue. Si une clé non autorisée est ajoutée à un compte de forte valeur, le compte obtient un chemin d’authentification supplémentaire que les défenseurs peuvent ne pas voir lors des revues classiques de mots de passe.

Les réinitialisations de mot de passe ne suffisent pas

C’est pour cela que les Shadow Credentials sont différentes d’une compromission fondée sur le mot de passe. Une réinitialisation de mot de passe traite un mot de passe volé. Elle ne supprime pas nécessairement une valeur key credential non autorisée du compte. Microsoft documente que la connexion et le déverrouillage Windows Hello for Business utilisent une clé ou un certificat, et que le changement du mot de passe du compte utilisateur n’affecte pas ce comportement de connexion ou de déverrouillage. En réponse à incident, cela signifie qu’une rotation de mot de passe peut être nécessaire mais insuffisante si l’objet compte contient encore du matériel de clé non autorisé.

Pourquoi Key Trust change le modèle d’attaque

Le durcissement Active Directory traditionnel se concentre souvent sur les mots de passe, l’exposition NTLM, les tickets de service Kerberos et l’appartenance aux groupes privilégiés. Ces sujets restent importants, mais Key Trust ajoute une autre question : qui peut modifier l’objet compte ou le matériel de clé associé à ce compte ?

Si un utilisateur ou un service dispose d’une permission effective d’écriture sur msDS-KeyCredentialLink, ou peut modifier la DACL ou le propriétaire de l’objet pour obtenir cette capacité d’écriture, le risque ne se limite plus à la connexion au compte. Il devient un contrôle de l’objet d’identité. L’événement Windows 4662 met en évidence Write Property, WRITE_DAC et WRITE_OWNER comme types d’accès importants à surveiller sur les objets AD. Ces droits ne sont pas automatiquement malveillants, mais sur des utilisateurs privilégiés, des comptes de service, des contrôleurs de domaine ou des OU d’administration, ils méritent une attention beaucoup plus forte.

C’est aussi pourquoi les Shadow Credentials sont un problème de chemin d’attaque. Le point de départ peut être un groupe helpdesk délégué, un compte de service avec des droits larges sur les objets, une permission héritée sur une OU ou une délégation administrative obsolète. Le résultat peut être un chemin d’authentification persistant vers un compte privilégié. Si le défenseur ne vérifie que l’appartenance aux groupes, il peut manquer la permission au niveau objet qui a rendu le chemin possible. L’imbrication de groupes peut aussi masquer qui reçoit effectivement le contrôle délégué ; consultez Imbrication Dangereuse de Groupes AD : Chemins vers Domain Admin lorsque des permissions héritées sont en jeu.

Comparez ce sujet à Délégation Kerberos : Non Contrainte à RBCD. L’abus de délégation dépend des paramètres de délégation et des relations d’identité de service. Les Shadow Credentials dépendent du matériel de clé et du contrôle en écriture sur l’objet. Les deux sujets sont proches de Kerberos, mais ils ne relèvent pas du même mode d’échec et ne doivent pas être fusionnés dans un article Kerberos générique.

Prérequis d’un abus

Un scénario Shadow Credentials exige généralement toutes les conditions suivantes :

Condition	Signification défensive
Le compte cible supporte un chemin d’authentification par clé pertinent	L’environnement utilise ou accepte Key Trust, une authentification adossée à des certificats ou des modèles Windows Hello for Business reposant sur la validation de clé publique.
Un principal non autorisé peut ajouter ou préserver du matériel key credential	La permission dangereuse peut être une écriture directe sur l’attribut ou un contrôle plus large de l’objet qui permet d’obtenir cette écriture.
L’attaquant contrôle la clé privée correspondante	AD stocke le côté public. L’authentification ne réussit que si le client peut prouver la possession de la clé privée correspondante.
L’activité n’est pas détectée ou corrigée	La valeur reste sur l’objet et peut survivre à un nettoyage limité au mot de passe.

Ce qui n’est pas une vulnérabilité en soi

Ces prérequis doivent être lus avec prudence. La présence de Windows Hello for Business ne signifie pas que l’environnement est vulnérable en soi. La présence de msDS-KeyCredentialLink ne signifie pas une compromission en soi. Le risque apparaît lorsque les permissions sur les objets compte, l’inventaire des key credentials et la télémétrie d’authentification montrent qu’une key credential inattendue a été ajoutée ou utilisée.

Nuance sur les objets ordinateur

Les objets ordinateur méritent une nuance séparée. Microsoft documente l’authentification par clé publique des appareils joints au domaine et explique que les appareils Windows modernes peuvent provisionner une clé publique liée à leur compte ordinateur lorsqu’un contrôleur de domaine Windows Server 2016 ou plus récent est disponible. Les défenseurs doivent donc s’attendre à trouver du matériel de clé légitime sur certains comptes ordinateur. Le contrôle n’est pas de viser « zéro key credential partout ». Le contrôle est la propriété exacte, la correspondance avec les appareils attendus et une capacité d’écriture restreinte.

Nuance sur les comptes privilégiés

Les comptes privilégiés exigent un standard plus strict. La documentation Microsoft sur le dual enrollment Windows Hello for Business décrit les permissions Key Admins sur msDS-KeyCredentialLink et les considérations AdminSDHolder pour les utilisateurs et groupes protégés. C’est un signal fort pour les défenseurs : tout workflow qui active intentionnellement la connexion par clé pour des identités privilégiées doit être documenté, limité et surveillé, car il touche exactement la surface de contrôle que des attaquants chercheraient à abuser.

La chaîne d’attaque

Un modèle défensif sûr de chaîne d’attaque ressemble à ceci :

Étape	Ce qui se passe	Ce que les défenseurs doivent vérifier
1. Découverte des permissions	L’attaquant identifie un compte ou une OU où il peut affecter les attributs ou le descripteur de sécurité de l’objet cible.	Vérifier les permissions effectives sur les utilisateurs de forte valeur, les comptes ordinateur, les comptes de service et les OU d’administration.
2. Ajout de key credential	Une valeur key credential inattendue est ajoutée à `msDS-KeyCredentialLink`.	Surveiller l’événement 5136 pour le nom LDAP `msDS-KeyCredentialLink`, surtout les opérations `Value Added`.
3. Authentification par clé	L’attaquant tente de s’authentifier avec la clé privée correspondant à la clé publique ajoutée.	Corréler les événements 4768, les patterns de pré-authentification PKINIT ou de type smart card, les hôtes source et la sensibilité du compte.
4. Mouvement latéral ou persistance	Le compte est utilisé pour l’accès, l’escalade ou la persistance alors qu’une rotation de mot de passe seule peut ne pas supprimer le chemin par clé.	Supprimer les key credentials non autorisées, corriger les permissions objet et valider qu’aucune authentification par clé inattendue ne continue.

L’article ne fournit volontairement pas de commandes d’exploitation propres à des outils. Les défenseurs n’ont pas besoin d’un chemin d’exploitation copiable pour comprendre l’échec de contrôle. Le point clé est qu’une modification d’objet directory peut créer un chemin d’authentification que l’hygiène classique des mots de passe ne supprime pas.

Cette chaîne explique aussi pourquoi les Shadow Credentials apparaissent souvent à côté d’autres risques AD. Un compte privilégié obsolète, une ACL héritée dangereuse ou un modèle de délégation faible peut créer les conditions d’écriture de key credential. Pour l’exposition des comptes, consultez Comptes Obsolètes et Sur-Privilégiés dans AD. Pour le contexte de persistance Kerberos, comparez avec les mécaniques différentes de Golden Ticket : Les Clés de Votre Domaine.

Détection

La détection des Shadow Credentials doit être fondée sur la corrélation. Aucun événement Windows unique ne prouve la technique complète. Une détection utile combine les preuves de modification directory, le contexte des permissions objet, le comportement d’authentification et l’inventaire légitime Windows Hello for Business.

Signal	Source	Ce que cela peut prouver	Limite
Valeur `msDS-KeyCredentialLink` ajoutée ou modifiée	Événement 5136, Directory Service Changes	L’attribut de l’objet a changé, et l’événement peut exposer le nom LDAP, le type d’opération, le DN de l’objet et l’ID de corrélation.	Cela ne prouve pas que le changement est malveillant. Un enrollment WHfB ou des flux appareil peuvent être légitimes.
Écriture sur des objets sensibles	Événement 4662, SACL sur objets AD	Un principal a effectué ou tenté des opérations comme `Write Property`, `WRITE_DAC` ou `WRITE_OWNER` sur des objets ou propriétés surveillés.	Nécessite une configuration correcte de l’audit et des SACL. Sans SACL, les preuves peuvent être absentes.
Demande de TGT avec pré-authentification de type clé publique	Événement 4768 sur contrôleurs de domaine	Un TGT a été demandé ; l’événement expose le type de pré-authentification et des champs liés aux certificats dans les scénarios pertinents.	C’est une télémétrie d’authentification, pas une preuve qu’une clé malveillante a été ajoutée. Corréler avec 5136/4662 et le contexte du compte.
Inventaire des key credentials non nulles	Requête AD ou parsing de type support Microsoft	Quels utilisateurs ont des valeurs `msDS-KeyCredentialLink` et ce que montrent des champs comme source, usage, DeviceID et KeyID.	L’inventaire doit être comparé aux enregistrements connus WHfB/FIDO/device enrollment.
Permissions effectives inattendues	Revue ACL AD	Quels utilisateurs, groupes ou services peuvent écrire l’attribut ou modifier la sécurité de l’objet.	Une permission est une exposition, pas une preuve d’exploitation.

Télémétrie de modification directory

Pour 5136, Microsoft recommande de surveiller le champ LDAP Display Name lorsqu’on suit les modifications d’un attribut AD spécifique. Pour ce sujet, le nom pertinent est msDS-KeyCredentialLink. Priorisez les événements Value Added, puis corrélez par DN d’objet, compte ayant effectué le changement, poste source lorsqu’il est disponible et opérations directory proches avec le même ID de corrélation.

Pour 4662, priorisez les utilisateurs de forte valeur, groupes privilégiés, OU d’administration, comptes de service et objets ordinateur représentant une infrastructure sensible. Microsoft met en avant les types d’accès Write Property, WRITE_DAC et WRITE_OWNER comme importants à surveiller. Pour une chasse Shadow Credentials, ils sont particulièrement pertinents lorsqu’ils concernent un objet d’identité privilégié ou un GUID de propriété mappé à msDS-KeyCredentialLink.

Corrélation d’authentification

Pour 4768, traitez l’événement comme un contexte d’authentification. Microsoft documente que 4768 est généré lorsque le KDC émet un TGT et que l’événement inclut un champ Pre-Authentication Type. Les types associés à une authentification smart card ou par clé publique peuvent aider à identifier des patterns d’authentification par clé, mais ils doivent être corrélés avec les changements directory et le comportement de connexion attendu. Si un compte privilégié montre soudainement une authentification par clé après une modification inattendue de l’attribut, l’histoire combinée est beaucoup plus forte que chaque événement isolé.

Questions d’inventaire

Une chasse pratique doit répondre à ces questions :

Quels utilisateurs privilégiés, comptes de service et comptes ordinateur ont des valeurs msDS-KeyCredentialLink non nulles ?
Ces valeurs sont-elles attendues pour un déploiement documenté Windows Hello for Business, FIDO ou authentification appareil ?
Chaque entrée correspond-elle à un appareil connu, un utilisateur attendu, un KeyID attendu et une source attendue ?
Qui peut écrire l’attribut ou modifier la DACL ou le propriétaire de l’objet ?
Des valeurs key credential ont-elles été ajoutées peu avant une authentification Kerberos inhabituelle ou une activité administrative ?

Pour une couverture plus large des événements, utilisez Supervision Sécurité AD : Événements Clés comme checklist complémentaire, mais gardez la corrélation Shadow Credentials spécifique. Une supervision Kerberos générique ne suffit pas.

Remédiation

La remédiation doit être ciblée. Effacer aveuglément msDS-KeyCredentialLink sur tout le domaine peut casser des scénarios légitimes Windows Hello for Business ou d’authentification appareil. L’approche la plus sûre consiste à valider la propriété, supprimer les valeurs non autorisées et corriger les permissions qui ont permis l’apparition de la valeur.

Inventaire et triage

Commencez par l’inventaire. Énumérez les utilisateurs et ordinateurs avec des valeurs msDS-KeyCredentialLink non nulles, puis parsez les valeurs en champs comme Source, Usage, DeviceID et KeyID lorsque c’est possible. La documentation de support Microsoft montre ce type d’analyse pour les objets utilisateur et explique que le certificat correspondant doit être trouvé dans le magasin de certificats personnel de l’utilisateur sur l’ordinateur ayant l’identifiant appareil correspondant. Dans un environnement géré, cet inventaire doit aussi être comparé aux enregistrements d’appareils Microsoft Entra, aux enregistrements Windows Hello for Business et à votre processus d’accès privilégié.

Séparez ensuite l’attendu de l’inattendu. Les valeurs attendues doivent correspondre à des utilisateurs, appareils et conceptions d’authentification connus. Les valeurs inattendues incluent les entrées sur des comptes qui ne devraient pas utiliser d’authentification par clé, les entrées ne correspondant pas à un appareil approuvé, les entrées ajoutées par un principal non approuvé, les entrées apparues après une activité administrative suspecte ou les valeurs trouvées sur des comptes privilégiés sans processus documenté de dual enrollment ou de workstation privilégiée.

Supprimer uniquement les valeurs non autorisées

Pour les entrées confirmées non autorisées, supprimez la valeur spécifique de l’objet. Ne vous reposez pas uniquement sur la réinitialisation du mot de passe. Une réinitialisation peut rester nécessaire si le compte a été compromis autrement, mais elle ne prouve pas à elle seule que le matériel d’authentification par clé a été supprimé d’AD.

Corriger le chemin de permission

Après le nettoyage des valeurs, corrigez les permissions. Vérifiez les droits directs et hérités qui permettent d’écrire msDS-KeyCredentialLink, d’écrire largement des propriétés de l’objet, de modifier la DACL ou de changer le propriétaire de l’objet. Retirez les délégations larges sur les comptes privilégiés, OU d’administration, OU de comptes de service et comptes ordinateur lorsqu’elles ne sont pas nécessaires. Si un workflow helpdesk ou automation doit légitimement gérer l’enrollment Windows Hello for Business, limitez-le précisément et surveillez-le explicitement.

Pour les comptes privilégiés, revoyez Key Admins et les groupes associés. La documentation Microsoft dual enrollment décrit les permissions Key Admins sur msDS-KeyCredentialLink et les considérations AdminSDHolder pour les comptes protégés. Si l’enrollment Windows Hello for Business de comptes privilégiés est autorisé, documentez les appareils approuvés, les comptes autorisés et la manière dont les nouvelles valeurs key credential sont approuvées. S’il n’est pas autorisé, les comptes privilégiés ne doivent pas accumuler silencieusement des key credentials.

Enfin, durcissez le modèle opérationnel. Utilisez une administration par tiers ou une isolation administrative équivalente afin que des postes moins fiables et des groupes délégués larges ne puissent pas modifier des objets d’identité de forte valeur. Séparez l’administration des identités privilégiées des comptes de productivité quotidiens. Revoyez périodiquement les chemins d’attaque, car ce problème est généralement causé par une chaîne de droits plutôt que par une appartenance évidente à un seul groupe.

Validation après nettoyage

La validation doit prouver à la fois le nettoyage et la reprise de contrôle.

Étape de validation	Critère de réussite
Relancer l’inventaire des key credentials	Seules les valeurs `msDS-KeyCredentialLink` attendues restent, et chacune correspond à un utilisateur, appareil, source, usage et KeyID documenté.
Revérifier les permissions objet	Aucun principal non autorisé ne peut écrire l’attribut, écrire largement des propriétés, modifier la DACL ou changer le propriétaire sur les comptes de forte valeur.
Revoir 5136 après nettoyage	Aucune opération `Value Added` inattendue ne se produit pour `msDS-KeyCredentialLink` sur les comptes privilégiés ou ordinateurs sensibles.
Revoir 4662 après nettoyage	Les activités Write Property et security descriptor sur les objets surveillés correspondent aux workflows admin approuvés.
Revoir 4768 après nettoyage	L’authentification par clé pour les comptes sensibles ne se produit que depuis des utilisateurs, appareils et scénarios attendus.
Tester les flux légitimes WHfB/FIDO	Les utilisateurs approuvés peuvent toujours se connecter lorsque l’entreprise s’appuie volontairement sur Key Trust.

Si un incident a impliqué un compte privilégié, la validation doit aussi inclure la revue de l’activité aval. Vérifiez les connexions administratives, changements d’appartenance à des groupes, changements de configuration de services, modifications GPO, nouveaux certificats et tout mouvement ultérieur qui aurait pu utiliser l’identité récupérée. Les Shadow Credentials peuvent être la méthode d’accès, mais pas nécessairement l’objectif final.

Comment EtcSec détecte les expositions liées

EtcSec ne doit pas associer cet article à un type de vulnérabilité inexact si le catalogue ne contient pas d’entrée directe Shadow Credentials ou msDS-KeyCredentialLink. L’exposition liée correspond néanmoins au modèle d’audit Active Directory d’EtcSec : permissions objet dangereuses, exposition de comptes privilégiés, chemins ACL hérités et trous de monitoring autour des changements d’objets AD.

En pratique, une revue EtcSec peut aider à identifier les conditions qui rendent ce chemin d’attaque viable : principals avec contrôle d’écriture excessif sur des objets utilisateur ou ordinateur, comptes privilégiés non isolés, chemins ACL dangereux vers des identités administratives et lacunes de monitoring sur les changements directory. C’est le bon cadrage. Les Shadow Credentials ne sont pas une faiblesse Kerberos générique ; c’est un chemin d’abus Key Trust créé par le contrôle d’objet.

Contrôles associés

Les contrôles Shadow Credentials doivent être liés à la propriété des identités, pas seulement à la supervision Kerberos.

Contrôle	Pourquoi c’est important
Inventorier `msDS-KeyCredentialLink` sur les utilisateurs et ordinateurs	Établit quels chemins d’authentification par clé existent avant un incident.
Restreindre l’écriture sur les attributs key credential	Empêche des principals non autorisés d’ajouter du nouveau matériel d’authentification.
Surveiller 5136 sur `msDS-KeyCredentialLink`	Capture les changements au niveau attribut lorsque l’audit Directory Service Changes et les SACL sont configurés.
Surveiller 4662 sur les objets d’identité sensibles	Expose les opérations Write Property, DACL et ownership lorsque les SACL sont en place.
Corréler 4768 avec les changements directory	Aide à relier le comportement d’authentification par clé aux modifications récentes d’objets.
Protéger les comptes privilégiés avec une isolation administrative	Réduit le risque qu’une compromission de niveau inférieur puisse modifier des objets d’identité de forte valeur.
Revoir Key Admins et le comportement AdminSDHolder	Évite que des chemins d’administration WHfB légitimes deviennent des chemins incontrôlés d’écriture de clés privilégiées.

Ces contrôles soutiennent aussi le durcissement AD plus large. Si vous construisez une revue structurée, combinez cet article avec Audit de sécurité Active Directory : checklist pratique, puis priorisez d’abord les objets d’identité privilégiés et les OU sensibles.

Shadow Credentials : abus de msDS-KeyCredentialLink dans Active Directory