WDigest activé : pourquoi des identifiants en clair réapparaissent dans LSASS

Que signifie WDigest activé ?

WDigest activé signifie qu'un système stocke à nouveau du matériel d'authentification réutilisable lié à WDigest dans LSASS alors que l'objectif des équipes de défense devrait être de réduire l'exposition des secrets en mémoire, pas de la rouvrir. La guidance Microsoft autour de l'Advisory 2871997 visait précisément à diminuer le vol de crédentiels sur les systèmes Windows joints au domaine. L'un des points de durcissement les plus pratiques est de s'assurer que le paramètre UseLogonCredential ne réactive pas le stockage de secrets WDigest en mémoire.

Le risque compte parce que WDigest n'est pas seulement un ancien protocole oublié. La documentation protocolaire Microsoft indique que la structure supplementalCredentials peut contenir Primary:WDigest, décrit comme des empreintes cryptographiques du mot de passe en clair pour le protocole Digest. Si une équipe réactive volontairement le stockage WDigest sur un poste ou un serveur, elle augmente la probabilité qu'une compromission locale expose des secrets réutilisables qui n'auraient pas dû être présents dans LSASS.

C'est pourquoi WDigest activé doit généralement être traité avec Sécurité des mots de passe AD : erreurs de configuration qui comptent, Mots de passe dans les champs de description AD : détection et nettoyage et Comptes obsolètes et trop privilégiés dans AD. Dans les trois cas, le vrai sujet n'est pas seulement un paramètre faible, mais le fait que du matériel d'authentification réutilisable soit plus facile à voler et à rejouer qu'attendu.

Comment ça fonctionne

Microsoft documente UseLogonCredential sous la ruche WDigest comme le contrôle qui empêche WDigest de stocker des identifiants en mémoire. Quand ce paramètre est réactivé, du matériel d'authentification redevient accessible à du code capable d'atteindre LSASS avec des privilèges suffisants.

La logique de durcissement est simple :

• si le stockage WDigest est désactivé, un attaquant qui compromet l'hôte doit trouver d'autres secrets réutilisables
• s'il est activé, l'hôte offre une surface de vol de crédentiels plus riche que nécessaire

L'Advisory 2871997 de Microsoft met aussi en avant le groupe Protected Users. Ses membres ne peuvent pas s'authentifier avec NTLM, Digest Authentication ou CredSSP, et leurs mots de passe ne sont pas mis en cache de la même manière sur les systèmes pris en charge. Ce groupe ne remplace pas la désactivation de WDigest, mais poursuit le même objectif : réduire la quantité de secrets réutilisables disponibles après compromission d'un poste.

La chaîne d'attaque

Étape 1 - Obtenir un accès local admin ou SYSTEM sur un hôte Windows

WDigest activé n'est généralement pas le vecteur initial. Il devient dangereux une fois que l'attaquant possède déjà du code avec des privilèges élevés sur une machine. À ce stade, la différence entre un poste durci et un poste faible est la quantité de secrets réutilisables encore présents dans LSASS.

C'est pourquoi ce problème apparaît souvent aux côtés de Kerberoasting : comment les attaquants cassent les mots de passe des comptes de service et AS-REP Roasting : récupérer des hashes sans identifiants. Les attaquants enchaînent les opportunités de crédentiels. Si un hôte livre des secrets réutilisables, le reste de l'attaque devient moins coûteux.

Étape 2 - Lire LSASS et récupérer des secrets exploitables

Quand le réglage est activé, l'attaquant n'a pas besoin que tout l'environnement soit cassé. Il lui suffit d'une machine sur laquelle la compromission locale peut être transformée en accès aux identifiants.

# Vérification défensive du réglage WDigest
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential

Pour l'équipe de défense, le point important n'est pas l'outil de dump, mais le fait que l'hôte conserve davantage de secrets en mémoire que nécessaire.

Étape 3 - Réutiliser les identifiants sur d'autres systèmes

Si l'identifiant volé appartient à un admin, à un opérateur helpdesk ou à un compte de service à portée large, l'attaquant peut se déplacer beaucoup plus vite vers d'autres postes ou vers des chemins d'escalade AD. C'est pour cela que WDigest activé est rarement un constat isolé : il amplifie la portée des autres erreurs de contrôle d'accès.

La même logique apparaît dans Chemins d'attaque Active Directory vers Domain Admin : toute configuration qui transforme un hôte compromis en source de secrets réutilisables raccourcit le chemin vers quelque chose de plus critique.

Détection

Vous n'avez pas besoin d'intuition pour détecter cette exposition. Microsoft fournit déjà le point de contrôle principal : la valeur de registre UseLogonCredential. Une revue sérieuse devrait aussi vérifier si les admins les plus sensibles sont encore hors du groupe Protected Users et si votre télémétrie détecte suffisamment vite une modification de registre ou un accès suspect à LSASS.

# Vérification rapide de WDigest sur un hôte
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential

