Identifiants en cache, WDigest et exposition des secrets

Credential Guard et la protection LSA durcissent la manière dont Windows protège les secrets qu'il détient. Ce guide porte sur la quantité de secrets qu'il détient au départ. Une poignée de paramètres déterminent si une machine compromise livre un mot de passe en clair, un hash cassable de chaque utilisateur de domaine récent, ou des mots de passe enregistrés pour des partages de fichiers et des applications web. La plupart ne coûtent rien à modifier et cassent très peu de choses, à condition de savoir quoi surveiller.

Tout ce qui suit s'applique aussi aux appareils où Credential Guard ne peut pas fonctionner : matériel ancien, VM sans virtualisation imbriquée et contrôleurs de domaine. C'est le socle de la série Protection des identifiants.

Ce que Windows conserve, et où

Étape 1 : réduire les ouvertures de session en cache

Lorsqu'un utilisateur de domaine ouvre une session interactive, Windows stocke un vérificateur afin que ce même utilisateur puisse se reconnecter plus tard sans contrôleur de domaine. Par défaut, les 10 derniers utilisateurs sont conservés. Sur un poste partagé ou un serveur, cela représente la liste de chaque technicien du support et de chaque administrateur récent, chacun sous forme de hash cassable hors ligne.

Le paramètre est Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive logon: Number of previous logons to cache (in case domain controller is not available). Il écrit CachedLogonsCount (un REG_SZ, pas un DWORD) sous HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

Les référentiels de sécurité Microsoft ne configurent pas ce paramètre ; la documentation de Microsoft indique 0 comme contre-mesure et suggère 2 pour les ordinateurs des utilisateurs finaux et les appareils mobiles, et les benchmarks CIS recommandent 4 ou moins. Choisissez la valeur la plus basse que vos utilisateurs peuvent supporter, et testez un portable en le déconnectant de tous les réseaux avant d'ouvrir une session.

Deux points connexes :

• Les membres de Protected Users ne laissent jamais de vérificateur en cache : une raison de plus de placer les administrateurs humains dans ce groupe (voir modèle en tiers et Protected Users).
• Abaisser la valeur n'efface pas immédiatement les vérificateurs existants. Les entrées sont écrasées au fur et à mesure des nouvelles connexions. Sur les serveurs où des vérificateurs d'administrateurs existent déjà, la valeur 0 empêche toute nouvelle mise en cache ; prévoyez de renouveler les mots de passe des comptes privilégiés qui ont été mis en cache sur des machines peu fiables.

Étape 2 : verrouiller WDigest en position désactivée

WDigest est un ancien package d'authentification HTTP/SASL qui avait besoin du mot de passe en clair de l'utilisateur en mémoire. Depuis Windows 8.1 et Windows Server 2012 R2, il ne stocke plus de mot de passe en clair par défaut, mais ce comportement dépend toujours d'une seule valeur de registre qu'un attaquant disposant de droits d'administration peut inverser :

Key:   HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
Value: UseLogonCredential  (REG_DWORD) = 0

Une fois cette valeur à 1, chaque ouverture de session interactive suivante place le mot de passe en clair dans la mémoire de LSASS, où des outils comme Mimikatz peuvent le lire. C'est une étape de persistance bien connue dans les intrusions : inverser la valeur, verrouiller l'écran, attendre que l'utilisateur le déverrouille.

Fixez explicitement la valeur à 0 au lieu de vous fier à la valeur par défaut. Le fichier SecGuide.admx du Security Compliance Toolkit l'expose sous le nom WDigest Authentication (disabling may require KB2871997) dans Computer Configuration > Policies > Administrative Templates > MS Security Guide ; réglez-le sur Disabled. La référence à la KB ne concerne que Windows 7 et Server 2008 R2. Microsoft a retiré ce paramètre du référentiel de sécurité Windows 11 24H2 car la stratégie a été dépréciée avec cette version : sur les builds actuelles, vous pouvez donc aussi imposer directement la valeur de registre avec les préférences de stratégie de groupe ou Intune, et continuer à la surveiller dans tous les cas.

Credential Guard empêche aussi Digest d'utiliser les identifiants enregistrés, mais une valeur 0 imposée par stratégie protège les machines où il ne fonctionne pas.

Étape 3 : effacer les identifiants après la déconnexion

Après la déconnexion d'un utilisateur, LSASS peut conserver ses identifiants en mémoire pendant un certain temps si des handles vers la session restent ouverts. Windows 8.1 et ultérieur les effacent au bout de 30 secondes. La valeur est :

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: TokenLeakDetectDelaySecs  (REG_DWORD) = 30

Sur les versions actuelles de Windows, c'est le comportement intégré : la définir sert surtout à empêcher quelqu'un de l'augmenter. Le référentiel de sécurité Microsoft ne l'exige pas ; définissez-la là où votre standard de durcissement ou votre audit le demande, et laissez-la à 30 secondes.

Notez que cela ne concerne que les sessions fermées. Un compte privilégié qui reste connecté à un serveur en RDP reste en mémoire tant que la session existe. Définissez des limites de durée pour les sessions RDP et fermez les sessions déconnectées, comme expliqué dans le durcissement RDP.

