Pass-the-Hash et Pass-the-Ticket : mécanique et détection pour les équipes bleues

Le vol d'identifiants reste l'un des moyens les plus fiables pour un intrus de se déplacer dans un domaine Windows, et deux techniques en sont au cœur : Pass-the-Hash (PtH) et Pass-the-Ticket (PtT). Toutes deux détournent le fonctionnement même des protocoles d'authentification plutôt qu'une seule faille corrigeable, et c'est précisément pourquoi les défenseurs doivent les comprendre en profondeur. Cet article adopte l'approche comprendre pour défendre : nous expliquons ce que sont ces techniques, comment elles opèrent au niveau conceptuel, où se trouve le matériel d'identification et — surtout — les signaux de détection concrets et les mesures de durcissement qui permettent à une équipe bleue de repérer et de contenir le mouvement latéral. Il n'y a ici aucune recette d'attaque, seulement le savoir dont un défenseur a besoin pour bâtir une surveillance résiliente et réduire le rayon d'impact d'un hôte compromis.

Ce que sont réellement Pass-the-Hash et Pass-the-Ticket

Dans un environnement Windows, les utilisateurs ressaisissent rarement leur mot de passe pour chaque ressource. Le système d'exploitation conserve plutôt des artefacts d'authentification en mémoire pour prouver l'identité au nom de l'utilisateur. Dans l'authentification NTLM, cet artefact est un hachage équivalent au mot de passe ; dans Kerberos, c'est un ticket, soit un Ticket-Granting Ticket (TGT), soit un ticket de service. Pass-the-Hash est la réutilisation d'un hachage NTLM volé pour s'authentifier en tant qu'utilisateur sans jamais connaître le mot de passe en clair. Pass-the-Ticket est l'idée équivalente pour Kerberos : un ticket volé ou forgé est présenté pour obtenir un accès. Le point stratégique pour les défenseurs est que ces deux techniques transforment un unique point d'accès compromis en rampe de lancement, car les artefacts récoltés là-bas sont valides ailleurs dans le domaine.

Comment ces techniques fonctionnent à haut niveau

Les deux techniques partagent une condition préalable : un attaquant qui a déjà obtenu l'exécution de code privilégiée sur un hôte et peut lire la mémoire protégée du processus LSASS, le sous-système Windows qui met en cache le matériel d'identification pour l'authentification unique. Une fois ce matériel extrait, PtH rejoue le hachage contre des services qui acceptent NTLM, et PtT injecte un ticket valide dans une session d'ouverture de session pour que les services fondés sur Kerberos lui fassent confiance. Des variantes comme Overpass-the-Hash font le pont entre les deux mondes en utilisant un hachage NTLM pour demander un TGT Kerberos. Le fil conducteur est que l'attaquant n'a jamais besoin du mot de passe : le secret dont il a besoin est l'artefact dérivé, et cet artefact est conçu pour être rejouable par un logiciel légitime. C'est pourquoi la réponse défensive est en couches : on ne peut pas simplement corriger un protocole qui se comporte comme spécifié.

Surface d'attaque : où réside le matériel d'identification

Comprendre la surface indique quoi protéger. Le réservoir principal est la mémoire de LSASS sur tout hôte où un compte privilégié s'est récemment connecté de manière interactive, via le Bureau à distance ou par un service qui met en cache des identifiants. Les réservoirs secondaires comprennent la base de données locale SAM, les vérificateurs de connexion de domaine mis en cache, la base de données NTDS.dit sur les contrôleurs de domaine, ainsi que les sauvegardes ou instantanés de machines virtuelles qui en contiennent. Les comptes très privilégiés — administrateurs de domaine, comptes de service aux droits étendus et opérateurs de sauvegarde — sont les joyaux de la couronne, car un seul hachage ou ticket récolté pour l'un d'eux peut ouvrir tout l'annuaire. Le corollaire défensif est un principe d'hygiène des identifiants : ne jamais laisser un compte de Niveau 0 s'authentifier sur un poste de moindre confiance, car cela ensemence la mémoire de cette machine avec un secret qui domine le domaine.