# Vérifier la composition du groupe Protected Users
Get-ADGroupMember 'Protected Users'

La vérification registre est la plus rapide, mais ne devrait pas être la seule. Pendant une revue d'incident, confirmez si le réglage est présent sur des postes d'administration, jump servers ou serveurs où se connectent des comptes à forte valeur. Une seule exception sur le mauvais hôte peut réduire à néant un travail de durcissement des crédentiels par ailleurs solide.

Remediation

Un chemin de remédiation propre reste généralement court :

1. Inventorier où UseLogonCredential est activé. Commencez par les postes admin, les jump servers et les serveurs sensibles.
2. Désactiver le réglage. Sur les systèmes pris en charge, empêchez WDigest de stocker des secrets en mémoire en positionnant UseLogonCredential à 0 ou en revenant à l'état par défaut de la baseline.
3. Revoir les dépendances legacy. Si une équipe affirme avoir besoin de WDigest, exigez un flux applicatif concret et un plan de retrait de l'exception.
4. Protéger les identités à haute valeur. Utilisez Protected Users lorsque c'est opérationnellement possible pour les comptes privilégiés.
5. Surveiller la dérive. Déclenchez des alertes sur les modifications du chemin de registre WDigest et sur les accès suspects à LSASS.

# Exemple de remédiation locale sur un hôte Windows
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential -Type DWord -Value 0

Si votre environnement contient encore de vieux scripts de baseline ou des modèles de durcissement post-build, revoyez-les avec attention. WDigest revient parfois non pas par conception, mais à cause d'un script oublié que quelqu'un a copié des années plus tôt pour « corriger » un problème applicatif. C'est pourquoi l'état du registre, la baseline de build et la dépendance de production réelle doivent être vérifiés ensemble.

Validez le changement avant de le considérer réglé

La séquence de validation la plus sûre est simple : confirmez l'état du registre sur des systèmes représentatifs, confirmez que le chemin applicatif à risque fonctionne toujours si une dépendance métier réelle existe, et confirmez que votre stack de détection déclenchera un signal si quelqu'un réactive UseLogonCredential plus tard. C'est typiquement le genre de contrôle qui semble trivial jusqu'au jour où un incident prouve qu'il avait été silencieusement annulé six mois plus tôt.

Il vaut aussi la peine de vérifier le volet identité. Si vos admins les plus sensibles continuent de se connecter sur des surfaces trop larges et ne bénéficient pas de protections plus fortes, une seule exception WDigest peut peser beaucoup plus lourd qu'attendu. C'est pourquoi ce constat appartient à une revue d'accès privilégié plus large, pas seulement à une checklist de durcissement de postes.

Pourquoi les exceptions WDigest reviennent dans le parc

WDigest revient rarement parce qu'une équipe souhaite consciemment un niveau de sécurité plus faible. Il revient plus souvent par habitude de dépannage : un ingénieur recopie un vieux workaround, une image de référence conserve la valeur, ou un script de support est réutilisé sans revalider l'ancienne dépendance applicative. Ce schéma est important, car il change la manière de traiter le risque. La question n'est pas seulement « la clé existe-t-elle ? », mais aussi « quel standard de build, quelle automatisation ou quel propriétaire continue de la réintroduire ? ».

Dans un environnement mature, cette revue doit inclure les postes d'administration, jump hosts et tout serveur où des admins se connectent de manière interactive. Si le registre est propre sur les postes standard mais encore faible là où vivent les identités à plus haute valeur, le risque résiduel reste élevé. C'est aussi pourquoi Comment auditer la sécurité Active Directory : checklist pratique pour les équipes internes et Supervision sécurité Active Directory : événements qui comptent sont des lectures complémentaires utiles : elles aident à relier une faiblesse de registre locale à la question plus large de savoir où vivent réellement les identifiants privilégiés.

Comment EtcSec détecte ce problème

EtcSec relie ce sujet directement à WDIGEST_ENABLED. Le point utile n'est pas simplement de savoir si la clé de registre existe quelque part, mais si les hôtes qui comptent le plus conservent encore du matériel d'authentification réutilisable dans LSASS et si l'exception a un propriétaire identifié.

Références officielles

• Microsoft Security Advisory 2871997: Update to Improve Credentials Protection and Management
• Microsoft Support article for the UseLogonCredential policy and WDigest credential storage behavior
• Microsoft protocol documentation for supplementalCredentials and Primary:WDigest

Lectures associées

Relisez ce sujet avec Sécurité des mots de passe AD : erreurs de configuration qui comptent, Mots de passe dans les champs de description AD : détection et nettoyage, Comptes obsolètes et trop privilégiés dans AD, Comment auditer la sécurité Active Directory : checklist pratique pour les équipes internes et Supervision sécurité Active Directory : événements qui comptent. Ces thèmes permettent de relier une clé de registre locale à la question plus large des secrets réutilisables encore présents dans l'environnement.