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

What Is 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.

How WDigest activé Works

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.

The Attack Chain

É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.

É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.

Detection

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.

Pourquoi ce réglage revient souvent

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, quel script 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é.

Remediation

💡 Quick Win: si un hôte n’a pas de dépendance justifiée au stockage WDigest, désactivez-le et vérifiez que la valeur ne revient pas via une vieille baseline, une image de référence ou un script de dépannage.

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

Validate Before You Close the Finding

Le changement ne doit pas être considéré comme terminé parce que la valeur a été mise à 0 une fois. Validez l’état du registre sur des systèmes représentatifs, confirmez que le chemin applicatif supposé critique fonctionne toujours si une dépendance légitime existe, et assurez-vous que la stack de détection alerterait si UseLogonCredential était réactivé plus tard. C’est typiquement le genre de contrôle qui semble trivial jusqu’au jour où l’incident prouve qu’il avait été silencieusement annulé des mois plus tôt.

Il vaut aussi la peine de vérifier le volet identité. Si les 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.

Où vérifier en priorité la dérive WDigest

La revue WDigest devrait commencer par les systèmes où des identités à forte valeur se connectent réellement. Le support Microsoft explique qu’après l’update liée à l’Advisory 2871997, le comportement par défaut varie selon la génération Windows. Sur Windows 7, Windows Server 2008 R2, Windows 8 et Windows Server 2012, UseLogonCredential reste par défaut à 1 après installation de l’update, sauf si l’organisation le force à 0. À l’inverse, sur Windows 8.1, Windows Server 2012 R2 et versions ultérieures, la mise en cache WDigest est désactivée par défaut quand l’entrée de registre n’existe pas. Cette différence explique pourquoi d’anciens modèles d’image, scripts de support ou baselines héritées réintroduisent encore le risque.

Concrètement, il faut donc vérifier séparément les postes d’administration, les jump hosts et les serveurs où des admins ouvrent des sessions interactives. Si le build moderne reste sain mais qu’une image legacy utilisée pour l’administration remet UseLogonCredential à 1, le risque réel reste concentré sur les hôtes qui contiennent les secrets les plus intéressants.

Un autre contrôle utile consiste à comparer la baseline, l’image de référence et la configuration locale des hôtes déjà en production. Quand ces trois sources ne définissent pas le même état du registre, le problème est souvent organisationnel plutôt que technique. Identifier quel script, quel pipeline d’image ou quelle exception remet la clé est souvent la partie la plus importante de la remédiation.

La revue doit aussi rester cohérente avec la guidance Microsoft sur Protected Users. Le groupe ne corrige pas WDigest à lui seul, mais Microsoft précise que ses membres ne peuvent pas s’authentifier avec NTLM, Digest Authentication ou CredSSP. Vérifier WDigest sans examiner où se connectent les comptes privilégiés et s’ils bénéficient déjà de cette protection laisse souvent passer l’essentiel du risque.

How EtcSec Detects This

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é.

ℹ️ Note: EtcSec signale automatiquement le stockage d’identifiants WDigest pendant les revues Active Directory afin d’aider les équipes à prioriser les hôtes où une compromission locale exposerait les identités les plus sensibles.

Official References

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

Related Reading

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.