Signaux de détection : journaux, Event IDs et télémétrie

La détection est le terrain où gagnent les équipes bleues. Comme ces techniques réutilisent des protocoles légitimes, aucun événement isolé n'est une preuve irréfutable ; on corrèle plutôt plusieurs signaux faibles en un signal fort. Surveillez les journaux de sécurité Windows pour l'Event ID 4624 (ouverture de session réussie) avec Logon Type 3 (réseau) ou Type 9 (NewCredentials), surtout lorsque le paquet d'authentification est NTLM pour des comptes censés utiliser Kerberos. Associez 4624 à 4776 (validation d'identifiant NTLM) et 4672 (privilèges spéciaux attribués) pour repérer les connexions réseau privilégiées qui ne correspondent pas aux schémas normaux. Pour l'abus de Kerberos, surveillez 4768 (TGT demandé) et 4769 (ticket de service demandé) ; les tickets aux types de chiffrement inhabituels, aux durées de vie incohérentes ou demandés pour des comptes qui ne se connectent jamais de manière interactive méritent un examen. Les tickets forgés produisent souvent une durée de vie qui dépasse la politique du domaine, une anomalie forte.

La télémétrie du poste comble l'écart. Un bon EDR signale les demandes de handle suspectes vers LSASS — l'accès au processus avec des droits comme PROCESS_VM_READ depuis un processus non système est une alerte de grande valeur — de même que le chargement de pilotes inhabituels et l'injection de matériel de ticket dans les sessions d'ouverture de session. Sysmon apporte de la précision : Event ID 10 (ProcessAccess) visant lsass.exe, Event ID 1 (création de processus) pour des schémas connus d'outillage d'identifiants et Event ID 3 (connexion réseau) pour les connexions latérales de poste à poste. Le signal comportemental le plus durable est le mouvement latéral lui-même : un compte qui s'authentifie depuis une machine jamais utilisée, à une heure où il ne travaille jamais, vers des hôtes qu'il ne touche jamais. Établir une base de référence des chemins d'authentification normaux et alerter sur les écarts détecte PtH et PtT même lorsque l'outillage est inédit.

Atténuation et durcissement

Le contrôle le plus efficace est la hiérarchisation des identifiants : diviser comptes et systèmes en niveaux administratifs (Niveau 0 pour les contrôleurs de domaine et l'infrastructure d'identité, Niveau 1 pour les serveurs, Niveau 2 pour les postes de travail) et interdire aux identifiants de niveau élevé de se connecter aux niveaux inférieurs. Cela seul prive l'attaquant des artefacts joyaux de la couronne sur les cibles molles. Activez Credential Guard, qui utilise la sécurité fondée sur la virtualisation pour isoler les secrets de LSASS du système d'exploitation en cours d'exécution, renchérissant fortement l'extraction. Déployez la protection de LSASS (RunAsPPL / Protected Process Light) pour que le code ordinaire ne puisse pas ouvrir un handle de lecture sur le processus. Utilisez le groupe de sécurité Utilisateurs protégés pour les comptes sensibles ; il désactive NTLM, le chiffrement Kerberos faible et la mise en cache des identifiants pour ses membres.

Réduisez le nombre d'endroits où atterrissent les secrets. Appliquez le principe du moindre privilège pour que le travail quotidien n'utilise jamais un compte d'administrateur de domaine ; fournissez des comptes d'administration distincts, sans messagerie, utilisés uniquement depuis des postes d'accès privilégié (PAW) durcis. Configurez des restrictions de connexion avec Interdire l'ouverture de session locale et Interdire l'ouverture de session par le Bureau à distance pour tenir les comptes de Niveau 0 à l'écart des machines ordinaires. Faites tourner le mot de passe du compte krbtgt de façon planifiée — deux fois, avec un délai — pour invalider les Golden Tickets forgés. Désactivez NTLM lorsque c'est possible et auditez là où il reste requis. Segmentez le réseau pour qu'un poste compromis ne puisse pas atteindre directement ses pairs, et exigez la signature SMB et la liaison de canal LDAP pour émousser l'abus de type relais. Enfin, raccourcissez les durées de vie des tickets Kerberos dans les limites opérationnelles pour que les tickets volés expirent vite.