Étape 4 : ne plus enregistrer les mots de passe réseau

Credential Manager stocke les mots de passe que les utilisateurs (ou les applications) choisissent d'enregistrer : lecteurs mappés avec « Mémoriser mes informations d'identification », connexions RDP, Outlook, certaines applications métier. Ils sont protégés par DPAPI avec la clé de l'utilisateur, ce qui signifie que tout code s'exécutant sous l'identité de l'utilisateur peut les déchiffrer.

Vérifiez ce qui est enregistré sur un appareil, pour l'utilisateur courant :

cmdkey /list
vaultcmd /listcreds:"Windows Credentials" /all

La stratégie Network access: Do not allow storage of passwords and credentials for network authentication (Security Options) définit DisableDomainCreds = 1 sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Une fois activée, Windows ne stocke plus d'identifiants de domaine pour l'authentification réseau dans Credential Manager.

Celle-ci doit être testée, et c'est pourquoi de nombreux référentiels la réservent aux tiers de haute sécurité :

• Les tâches planifiées configurées avec Run whether user is logged on or not et un mot de passe stocké cessent de fonctionner. Convertissez-les pour qu'elles s'exécutent en SYSTEM, avec un gMSA ou un compte de service géré ailleurs.
• Les identifiants RDP et de lecteurs mappés enregistrés ne sont plus conservés. Les utilisateurs doivent les saisir à nouveau, ce qui est généralement le résultat souhaité.

Activez-la d'abord sur les serveurs et les postes d'administration sécurisés, là où les identifiants de domaine enregistrés sont les plus dangereux et où les tâches planifiées sont les plus faciles à inventorier. Pour le RDP en particulier, activez aussi Do not allow passwords to be saved sous Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client.

Étape 5 : appliquer par script et vérifier

Pour un état des lieux rapide sur une machine ou via un script de correction :

$lsa = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
[pscustomobject]@{
  CachedLogonsCount        = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon").CachedLogonsCount
  UseLogonCredential       = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -ErrorAction SilentlyContinue).UseLogonCredential
  TokenLeakDetectDelaySecs = (Get-ItemProperty $lsa).TokenLeakDetectDelaySecs
  DisableDomainCreds       = (Get-ItemProperty $lsa).DisableDomainCreds
  NoLMHash                 = (Get-ItemProperty $lsa).NoLMHash
}

Imposez les valeurs par stratégie de groupe ou Intune plutôt que par script, afin qu'elles soient réappliquées si quelque chose les modifie. Dans Intune, les paramètres Security Options figurent dans le catalogue de paramètres sous Local Policies Security Options ; pour les valeurs sans paramètre natif, un OMA-URI personnalisé avec un ADMX importé ou un script de correction fonctionne.

Ce qui casse

• L'ouverture de session hors ligne sur les portables si le nombre d'ouvertures de session en cache est à 0.
• Les tâches planifiées avec mot de passe stocké et les identifiants enregistrés une fois DisableDomainCreds activé.
• Les très anciennes applications qui utilisent l'authentification HTTP Digest avec l'authentification unique Windows. Elles sont rares ; elles demanderont un mot de passe.

Vérifier

1. Ouvertures de session en cache utilisées. L'événement Security 4624 avec le Logon Type 11 (CachedInteractive) indique qu'un utilisateur s'est connecté à partir d'un vérificateur en cache. Sur les serveurs, il ne doit jamais apparaître une fois la valeur à 0.
2. Altération de WDigest. Déclenchez une alerte sur les écritures dans UseLogonCredential avec Sysmon Event 13 ou l'audit du registre (événement Security 4657, qui nécessite une SACL sur la clé). Tout passage à 1 est un indicateur de compromission très fiable.
3. Contenu de Credential Manager. Exécutez la vérification cmdkey /list sur un échantillon de serveurs et de postes d'administration après l'activation de DisableDomainCreds ; les entrées de domaine enregistrées doivent disparaître une fois que les utilisateurs se sont réauthentifiés.
4. Rapport de parc. Centralisez la sortie du script de l'étape 5 et suivez les appareils hors standard.

Liste de contrôle

• Ouvertures de session en cache : 0 sur les serveurs et les bornes, 1 à 2 sur les portables
• Comptes d'administration humains dans Protected Users pour qu'ils ne soient jamais mis en cache
• UseLogonCredential explicitement à 0 par stratégie, modifications sous alerte
• TokenLeakDetectDelaySecs à 30 là où votre standard l'exige
• DisableDomainCreds activé sur les serveurs et les PAW, tâches planifiées converties
• Client RDP non autorisé à enregistrer les mots de passe
• Événements 4624 de type 11 examinés sur les serveurs

Aucun de ces paramètres n'est spectaculaire, mais ensemble ils réduisent la quantité de matériel réutilisable sur chaque machine. Associés à la surveillance de WDigest et à Credential Guard, ils laissent à un attaquant bien moins de choses à récolter.