Pass-the-Hash dans l’AD : détection et réduction du risque

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 grâce à la sécurité basée sur 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 à l’usage du Pass-the-Hash : son module SEKURLSA::Pth « peut usurper un utilisateur, avec seulement un hash de mot de passe, pour exécuter des commandes arbitraires ».

É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 Windows de MITRE pour T1550.002 va dans la bonne direction : elle signale les authentifications NTLM LogonType 3 anormales survenant sans événement de logon de domaine correspondant, corrélées au contexte processus, session et réseau, plutôt que de dépendre d’un seul indicateur isolé.

Ce qu’il faut surveiller

Les motifs autour de 4624

4624 (An account was successfully logged on — un compte s’est connecté avec succès) 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

4672 (Special privileges assigned to new logon — des privilèges spéciaux ont été attribués à une nouvelle connexion) 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

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 indique que Credential Guard protège les hashes de mot de passe NTLM, les tickets Kerberos Ticket Granting Ticket (TGT) ainsi que les identifiants stockés par les applications en tant qu’identifiants de domaine, en les isolant grâce à la sécurité basée sur la virtualisation. C’est l’un des contrôles les plus directs contre les chaînes classiques de vol d’identifiants qui rendent le PtH possible.

Avant de planifier un déploiement, vérifiez ce qui est déjà activé. Depuis Windows 11, version 22H2 et Windows Server 2025, Credential Guard est activé par défaut sur les systèmes joints au domaine qui répondent aux exigences matérielles et de licence et qui ne sont pas des contrôleurs de domaine. Dans de nombreux parcs actuels, le travail consiste à confirmer que la fonctionnalité reste activée, pas à l’activer depuis zéro.

Points d’attention explicitement documentés par Microsoft, tirés des limites de protection de Credential Guard :

certaines capacités d’authentification sont bloquées ; il faut donc tester les applications avant généralisation
les comptes locaux et les comptes Microsoft ne sont pas protégés. Credential Guard protège les secrets issus du domaine, donc le matériel des comptes locaux derrière un compte administrateur local réutilisé reste exposé
les identifiants fournis pour une authentification NTLM ne sont pas protégés : Microsoft indique que si un utilisateur est invité à saisir des identifiants pour une authentification NTLM et les saisit, ces identifiants sont exposés à une lecture depuis la mémoire LSASS
les tickets de service Kerberos ne sont pas protégés non plus ; seul le TGT Kerberos l’est
Microsoft indique explicitement qu’il n’est pas recommandé d’activer Credential Guard sur les contrôleurs de domaine — cela n’y apporte aucune sécurité supplémentaire et peut provoquer des problèmes de compatibilité applicative

2. Utiliser Remote Credential Guard ou Restricted Admin pour les workflows RDP

Microsoft documente deux protections différentes pour les flux d’administration fondés sur RDP, et attribue à chacune la prévention du Pass-the-Hash. Le choix entre les deux dépend du niveau de confiance que vous accordez à l’hôte distant.

Remote Credential Guard redirige les requêtes Kerberos vers l’appareil qui initie la connexion, de sorte que ni l’identifiant ni ses dérivés ne sont jamais transmis à l’hôte distant. Elle convient aux connexions vers un hôte que vous considérez de confiance.

Restricted Admin est l’option que Microsoft recommande pour les scénarios de support helpdesk, et c’est le point le plus souvent inversé dans la lecture. Microsoft indique que Remote Credential Guard n’est pas recommandé pour le travail helpdesk : si la session est ouverte vers un client déjà compromis, l’attaquant peut utiliser ce canal ouvert pour créer des sessions au nom de l’utilisateur et atteindre ses ressources pendant une durée limitée après la déconnexion de la session. Pour le helpdesk, Microsoft indique que les connexions RDP ne doivent être lancées qu’avec le commutateur /RestrictedAdmin.

Caveats importants tirés de la documentation Microsoft :

Remote Credential Guard ne fonctionne qu’avec RDP
le serveur et le client doivent s’authentifier via Kerberos, et Remote Credential Guard n’autorise pas de repli sur NTLM, car cela exposerait les identifiants
il n’est supporté que pour des connexions directes à la machine cible, pas via Remote Desktop Connection Broker ou Remote Desktop Gateway
l’hôte distant doit être joint à un domaine Active Directory ; il ne peut pas être utilisé pour se connecter à un appareil joint uniquement à Microsoft Entra ID (un client joint à Microsoft Entra peut en revanche se connecter à un hôte joint à AD)
il ne prend pas en charge l’authentification composée (compound authentication), ce qui impose des tests de compatibilité
Restricted Admin a lui aussi un coût : il nécessite l’appartenance au groupe Administrateurs sur l’hôte distant et n’offre aucune authentification unique (single sign-on) vers d’autres systèmes

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 cite « la protection contre les attaques de type pass-the-hash et de déplacement latéral » comme premier bénéfice de Windows LAPS. Déployez le Windows LAPS intégré plutôt que l’ancien MSI Microsoft LAPS, que Microsoft a déprécié à partir de Windows 11 23H2.

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 sans détour sur ce point. Credential Guard n’empêche pas un attaquant disposant d’un malware sur le poste d’utiliser les privilèges associés à un identifiant quelconque ; c’est pourquoi Microsoft recommande « l’usage de PC dédiés pour les comptes à haute valeur, tels que les IT Pros et les utilisateurs ayant accès à des ressources à haute valeur ». 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, ne peuvent pas utiliser le chiffrement DES ou RC4 lors de la pré-authentification Kerberos, ne peuvent pas faire l’objet d’une délégation contrainte ou non contrainte, et ne peuvent pas renouveler leurs TGT Kerberos au-delà d’une durée de vie initiale de quatre heures. Côté poste, CredSSP et Windows Digest cessent de mettre en cache les identifiants en clair, NTLM cesse de mettre en cache la fonction à sens unique NT, et l’ouverture de session hors connexion cesse de fonctionner. Microsoft met également en garde contre l’ajout de membres Domain Admins ou Enterprise Admins avant des tests, car cela peut verrouiller ces comptes. C’est donc un contrôle fort pour les comptes à haute valeur, mais 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 :

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.