Pièges courants qui affaiblissent les défenses

Même les équipes matures se sabotent. Une erreur fréquente est d'activer Credential Guard sur les postes de travail tout en laissant un administrateur de domaine se connecter à des serveurs où il n'est pas activé, réensemençant des secrets récoltables. Une autre est de traiter les règles de détection comme du « configurer et oublier » : les bases de référence d'authentification dérivent à mesure que le parc évolue, si bien qu'une règle ajustée l'an dernier enterre aujourd'hui les vraies alertes dans le bruit. Les équipes font aussi trop confiance à un seul Event ID ; comme 4624 et 4769 se déclenchent en permanence, alerter dessus sans corrélation ne produit que de la fatigue d'alerte. Les sauvegardes sont un angle mort : une sauvegarde NTDS.dit non protégée livre tous les hachages du domaine. Enfin, oublier de faire tourner krbtgt après un incident laisse intacte la persistance des tickets forgés, même lorsqu'on croit avoir expulsé l'intrus.

Liste de contrôle du défenseur

Utilisez ceci comme liste de travail. Identité : mettez en place la hiérarchisation administrative ; placez les comptes sensibles dans Utilisateurs protégés ; utilisez des PAW pour tout travail privilégié ; faites tourner krbtgt deux fois de façon planifiée et après toute suspicion de compromission. Durcissement des hôtes : activez Credential Guard et RunAsPPL ; maintenez la protection de LSASS vérifiée, pas seulement configurée ; restreignez les droits de connexion locale et RDP par niveau. Détection : collectez et centralisez les Event IDs de sécurité 4624, 4672, 4768, 4769, 4776 ; déployez Sysmon avec la surveillance ProcessAccess sur lsass.exe ; établissez des bases de référence des chemins d'authentification normaux et alertez sur les écarts ; chassez les tickets aux durées de vie ou types de chiffrement anormaux. Confinement : segmentez le réseau, exigez la signature SMB et la liaison de canal LDAP, désactivez le NTLM hérité et répétez un runbook d'incident incluant la rotation de krbtgt et la réinitialisation des identifiants privilégiés.

Foire aux questions

Pass-the-Hash est-il encore pertinent si nous utilisons Kerberos partout ? Oui. Beaucoup d'environnements retombent sur NTLM pour des cas particuliers — connexions IP directes, applications anciennes ou services mal configurés — et toute surface NTLM résiduelle maintient PtH viable. De plus, Pass-the-Ticket vise directement Kerberos, si bien que changer de protocole ne remplace pas l'isolation des identifiants ni la surveillance.

L'authentification multifacteur arrête-t-elle ces techniques ? Le MFA est essentiel au point d'ouverture de session interactive, mais PtH et PtT réutilisent des artefacts créés après une authentification réussie. Une fois le hachage ou le ticket présent en mémoire, le MFA n'est plus dans la boucle. C'est pourquoi les contrôles durables sont l'isolation des artefacts (Credential Guard, protection de LSASS), la hiérarchisation et la détection comportementale, et non la seule robustesse de l'authentification.

Conclusion

Pass-the-Hash et Pass-the-Ticket perdurent parce qu'ils exploitent les mécanismes mêmes qui rendent l'authentification unique commode. Aucun correctif unique ne les supprime ; les défenseurs l'emportent en rendant les artefacts récoltés difficiles à obtenir, inutiles hors d'un périmètre étroit et bruyants lorsqu'on en abuse. Concentrez-vous sur la hiérarchisation des identifiants, sur les fonctions d'isolation mémoire comme Credential Guard et RunAsPPL, sur des restrictions de connexion disciplinées et sur une détection corrélée bâtie sur les Event IDs Windows et la télémétrie des postes. Lorsque ces couches fonctionnent ensemble, un unique poste compromis reste un unique poste compromis — et la technique la plus fiable de l'intrus devient son erreur la plus visible.