Qu’est-ce que le Pass-the-Hash ?
Le Pass-the-Hash est une méthode d’authentification qui réutilise du matériel d’authentification dérivé de NTLM volé à la place du mot de passe en clair de l’utilisateur. En pratique, l’attaquant dérobe du matériel réutilisable sur un système Windows compromis puis l’utilise pour accéder à un autre hôte ou service au nom de cet utilisateur.
Dans cet article, le périmètre est volontairement restreint : Windows, Active Directory, NTLM et mouvements latéraux. Il ne s’agit pas d’un article générique sur le vol d’identifiants. Le sujet ici est le modèle d’exploitation précis qui rend le Pass-the-Hash pertinent dans un environnement AD d’entreprise : un poste ou un serveur compromis, du matériel d’authentification réutilisable présent sur ce système, puis un second hôte qui accepte encore une authentification fondée sur NTLM.
Cette distinction compte, car le Pass-the-Hash est souvent mélangé à plusieurs techniques proches :
- Le password spraying teste des mots de passe courants sur de nombreux comptes et ne nécessite pas de hashes volés.
- Le Pass-the-Ticket réutilise des tickets Kerberos volés, pas du matériel dérivé de NTLM.
- L’Overpass-the-Hash part de matériel dérivé de NTLM pour obtenir du matériel Kerberos puis bascule vers un accès fondé sur Kerberos.
- Le Kerberoasting demande des tickets de service puis les casse hors ligne pour retrouver les mots de passe de comptes de service.
Le Pass-the-Hash est donc un problème distinct : l’attaquant dispose déjà d’un matériel d’authentification réutilisable et n’a pas besoin du mot de passe en clair pour continuer à progresser.
Comment fonctionne le Pass-the-Hash ?
MITRE classe le Pass-the-Hash dans T1550.002, sous-technique de Use Alternate Authentication Material. L’idée de base est simple : après une connexion utilisateur, Windows et certains flux d’authentification conservent du matériel d’authentification, et ce matériel peut parfois être réutilisé si un attaquant parvient à le voler.
Dans les environnements Windows, NTLM reste la raison principale pour laquelle le Pass-the-Hash est encore opérationnellement pertinent. Si une cible distante accepte NTLM, l’attaquant peut parfois présenter du matériel dérivé de NTLM volé et s’authentifier sans jamais connaître le mot de passe en clair. C’est précisément pour cela que la réduction de l’usage de NTLM et la réduction des endroits où des identifiants réutilisables atterrissent sont des défenses centrales.
En pratique, le matériel réutilisable provient le plus souvent de l’un de ces chemins :
- La mémoire LSASS sur un poste ou un serveur compromis après la connexion de la victime.
- Les ruches SAM / SECURITY pour du matériel lié aux comptes locaux de la machine.
- Des comptes administrateur locaux partagés réutilisés sur plusieurs systèmes.
- Un dumping d’identifiants après que l’attaquant a déjà obtenu des privilèges d’administration locale ou une exécution équivalente sur un hôte.
La documentation Microsoft sur Credential Guard est utile ici, car elle explique précisément ce que la fonctionnalité protège : les secrets NTLM, Kerberos et Credential Manager sont isolés par la virtualisation au lieu de rester uniquement exposés dans l’espace mémoire habituel de LSASS. Cela n’élimine pas tous les risques de vol d’identifiants, mais cela modifie nettement la surface d’attaque des chaînes PtH classiques.
Préconditions pour qu’une attaque Pass-the-Hash réussisse
Le Pass-the-Hash ne fonctionne généralement que lorsque plusieurs conditions sont réunies.
1. L’attaquant a déjà compromis un hôte Windows
Le Pass-the-Hash est rarement le point d’entrée initial. L’attaquant commence en général par du phishing, un malware, un accès distant exposé, une faiblesse sur les privilèges locaux ou un autre vecteur d’intrusion. PtH devient ensuite une technique de mouvement latéral.
2. Du matériel d’authentification réutilisable est présent sur le système compromis
C’est la condition centrale. Si des comptes privilégiés se connectent à des systèmes de confiance plus faible, si les administrateurs utilisent RDP sans protections renforcées, ou si des serveurs accumulent des secrets d’administration réutilisables dans LSASS, l’attaquant a quelque chose à voler.
3. La cible suivante accepte encore une authentification NTLM
La technique devient beaucoup plus difficile à exploiter si l’environnement a réduit sa dépendance à NTLM, durci les flux d’administration à distance ou supprimé les chemins critiques reposant sur des secrets NTLM réutilisables.
4. L’identifiant compromis conserve des droits utiles ailleurs
Un hash volé pour un compte peu privilégié a une valeur limitée. Le matériau vraiment dangereux est celui d’un administrateur local réutilisé sur plusieurs postes, d’un compte helpdesk avec une large portée, ou d’un compte AD privilégié qui se connecte à des serveurs membres.
5. L’hygiène administrative est suffisamment faible pour autoriser une chaîne de rebonds
C’est la raison pour laquelle le Pass-the-Hash est intimement lié aux mouvements latéraux et pas seulement au vol d’identifiants. Si les mots de passe d’admin locaux sont uniques, si les administrateurs utilisent des postes dédiés et si les identifiants privilégiés n’atterrissent pas sur des systèmes de rang inférieur, l’attaquant perd le chemin qui donne sa valeur au PtH.
La chaîne d’attaque
Une séquence Pass-the-Hash typique dans un environnement AD ressemble à ceci.
Étape 1 - Obtenir de l’exécution sur un premier hôte
L’attaquant compromet un poste ou un serveur via du phishing, un malware, un logiciel vulnérable ou un accès déjà existant.
Étape 2 - Dumper du matériel réutilisable
Dès qu’il dispose des privilèges nécessaires sur cet hôte, l’attaquant cible LSASS ou les magasins d’identifiants locaux afin d’extraire du matériel réutilisable. MITRE associe explicitement des outils comme Mimikatz au Pass-the-Hash, notamment via le module SEKURLSA::Pth.
Étape 3 - Identifier le meilleur compte à réutiliser
L’attaquant n’a pas besoin de tous les comptes. Il a besoin du compte qui ouvre l’accès à l’hôte suivant. Dans les environnements réels, cela signifie souvent :
- un administrateur local réutilisé
- une identité d’administration poste de travail ou helpdesk
- un compte d’administration serveur ayant touché de nombreux hôtes
- un compte AD privilégié qui n’aurait jamais dû se connecter à ce poste
Étape 4 - S’authentifier vers un autre hôte par un chemin qui accepte encore NTLM
L’attaquant se déplace ensuite via des protocoles d’administration, de la création de services à distance, de l’accès SMB administratif, WMI, des tâches planifiées ou d’autres mécanismes de gestion Windows qui acceptent encore ce matériel réutilisé.
Étape 5 - Répéter jusqu’à atteindre un niveau privilégié supérieur
Le danger du Pass-the-Hash n’est pas un seul saut. Le danger est la chaîne. Un poste compromis mène à un autre contexte administrateur, puis à un serveur d’administration, puis à un système où des identifiants de plus forte valeur sont présents, jusqu’à potentiellement le contrôle du domaine ou de la forêt. C’est la même logique opérationnelle que celle décrite plus largement dans les chemins d’attaque AD : chaque frontière d’identifiants faible rend le saut suivant plus simple.
Pass-the-Hash vs Overpass-the-Hash vs Pass-the-Ticket
Ces techniques sont proches, mais elles ne sont pas interchangeables.
Le Pass-the-Hash reste centré sur du matériel d’authentification dérivé de NTLM et sur des chemins d’accès qui acceptent encore NTLM.
L’Overpass-the-Hash part de matériel dérivé de NTLM mais s’en sert pour obtenir du matériel d’authentification Kerberos, puis bascule vers un accès fondé sur Kerberos.
Le Pass-the-Ticket ne repose pas sur du matériel dérivé de NTLM ; il réutilise directement des tickets Kerberos volés.
Cette distinction est importante autant pour la détection que pour la remédiation. Si les défenseurs écrasent ces techniques sous un seul concept, ils finissent presque toujours par construire une stratégie de détection faible et par appliquer les mauvais contrôles au mauvais problème.
Détection
Il n’existe pas d’événement Windows unique qui dise « ceci est un Pass-the-Hash ». Une stratégie de détection utile est une stratégie de corrélation.
La stratégie de détection MITRE pour T1550.002 va dans la bonne direction : il faut corréler une activité NTLM LogonType 3 anormale avec le contexte processus, session et réseau, au lieu de dépendre d’un seul indicateur isolé.
Ce qu’il faut surveiller
Les motifs autour de 4624
L’événement 4624 est utile quand on s’intéresse à l’endroit où la session apparaît, au type de logon utilisé et au contexte de compte qui ne devrait pas se trouver sur ce système.
Exemples à forte valeur :
- un logon réseau qui place une identité d’administration sur un hôte qu’elle touche rarement
- des mouvements latéraux répétés depuis un poste compromis vers plusieurs pairs ou serveurs
- le même contexte administrateur local observé sur plusieurs endpoints
4672 sur la cible
L’événement 4672 est utile lorsqu’une nouvelle session reçoit des privilèges spéciaux sur le système cible. Ce n’est pas un détecteur PtH à lui seul, mais il aide à distinguer les logons distants qui comptent vraiment.
Le contexte NTLM lorsqu’il est disponible
Dès que votre télémétrie expose le contexte d’authentification NTLM, ce signal devient utile, car PtH dépend des chemins qui acceptent encore NTLM. Le but n’est pas d’alerter sur chaque événement NTLM. Le but est d’identifier une activité administrative fondée sur NTLM inattendue, impliquant des comptes, des systèmes ou des trajectoires qui ne vont pas normalement ensemble.
Des mouvements privilégiés inhabituels entre hôtes
Les signaux les plus solides viennent souvent du comportement plutôt que d’un ID d’événement isolé :
- la même identité d’administration qui apparaît sur plusieurs hôtes en peu de temps
- un contexte administrateur local réutilisé sur des hôtes qui devraient tous avoir des mots de passe d’admin uniques
- une activité administrative qui démarre depuis un poste de travail hors du flux habituel des administrateurs
Les signaux EDR de credential dumping et d’accès à LSASS
Le Pass-the-Hash dépend généralement d’un vol d’identifiants préalable. Si l’EDR remonte un accès suspect à LSASS, un comportement de credential dumping, puis une activité d’administration distante depuis ce même hôte, cette corrélation a souvent plus de valeur qu’une règle basée sur un seul événement.
Exemple de cadrage de détection
Il ne faut pas formuler la détection comme « 4624 signifie Pass-the-Hash ». Un meilleur cadrage est :
- comportement suspect d’accès aux identifiants sur l’hôte A
- suivi d’un logon distant ou d’une activité administrative fondée sur NTLM sur l’hôte B
- avec un contexte de compte qui ne correspond ni au système source habituel ni au workflow d’administration normal
C’est à ce niveau que les défenseurs attrapent réellement le PtH.
Dépendance au monitoring
Si votre supervision AD et Windows est faible, cette technique sera facile à manquer. C’est pour cela que la supervision sécurité AD fait partie de la même famille de contrôles que la détection du Pass-the-Hash.
Remediation / Remédiation
La remédiation du Pass-the-Hash ne se résume pas à un paramètre. C’est une stratégie visant à réduire les endroits où des identifiants réutilisables existent, à réduire les chemins qui acceptent encore NTLM et à limiter jusqu’où un contexte d’administration volé peut voyager.
1. Activer Credential Guard là où il est supporté
Microsoft explique que Credential Guard protège les hashes NTLM, les TGT Kerberos et d’autres secrets en les isolant avec la virtualisation matérielle. C’est l’un des contrôles les plus directs contre les chaînes classiques de vol d’identifiants qui rendent le PtH possible.
Points d’attention explicitement documentés par Microsoft :
- certaines capacités d’authentification sont bloquées ; il faut donc tester les applications avant généralisation
- Credential Guard ne protège pas les comptes locaux et les comptes Microsoft exactement de la même manière que les secrets issus du domaine
- les identifiants fournis pour une authentification NTLM ne sont pas entièrement protégés dans tous les scénarios
- Microsoft indique explicitement qu’il n’est pas recommandé d’activer Credential Guard sur les contrôleurs de domaine
2. Utiliser Remote Credential Guard ou Restricted Admin pour les workflows RDP
Microsoft documente deux protections distinctes pour les flux d’administration fondés sur RDP.
Remote Credential Guard empêche l’envoi des identifiants vers la machine distante et constitue l’option privilégiée lorsque le scénario le supporte.
Restricted Admin reste utile lui aussi. Microsoft le recommande en particulier dans les scénarios de support helpdesk, car il réduit l’exposition des identifiants réutilisables et des ressources de l’utilisateur face à un hôte distant compromis.
Caveats importants tirés de la documentation Microsoft :
- Remote Credential Guard ne fonctionne qu’avec RDP
- il nécessite Kerberos
- il n’est supporté que pour des connexions directes à la machine cible, pas via RD Gateway ou Connection Broker
- il ne fonctionne pas quand l’hôte distant est uniquement joint à Microsoft Entra
- il ne couvre pas tous les scénarios d’authentification ; des tests de compatibilité restent nécessaires
3. Éliminer la réutilisation des mots de passe d’administrateur local avec Windows LAPS
Des mots de passe d’admin local partagés sont l’une des manières les plus simples de rendre le Pass-the-Hash scalable. Microsoft présente explicitement Windows LAPS comme une protection contre les attaques qui exploitent les comptes locaux pour les mouvements latéraux, y compris des progressions de type PtH.
Si le même mot de passe administrateur local existe sur des dizaines ou des centaines de postes, la compromission d’une seule machine peut se transformer en campagne de mouvements latéraux. Windows LAPS non déployé doit donc être traité comme un article d’exposition PtH directe et non comme un simple sujet d’hygiène annexe.
4. Empêcher les identifiants privilégiés d’atterrir sur des hôtes de moindre confiance
La documentation Microsoft sur Credential Guard est très claire sur ce point : les comptes à haute valeur doivent utiliser des machines dédiées. C’est l’un des contrôles anti-PtH les plus pratiques, car il réduit la probabilité que du matériel d’authentification privilégié atterrisse sur des postes banalisés.
Cela peut prendre plusieurs formes :
- postes d’administration dédiés
- jump hosts d’administration avec un périmètre strict
- administration tierisée empêchant des systèmes de niveau inférieur de collecter des identifiants de niveau supérieur
- identités d’administration séparées au lieu d’un usage quotidien privilégié
5. Réduire l’usage de NTLM dès que possible
Le Pass-the-Hash reste utile en opération parce que NTLM reste utile en exploitation. Si des chemins d’administration critiques reposent encore sur NTLM, l’attaquant garde plus d’options de déplacement. Réduire l’usage de NTLM, supprimer les dépendances inutiles et éviter les fallbacks silencieux réduit donc mécaniquement l’exposition au PtH.
C’est aussi la raison pour laquelle PtH et les attaques NTLM Relay doivent être revus dans le même mouvement. Ce sont deux techniques différentes, mais elles survivent toutes deux sur la même dette protocolaire.
6. Protéger les comptes qui valent le plus la peine d’être volés
Pour les identités les plus privilégiées, il faut envisager des contrôles qui rendent l’usage de NTLM et le stockage de secrets réutilisables beaucoup moins acceptables d’un point de vue opérationnel :
- éviter de connecter des comptes privilégiés à des systèmes généralistes
- utiliser le groupe Protected Users quand l’environnement supporte ses restrictions
- revoir les comptes obsolètes et sur-privilégiés et supprimer les identités anciennes qui gardent une portée excessive
- durcir la sécurité des mots de passe Active Directory afin que des faiblesses de mot de passe n’amplifient pas les effets d’un seul contexte administrateur compromis
Le groupe Protected Users est puissant, mais il a un coût. Microsoft documente que ses membres ne peuvent pas s’authentifier via NTLM, Digest ni via la délégation par défaut de CredSSP, et que certains workflows legacy peuvent donc casser. C’est un contrôle fort pour les comptes à haute valeur, mais certainement pas un changement à appliquer sans validation.
Validation après durcissement
Il ne faut pas clore une remédiation Pass-the-Hash parce qu’un seul paramètre a été activé. Il faut valider le chemin de bout en bout.
- confirmer que les comptes privilégiés ne se connectent plus à des systèmes de niveau inférieur qui exposent leur matériel d’authentification
- vérifier que Windows LAPS fait réellement tourner des mots de passe administrateur local uniques sur le périmètre visé
- tester la compatibilité de Credential Guard sur des systèmes représentatifs avant déploiement large, puis confirmer qu’il reste effectivement activé
- valider que les flux RDP d’administration utilisent bien Remote Credential Guard ou Restricted Admin lorsque prévu
- revoir si les chemins d’administration restants reposent encore sur NTLM ou sur des fallbacks silencieux
- tester si un endpoint compromis peut encore atteindre d’autres systèmes via un contexte administrateur local réutilisé
Le bon critère de succès n’est pas « nous avons activé un contrôle ». Le bon critère de succès est : « un seul contexte administrateur volé ne permet plus à l’attaquant de progresser sur la même chaîne ».
Comment EtcSec détecte les expositions liées
EtcSec n’a pas besoin d’un faux tag de taxonomie Pass-the-Hash pour être utile ici. La valeur vient des expositions associées qui rendent PtH viable.
Les familles de contrôles les plus pertinentes autour du PtH sont :
- Windows LAPS non déployé
- WDigest activé
- Attaques NTLM Relay
- Comptes obsolètes et sur-privilégiés
- Supervision sécurité AD
- Kerberoasting
Ensemble, ces contrôles indiquent si l’environnement possède encore les ingrédients qui permettent à un identifiant Windows volé de devenir une chaîne de mouvements latéraux.
Contrôles liés
Le Pass-the-Hash est rarement le seul problème d’identité du périmètre. Si l’objectif est de réduire les mouvements réels d’un attaquant et pas seulement d’améliorer une case dans une checklist, il faut revoir le PtH avec Windows LAPS non déployé, WDigest activé, les attaques NTLM Relay, les comptes obsolètes et sur-privilégiés, la supervision sécurité AD et le Kerberoasting. Ce sont les contrôles voisins qui déterminent si le Pass-the-Hash reste une technique praticable dans votre environnement AD.
