par Nilaa Maharjan, Security Research
Les tests d’intrusion internes nécessitent souvent des spécialistes de la sécurité pour tenter d’extraire les mots de passe de la mémoire des machines infectées. Si les identifiants récupérés sont hachés, le testeur peut utiliser l’approche pass-the-hash pour se déplacer latéralement au sein du réseau afin d’atteindre ses objectifs. Cette technique était fréquemment utilisée par le passé et reste un vecteur de menace toujours valable pour les machines non mises à jour.
Si le testeur est capable d’extraire des identifiants en clair de la mémoire ou de déchiffrer les hachages collectés, alors il pourra s’authentifier auprès de ressources et de services réseau supplémentaires tels qu’Outlook, les applications Web essentielles et les portails d’appareil, entre autres.
Dans cet article, nous allons présenter plus en détail WDigest, comment il est utilisé pour extraire les identifiants en clair de la mémoire et comment un analyste peut utiliser Logpoint pour détecter, atténuer et répondre à toute tentative d’attaque liée à WDigest.
Mais d’abord, un petit rappel du contexte s’impose.
Qu’est-ce que WDigest ?
L’authentification WDigest est un protocole de défi/réponse qui était principalement utilisé pour l’authentification LDAP et Web dans Windows Server 2003. Il a été introduit pour la première fois dans Windows XP et a été activé par défaut sur les systèmes Windows. Il permet aux clients de communiquer des identifiants en clair aux applications HTTP (Hypertext Transfer Protocol) et SASL (Simple Authentication Security Layer).
Microsoft a mis en cache les identifiants en clair dans la RAM de Windows une fois les utilisateurs connectés à leurs postes de travail pour rendre la procédure d’authentification plus pratique pour les utilisateurs finaux. Les postes de travail utilisaient ces identifiants mis en cache pour authentifier les services HTTP et SASL sans obliger les utilisateurs à saisir leurs identifiants encore et encore. Les identifiants en clair s’authentifient via les échanges HTTP et SASL.
Par exemple, un client demande un accès, le serveur d’authentification envoie un défi au client et ce dernier répond en chiffrant sa réponse avec une clé dérivée du mot de passe. Pour vérifier si l’utilisateur a le bon mot de passe, la réponse chiffrée est comparée à une réponse stockée au préalable sur le serveur d’authentification. C’est à ce niveau que se trouve le nœud du problème.
Microsoft propose une présentation plus détaillée du fonctionnement de WDigest et de certaines de ses applications ici.
Pourquoi WDigest est-il si important ?
Nous devrions tous donner la priorité à l’audit de sécurité Windows. Il est essentiel pour la protection de n’importe quel système de bien comprendre comment vos systèmes endpoint sont configurés et quelles portes d’entrée ces derniers peuvent exposer à des utilisateurs indésirables. C’est à ce moment-là que WDigest entre en jeu. Il est important de garder à l’esprit que WDigest conserve les mots de passe en clair et en mémoire. Ainsi, si une personne malveillante accède à un système endpoint et est capable d’exécuter un programme comme Mimikatz, elle pourra alors obtenir non seulement les hachages actuellement stockés en mémoire, mais également les mots de passe en clair pour les comptes associés.
Il ne s’agit pas seulement d’une pratique de test standard utilisée par l’équipe rouge (red team), mais aussi d’une tactique souvent utilisée par des adversaires comme lors des campagnes de ransomware KNOTWEED ou PHOSPHORUS.
Cette réalité est ou, du moins, devrait être une préoccupation majeure car les adversaires peuvent désormais non seulement utiliser une attaque de type pass-the-hash, mais ils ont également le nom d’utilisateur et le mot de passe pour essayer de se connecter à des services comme Exchange et à des sites Web internes, etc.
Un scénario d’attaque classique
Mimikatz a été utilisé dans des situations réelles pour voler les identifiants au niveau de la mémoire au cours de ces dernières années. Par conséquent, plusieurs solutions antivirus ont créé des signatures pour empêcher cet utilitaire de s’exécuter sur les PC. Cependant, il existe plusieurs façons d’éviter ces signatures antivirus, notamment l’exécution du programme en mémoire ou l’obfuscation de l’utilitaire.
Une fois que l’attaquant a obtenu l’accès à un système interne au sein d’une entreprise, Mimikatz peut être utilisé pour récupérer les identifiants au niveau de la mémoire. Ces derniers peuvent être récupérés sous un format haché, en clair ou dans les deux formats.
Si l’attaquant a la chance d’obtenir ces identifiants en clair, le cassage des hachages ne sera pas nécessaire et ces derniers offriront un accès direct aux ressources internes, permettant ainsi aux attaquants d’atteindre leurs objectifs.
Cependant, il est important de noter qu’avant que la commande ne puisse être exécutée, l’attaquant doit disposer de droits d’administration.
Voici un exemple de ce qu’un attaquant verrait lors de la récupération des identifiants en mémoire avec un outil comme Mimikatz. L’utilisateur “HanSolo” a utilisé un bureau distant pour se connecter à la machine en question, et comme la configuration spécifique autour de WDigest a été effectuée de manière non sécurisée, non seulement il voit un hachage NTLM pour le compte, mais aussi le mot de passe en clair “Password99!”.
Exemple de ce qu’un attaquant verrait lors de la récupération des identifiants en mémoire. Pour obtenir plus d’informations, parcourez le guide d’adsecurity présentant brièvement l’utilisation de Mimikatz.
Comprendre le registre WDigest est utile pour les analystes offensifs et défensifs.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest
- Si la valeur UseLogonCredential est sur 0, WDigest ne stockera pas les identifiants en mémoire.
- Si la valeur UseLogonCredential est sur 1, WDigest stockera les identifiants en mémoire.
Comme lors de la campagne de ransomware PHOSPHOROUS lancée par le groupe DEV-0270, après avoir compromis l’appareil et obtenu des privilèges d’administrateur, les acteurs malveillants de ce groupe ont utilisé des LOLBIN pour mener à bien leur vol d’identifiants, car cette technique évite d’avoir à utiliser des outils courants et susceptibles d’être détectés et bloqués par les antivirus et les solutions EDR (Endpoint Detection and Response). L’un de ces processus commence par l’activation de WDigest dans le registre, se traduisant ainsi par un stockage des mots de passe en clair sur l’appareil et faisant gagner du temps à l’acteur en lui évitant d’avoir à cracker le hachage du mot de passe.
Nous avons remarqué que deux variantes de cette commande étaient utilisées, toutes les deux avec la valeur de registre UseLogonCredential sur 1.
Dans les systèmes où le registre WDigest est manquant ou supprimé.
"Set-ItemProperty -Force
-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest'
-Name "UseLogonCredential"
-Value '1'"Dans les systèmes où le registre WDigest est configuré pour ne pas stocker de mots de passe en clair.
"reg" add
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v
UseLogonCredential /t REG_DWORD /d 1 /fL’acteur utilise ensuite rundll32.exe et comsvcs.dll avec sa fonction MiniDump intégrée pour récupérer les mots de passe à partir du LSASS dans un fichier dump. La commande pour accomplir cette tâche spécifie souvent la sortie pour enregistrer les mots de passe provenant du LSASS. Le nom du fichier est également inversé pour échapper aux détections (ssasl.dmp) :
powershell.exe" /c Remove-Item -Path C:\windows\temp\ssasl.pmd
-Force -ErrorAction Ignore;
rundll32.exe C:\windows\System32\comsvcs.dll,
MiniDump (Get-Process lsass).id C:\windows\temp\ssasl.pmd full | out-host;
Compress-Archive C:\windows\temp\ssasl.pmd C:\windows\temp\[name].zipIdentification de l’utilisation de Wdigest
D’un point de vue défensif, le suivi des changements concernant le chemin du registre devrait fournir un indice fort indiquant qu’un acte malveillant est en cours. Même avec sysmon, vous devez définir un chemin de suivi pour qu’il puisse commencer à journaliser (logging) les modifications dans le registre.
L’utilisation de WDigest peut être identifiée à deux endroits différents : au niveau des logs de votre contrôleur de domaine, ou bien au niveau des logs de votre serveur (chaque serveur doit être vérifié).
Avec Logpoint, nous fournissons un fichier de configuration sysmon personnalisé et un exemple Nxlog. La ligne ci-dessous concerne WDigest en particulier.
\Control\SecurityProviders\WDigestUne fois le chemin ou le fichier sysmon configuré dans le système, une règle d’alerte prête à l’emploi LP_Wdigest Registry Modification peut être utilisée pour suivre les modifications apportées au chemin du registre.
norm_id=WindowsSysmon event_id=13
target_object="*WDigest\UseLogonCredential" -user IN EXCLUDED_USERS
Une règle d’alerte préconfigurée suit les modifications apportées au chemin d’accès au registre.
Comme pour le processus dump, LP_Process Dump via Rundll32 et Comsvcs se déclencheront lorsque l’attaquant ou le testeur tentera de récupérer les mots de passe à partir du LSASS dans un fichier dump.
label="Process" label=Create
"process"="*\rundll32.exe"
command IN ["*comsvcs.dll*#24*", "*comsvcs.dll*MiniDump*" ] -user IN EXCLUDED_USERSToutes les nouvelles règles mises à jour et existantes peuvent être téléchargées depuis Logpoint Service Desk.
REMARQUE : Par défaut dans Windows 8.1 et Windows Server 2012 R2 et les versions ultérieures, la mise en cache des identifiants en mémoire pour WDigest est désactivée (la valeur UseLogonCredential est par défaut sur 0 lorsque l’entrée de registre n’est pas présente).
Le changement de comportement observé lorsque la valeur UseLogonCredential est sur 0 impliquera que les identifiants seront requis plus fréquemment lors de l’utilisation de WDigest.
Comme il s’agit d’un problème de longue date et très ancien, Microsoft a publié un correctif en 2014 qui a effectivement désactivé le stockage en mémoire des mots de passe WDigest.
De plus, dans une note traitant de la résolution de ce problème, Microsoft recommande aux utilisateurs d’éliminer les mots de passe en clair de la mémoire.
Suppression des identifiants en clair du LSASS
Cette mise à jour empêche chaque SSP Microsoft dans LSASS, à l’exception de WDigest, de stocker le mot de passe de l’utilisateur en clair. WDigest stocke toujours le mot de passe en clair de l’utilisateur car il ne peut pas fonctionner sans ce dernier (Microsoft ne veut pas perturber les configurations client existantes en diffusant une mise à jour qui désactivera cette fonctionnalité). Microsoft recommande aux utilisateurs de consulter les logs de leur contrôleur de domaine concernant les connexions d’authentification WDigest (instructions fournies ci-dessous). Si l’authentification WDigest n’est pas utilisée, les clients peuvent appliquer le FixIt trouvé dans l’article de la base de connaissances (KB) pour désactiver WDigest. Cette action éliminera toutes les identifiants en clair de la mémoire LSASS.
Il est important de réaliser que même si les identifiants en clair ne seront plus stockés, le hachage NT et la clé TGT/Session de Kerberos seront toujours stockés et sont considérés comme des identifiants (sans identifiants équivalents stockés en mémoire, l’authentification unique – single sign-on – sera impossible). De plus, même si les identifiants en clair ne sont plus stockés en mémoire, un attaquant pourra utiliser d’autres techniques telles que les keyloggers pour récupérer les mots de passe en clair. L’élimination des mots de passe en clair de la mémoire est utile et réduit les risques, mais elle ne permet pas de stopper systématiquement les attaquants.
Pour Windows 7, 8, Server 2008 R2 et Server 2012, vous devez installer la mise à jour de sécurité mentionnée ci-dessus, puis définir la clé de registre suivante sur 0.
Définir la clé de registre sur 0 permet de réduire les risques liés à WDigest.
Chemin: HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersWDigestUseLogonCredential
Le moyen le plus simple de le faire serait d’utiliser la stratégie de groupe, mais un script rapide fonctionne également:
reg add
HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v
UseLogonCredential /t REG_DWORD /d 0Une fois que vous avez installé la mise à jour de sécurité et la mise à jour de la clé de registre sur tous vos serveurs, vous pouvez vous assurer que vous l’avez fait avec succès en interrogeant le registre pour vérifier qu’il existe bien et n’est pas défini sur 1.
reg query
HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v
UseLogonCredentialREMARQUE : Les deux modifications ci-dessus déclencheront également l’alerte lorsqu’une modification sera apportée au chemin spécifié.
Par défaut, les versions ultérieures de Windows (8.1+ et 2012 R2+) ne nécessitent pas la mise à jour de sécurité ou la définition de la valeur sur 0, car la valeur par défaut est 0 lorsqu’elle n’est pas présente. Cependant, vous devez vous assurer qu’aucune modification manuelle n’a été effectuée pour la remettre sur 1.
Utilisez ce tableau pour vous aider à décider si vous devez prendre des mesures au niveau de vos systèmes endpoint.
Correction avec les playbooks Logpoint SOAR
Lors de la détection de traces d’exploitation, les analystes doivent isoler l’hôte sur lequel l’attaque a lieu via un playbook et lancer un playbook de réponse aux incidents.
La détection de l’exploitation est simple et transparente car Logpoint est une solution SIEM+SOAR unifiée qui utilise une alerte (événement SIEM) pour déclencher automatiquement un playbook SOAR. Vous pouvez configurer un playbook pour qu’il s’exécute lorsqu’une modification a été apportée au chemin du registre WDigest. Le playbook supprime l’utilisateur d’Active Directory et modifie le mot de passe de l’utilisateur à l’aide d’un générateur de mot de passe aléatoire.
Le playbook se déclenche lorsqu’une modification a été apportée au chemin du registre WDigest, lançant ainsi automatiquement un ensemble d’actions pour investiguer et répondre à cette modification.
Le playbook lance une réponse qui désactive l’utilisateur et réinitialise le mot de passe.
En se basant sur la politique de l’entreprise et les procédures de l’équipe de réponse aux incidents, un manuel d’investigation collectera autant de données que possible et générera ensuite un rapport.
Vous pouvez également générer des rapports à partir du playbook pour documenter les étapes de l’investigation.
Conclusion
Une configuration liée à WDigest pourrait entraver la sécurité de votre environnement, en particulier au niveau des systèmes endpoint, en permettant à un attaquant de voler les identifiants en clair au niveau de la mémoire. Il existe des mesures que vous pouvez prendre pour remédier à cette situation et vous assurer que vos systèmes endpoint et vos identifiants soient davantage sécurisés. La mise à jour de sécurité de Microsoft (KB2871997) traite le problème sur les anciennes versions de Windows, tandis que les versions plus récentes sont censées être sécurisées par défaut. La vérification du registre sur tous vos systèmes endpoint Windows concernant le paramètre WDigest doit être une priorité, car la perte d’identifiants peut entraîner la perte de données sensibles. Pour ce faire, vous pouvez notamment lancer des requêtes en ligne de commande sur tous vos hôtes, mais un moyen plus rapide consiste à automatiser ce type d’audit au niveau de vos systèmes endpoint et à regrouper les données dans un rapport facile à utiliser.
