Shadow credentials : comprendre et contrôler l'attribut msDS-KeyCredentialLink
L'authentification par clé de Windows Hello Entreprise a introduit dans Active Directory un attribut qui associe une clé publique à un compte. Cet attribut est devenu une cible : un attaquant capable d'y écrire peut ajouter sa propre clé et obtenir un ticket Kerberos au nom de la victime, sans toucher à son mot de passe. On parle de « shadow credentials », des identifiants fantômes.
À quoi sert msDS-KeyCredentialLink
Dans le modèle d'approbation par clé de Windows Hello Entreprise, l'appareil génère une paire de clés lors de l'inscription de l'utilisateur. La clé publique est enregistrée dans l'attribut msDS-KeyCredentialLink du compte, directement ou via la synchronisation depuis Entra ID. Lors de l'ouverture de session, l'utilisateur prouve la possession de la clé privée et le contrôleur de domaine lui délivre un TGT grâce à l'extension PKINIT de Kerberos.
Ce fonctionnement exige des contrôleurs de domaine Windows Server 2016 ou ultérieurs disposant d'un certificat adapté à l'authentification Kerberos. Les comptes d'ordinateur peuvent aussi porter des clés, notamment dans des scénarios d'inscription d'appareils.
Le principe de l'abus
L'attribut ne contient qu'une clé publique : il ne révèle rien en lecture. Le risque est en écriture. Un compte disposant d'un droit d'écriture sur cet attribut d'un utilisateur ou d'un ordinateur peut y ajouter une clé dont il détient la partie privée, puis s'authentifier en PKINIT comme la victime. Dans ce contexte, le protocole peut également restituer le hachage NT du compte, ce qui ouvre d'autres usages.
La technique est discrète : le mot de passe de la victime ne change pas, l'utilisateur légitime ne remarque rien, et la clé ajoutée peut rester en place longtemps comme mécanisme de persistance. Elle s'appuie sur les mêmes faiblesses que les autres abus d'ACL : GenericAll, GenericWrite ou écriture de propriété sur l'objet cible. Elle peut aussi découler d'un relais NTLM vers LDAP si le contrôleur de domaine accepte des connexions LDAP non signées.
Qui peut écrire l'attribut
Par défaut, les groupes Administrateurs de clés et Administrateurs de clés Entreprise disposent de droits sur cet attribut, respectivement pour le domaine et la forêt. Le compte utilisé par la synchronisation d'annuaire hybride reçoit aussi des droits d'écriture lorsque certaines fonctionnalités sont activées. Enfin, un compte d'ordinateur peut, dans certaines conditions, écrire sa propre clé.
À ces droits prévus s'ajoutent tous les droits hérités d'une délégation trop large : un groupe du support disposant de GenericWrite sur une OU d'utilisateurs peut, sans le savoir, attribuer des identifiants fantômes à tous ses comptes.
Même sans Windows Hello. La technique fonctionne dès lors que les contrôleurs de domaine acceptent PKINIT, que vous utilisiez Windows Hello Entreprise ou non. Ne pas utiliser la fonctionnalité ne vous protège pas.
Détecter
- Inventaire. Listez les comptes dont
msDS-KeyCredentialLinkest renseigné. Une clé sur un compte d'administration, un compte de service ou un utilisateur qui n'utilise pas Windows Hello est suspecte. - Cohérence. Les clés légitimes sont liées à un appareil inscrit. Une clé sans appareil correspondant, ou créée à une date sans rapport avec un déploiement, mérite une investigation.
- Journalisation. Configurez l'audit des modifications du service d'annuaire et une liste SACL sur l'attribut pour générer un événement à chaque modification. Toute écriture par un compte autre que ceux attendus doit alerter.
Durcir
- Réduisez les droits d'écriture sur les comptes sensibles, en commençant par les comptes de niveau 0 et les contrôleurs de domaine.
- Maintenez les groupes Administrateurs de clés et Administrateurs de clés Entreprise vides ou limités aux comptes strictement nécessaires, et surveillez-les comme des groupes privilégiés.
- Protégez le compte de synchronisation hybride au niveau 0.
- Exigez la signature LDAP et la liaison de canal pour fermer la voie du relais.
- Nettoyez les clés orphelines après validation avec les équipes chargées des postes.
Ce qu'un audit vérifie
- les comptes privilégiés portant une valeur dans
msDS-KeyCredentialLink; - les titulaires de droits d'écriture sur cet attribut pour les objets sensibles ;
- la composition des groupes Administrateurs de clés ;
- l'existence d'une journalisation des modifications de l'attribut ;
- la configuration de la signature LDAP et de la liaison de canal.