Pass-the-Hash (PtH) est l'une des techniques offensives les plus emblematiques et persistantes du monde Windows : elle permet a un attaquant de s'authentifier sur un service NTLM en presentant directement le hash NT d'un compte, sans jamais avoir besoin de connaitre le mot de passe en clair correspondant. Repertoriee dans le framework MITRE ATT&CK sous l'identifiant T1550.002, cette attaque exploite une caracteristique de conception du protocole NTLM : le serveur ne verifie jamais le mot de passe lui-meme, mais une preuve cryptographique calculee a partir du hash NT — un hash MD4 du mot de passe Unicode. Quiconque possede ce hash peut donc se faire passer pour l'utilisateur sans realiser le moindre cassage offline. Conceptualisee des 1997 par Paul Ashton sur la mailing list Bugtraq, la technique a connu sa popularisation industrielle a partir de 2008 avec la publication du Pass-the-Hash Toolkit par Hernan Ochoa, puis sa massification grace a son integration dans Mimikatz en 2011 via la commande sekurlsa::pth. Aujourd'hui omnipresente dans les compromissions Active Directory, employee par les groupes APT (APT29, Lazarus, FIN6) comme par les operateurs de ransomware (Conti, LockBit, BlackBasta), Pass-the-Hash demeure un vecteur de mouvement lateral redoutable malgre les mitigations Microsoft (Credential Guard, LSA Protection, Restricted Admin Mode, modele Tier et LAPS). Cette page entity-first detaille le fonctionnement cryptographique de NTLM, les outils d'execution (Mimikatz, Impacket, NetExec, Cobalt Strike), les sources de hashes, les CVE associes, ainsi que les strategies de detection cote SIEM/EDR pour 2026.

L'essentiel a retenir sur Pass-the-Hash

  • Definition : authentification NTLM en presentant le hash NT au lieu du mot de passe en clair — aucun cassage offline necessaire.
  • MITRE ATT&CK : technique T1550.002 — Use Alternate Authentication Material: Pass the Hash, sous-technique de T1550.
  • Origine : concept theorise par Paul Ashton en 1997, outillage publie par Hernan Ochoa en 2008, adoption massive via Mimikatz (Benjamin Delpy) en 2011.
  • Outils signatures : Mimikatz (sekurlsa::pth), Impacket (psexec.py, wmiexec.py, smbexec.py), NetExec (ex-CrackMapExec), Cobalt Strike, Metasploit exploit/windows/smb/psexec.
  • Sources de hashes : LSASS dump, base SAM locale, NTDS.dit (replication DCSync), capture SMB via Responder, dump DPAPI.
  • Mitigations 2026 : Credential Guard (VBS), LSA Protection RunAsPPL, Restricted Admin Mode RDP, modele Tier 0/1/2, LAPS, desactivation NTLMv1, signed SMB, Protected Users.
  • Detection : Event 4624 LogonType 9 (NewCredentials), Sysmon Event 10 ProcessAccess sur LSASS, Microsoft Defender for Identity, Sentinel UEBA, regles Sigma communautaires.

Definition : qu'est-ce que Pass-the-Hash ?

Pass-the-Hash, abrege PtH, designe une famille de techniques de mouvement lateral et d'usurpation d'identite consistant a reutiliser directement le hash NT (parfois appele NTLM hash) d'un compte Windows pour s'authentifier aupres d'un service supportant l'authentification NTLM. La technique exploite le fait fondamental que le protocole NTLM, contrairement a une saisie interactive de mot de passe, ne necessite a aucun moment la connaissance du cleartext password : il manipule uniquement le hash MD4 du mot de passe encode en UTF-16LE.

Concretement, lorsqu'un client Windows s'authentifie en NTLM, il calcule une reponse challenge-response a partir du hash NT stocke en cache memoire (LSASS) et d'un challenge envoye par le serveur. Si un attaquant parvient a injecter un hash NT volontairement choisi dans le contexte de securite d'un processus — typiquement via la commande sekurlsa::pth de Mimikatz — toutes les requetes NTLM ulterieures issues de ce processus seront effectuees au nom du compte cible, exactement comme si l'utilisateur legitime s'etait connecte. Le serveur distant n'a aucun moyen de distinguer une authentification PtH d'une authentification authentique : les deux sont, sur le fil, cryptographiquement identiques.

Pass-the-Hash est repertoriee dans le framework MITRE ATT&CK sous l'identifiant T1550.002, en tant que sous-technique de T1550 — Use Alternate Authentication Material. Elle est categorisee dans les tactiques Lateral Movement et Defense Evasion, refletant son double usage : se deplacer horizontalement entre machines compromises et contourner les MFA basees sur la saisie de mot de passe.

Histoire de Pass-the-Hash : de 1997 a Mimikatz

L'histoire de Pass-the-Hash s'etale sur trois decennies et reflete l'evolution des paradigmes de securite Windows. La technique nait dans un contexte d'analyse cryptographique des protocoles SMB/CIFS, traverse une longue phase de maturation outillee, puis devient en 2011 un standard de l'arsenal offensif AD.

  • Avril 1997 : Paul Ashton publie sur la mailing list Bugtraq un message intitule « NT Pass The Hash with Modified SMB Client Vulnerability », decrivant pour la premiere fois la possibilite de modifier un client SMB pour s'authentifier avec un hash plutot qu'un mot de passe. Microsoft minimise initialement la portee, considerant qu'un attaquant disposant deja du hash a essentiellement vaincu l'authentification.
  • 2000-2007 : phase d'incubation. Plusieurs implementations privees circulent dans la communaute pentest, notamment des patches du client SMB Samba sous Linux. La technique reste artisanale et peu accessible.
  • 2008 : Hernan Ochoa (Core Security, puis Amplia Security) presente a la conference Hack.lu son Pass-the-Hash Toolkit (PSHToolkit), premier ensemble d'outils utilisateurs (whosthere, iam) capable d'extraire des hashes depuis LSASS et de les injecter dans une session existante sur Windows XP/Server 2003. C'est la veritable democratisation de la technique.
  • 2011 : Benjamin Delpy publie Mimikatz, integrant nativement la commande sekurlsa::pth qui automatise l'injection de hash NT (et de cle Kerberos AES) dans le contexte LSASS. PtH devient une fonctionnalite trois clics, accessible a tout pentester debutant.
  • 2012-2014 : Microsoft publie deux livres blancs majeurs « Mitigating Pass-the-Hash Attacks » v1 et v2, codifiant pour la premiere fois la doctrine du modele Tier 0/1/2, la rotation des hashes via mots de passe forts et la separation des comptes administrateurs.
  • Aout 2014 : Microsoft publie KB2871997 qui retire les credentials des sessions reseau de la memoire LSASS et bloque l'authentification PtH avec le compte RID 500 par defaut sauf via Local Account SID S-1-5-113.
  • Windows 10 (2015) : introduction de Credential Guard base sur la Virtualization-Based Security (VBS) qui isole les secrets LSASS dans un processus protege par hyperviseur (LSAIso).
  • Windows Server 2016 : generalisation de Credential Guard cote serveur, ajout du groupe Protected Users et du Restricted Admin Mode RDP.
  • 2017-2020 : adoption massive par les groupes ransomware (NotPetya, Ryuk, REvil, Conti). PtH devient le vecteur de propagation laterale le plus document dans les rapports DFIR.
  • 2021-2026 : maturation defensive avec Microsoft Defender for Identity (ex-Azure ATP), regles ML detectant les anomalies NTLM, et integration native dans Microsoft Defender XDR.

Principe NTLM : challenge-response, LM, NTLM, NTLMv2

Comprendre Pass-the-Hash necessite une comprehension precise de la famille de protocoles NTLM (NT LAN Manager). Trois generations coexistent dans le paysage Windows.

LM hash (Lan Manager) — historique et obsolete

Le LM hash est le format historique herite d'OS/2 et de Windows NT 3.x. Il prend le mot de passe, le force en majuscules, le tronque a 14 caracteres, le decoupe en deux blocs de 7 caracteres et chiffre une chaine constante (KGS!@#$%) avec DES en utilisant chaque bloc comme cle. Les LM hashes sont cryptographiquement brises : un cassage exhaustif tient en quelques minutes sur GPU moderne. Microsoft a desactive leur stockage par defaut depuis Windows Vista/Server 2008 via la GPO NoLMHash.

NT hash (NTLM hash) — le pivot de Pass-the-Hash

Le NT hash, souvent appele simplement NTLM hash, est le hash MD4 du mot de passe utilisateur encode en UTF-16 little-endian. C'est ce hash de 32 caracteres hexadecimaux (16 octets) qui est la matiere premiere de Pass-the-Hash. Il est stocke dans la base SAM locale (HKLM\SAM), dans la base NTDS.dit des contrôleurs de domaine et en cache memoire LSASS pour permettre l'authentification SSO. Important : MD4 etant non-sale, deux utilisateurs ayant le meme mot de passe partagent le meme NT hash — c'est ce qui rend les rainbow tables NTLM efficaces sur les mots de passe faibles.

Challenge-response NTLMv1 et NTLMv2

Le hash NT n'est jamais transmis en clair sur le reseau. Lors d'une authentification NTLM, le serveur envoie un challenge aleatoire de 8 octets, et le client renvoie une reponse calculee a partir du hash NT et du challenge :

  • NTLMv1 : reponse calculee par DES(hash_nt, challenge). Vulnerable au cracking offline rapide via cassage des trois blocs DES de 7 octets, particulierement avec asreproast et services comme crack.sh.
  • NTLMv2 : reponse HMAC-MD5 incluant un challenge client (nonce), un timestamp, le nom de domaine et d'utilisateur. Resistante aux rainbow tables grace au sel implicite, mais reste cassable offline si le mot de passe est faible (Hashcat mode 5600).

Point cle pour PtH : le hash NT seul suffit pour repondre au challenge, qu'il s'agisse de NTLMv1 ou NTLMv2. C'est pourquoi passer le hash fonctionne contre les deux protocoles. Activer NTLMv2 protege contre la capture-et-cassage offline via Responder, mais n'empeche pas Pass-the-Hash si l'attaquant possede deja le hash NT.

Comment fonctionne Pass-the-Hash techniquement

L'execution de Pass-the-Hash repose sur trois etapes : (1) obtention du hash NT d'un compte cible, (2) injection du hash dans le contexte de securite d'un processus local, (3) acces a un service distant via une session NTLM authentifiee avec ce contexte.

L'injection elle-meme se fait en patchant les structures internes de LSASS pour que le module d'authentification msv1_0.dll presente le hash fourni au lieu de celui legitime. Cote reseau, le serveur cible ne voit aucune anomalie : il recoit un message NEGOTIATE_MESSAGE, repond par un CHALLENGE_MESSAGE, et recoit un AUTHENTICATE_MESSAGE contenant la reponse NTLMv2 valide. La session SMB, RPC, WinRM ou WMI est alors etablie au nom du compte cible.

Crucialement, Pass-the-Hash ne necessite jamais :

  • la connaissance du mot de passe en clair de la cible ;
  • le cassage offline du hash via Hashcat ou John the Ripper ;
  • l'interaction avec un endpoint Web ou un MFA TOTP/U2F (NTLM ne supporte pas la MFA) ;
  • une vulnerabilite logicielle particuliere — c'est une feature abuse, non un exploit.

Pass-the-Hash vs Pass-the-Ticket vs Overpass-the-Hash

Trois techniques connexes sont frequemment confondues. Bien les distinguer est essentiel pour comprendre la chaine d'exploitation et les defenses applicables.

  • Pass-the-Hash (T1550.002) : reutilisation du hash NT contre un service NTLM. Fonctionne tant que NTLM est accepte sur la cible. Identifiable par logon type 9.
  • Pass-the-Ticket (T1550.003) : reutilisation d'un ticket Kerberos (TGT ou TGS) extrait de la memoire LSASS. Necessite Kerberos sur la cible mais contourne les protections NTLM. Inclut les sous-variantes Golden Ticket (TGT forge avec le hash krbtgt) et Silver Ticket (TGS forge avec le hash d'un service). Voir Kerberoasting pour les techniques d'extraction de TGS.
  • Overpass-the-Hash (T1550.002 + T1558) : technique hybride. L'attaquant possede uniquement le hash NT (ou la cle AES) et l'utilise pour demander un TGT Kerberos au KDC, transformant ainsi un acces NTLM en acces Kerberos. Permet de contourner les environnements ou NTLM est desactive ou bloque par audit. Implementee par sekurlsa::pth avec l'option /aes256 ou par getTGT.py d'Impacket.

En pratique, un attaquant moderne combine ces techniques selon le contexte : Pass-the-Hash pour SMB/RPC sur les anciennes machines, Overpass-the-Hash pour passer Kerberos quand NTLM est restreint, et Pass-the-Ticket pour reutiliser des TGT extraits.

Outils d'execution de Pass-the-Hash

L'arsenal offensif pour Pass-the-Hash s'est considerablement enrichi depuis 2011. Les principaux outils utilises en 2026 sont les suivants.

Mimikatz : la reference historique

La commande emblematique est sekurlsa::pth qui injecte un hash NT (ou une cle Kerberos AES128/AES256) dans une nouvelle session lancee localement :

privilege::debug
sekurlsa::pth /user:Administrator /domain:CORP /ntlm:8846f7eaee8fb117ad06bdd830b7586c /run:powershell.exe

Le PowerShell ainsi lance peut alors acceder a \\DC01\C$, executer Invoke-Command ou monter des shares au nom du compte cible. Pour le detail des modules Mimikatz, consulter notre page entity Mimikatz.

Impacket : la suite Python multiplateforme

Impacket, maintenu aujourd'hui par Fortra (anciennement SecureAuth puis Core Security), est l'arsenal Python de reference pour PtH depuis Linux. Les scripts cles supportent tous l'option -hashes :NTHASH ou LMHASH:NTHASH :

  • psexec.py : execution distante via service SMB temporaire (PSEXESVC). Bruyant en logs.
  • wmiexec.py : execution via WMI (DCOM 135 + ports dynamiques). Plus discret que psexec.
  • smbexec.py : execution via service SMB sans drop binaire — alternative furtive.
  • atexec.py : execution via tache planifiee distante.
  • secretsdump.py : dump SAM/LSA/NTDS.dit a distance avec un hash.
  • getTGT.py : Overpass-the-Hash, recupere un TGT a partir d'un hash NT.
impacket-psexec -hashes :8846f7eaee8fb117ad06bdd830b7586c CORP/Administrator@10.10.10.5

NetExec (ex-CrackMapExec) : le couteau suisse pentest

NetExec (NXC), fork communautaire du defunt CrackMapExec (CME) maintenu par Pennyw0rth, est devenu en 2024 le standard de facto pour les operations PtH a grande echelle. Il supporte SMB, WinRM, MSSQL, RDP, LDAP, FTP, SSH avec parallelisation native :

netexec smb 10.10.10.0/24 -u Administrator -H 8846f7eaee8fb117ad06bdd830b7586c --local-auth
netexec winrm 10.10.10.5 -u Administrator -H 8846f7eaee8fb117ad06bdd830b7586c -x "whoami /all"

Les modules de NetExec automatisent les actions post-PtH : enumeration, dump de SAM, extraction LAPS, deploiement de payloads.

Cobalt Strike, Metasploit et frameworks C2

Les frameworks commerciaux et open source integrent PtH nativement :

  • Cobalt Strike : commande beacon pth qui appelle en interne mimikatz (kiwi.dll), suivi de jump psexec ou jump winrm. Voir notre page Cobalt Strike (entity).
  • Metasploit : module exploit/windows/smb/psexec avec option SMBPass au format aad3b435...:NTHASH.
  • Sliver, Havoc, Mythic : frameworks C2 modernes integrant PtH via leurs propres modules, generalement reposant sur les structures Impacket ou des reimplementations en Go/Rust.

Sources de hashes pour Pass-the-Hash

Pass-the-Hash necessite l'obtention prealable d'un hash NT valide. Les sources principales en 2026 sont :

  • Dump LSASS : extraction memoire du processus lsass.exe via MiniDumpWriteDump, procdump.exe -ma lsass.exe, NanoDump, Lsassy ou comsvcs.dll avec MiniDump. Le dump est ensuite parse offline par pypykatz ou Mimikatz pour extraire les hashes des sessions actives.
  • Base SAM locale : ruches HKLM\SAM et HKLM\SYSTEM sur les machines membres. Extraction via reg save puis secretsdump.py LOCAL -sam SAM -system SYSTEM. Donne les hashes des comptes locaux uniquement.
  • NTDS.dit (DCSync) : base AD complete contenant tous les hashes du domaine. Extraction via replication MS-DRSR (lsadump::dcsync ou secretsdump.py -just-dc) ou via copie a froid de C:\Windows\NTDS\ntds.dit + dump SYSTEM. Voir DCSync.
  • Capture SMB/HTTP via Responder : empoisonnement LLMNR/NBT-NS pour collecter des challenges NTLMv1/v2, suivis d'un cassage offline avec Hashcat. Voir NTLM Relay moderne.
  • DPAPI et Credential Manager : extraction des secrets stockes par les applications, parfois sous forme de hashes ou de credentials reutilisables.
  • Backup d'images systeme : copies VMware/Hyper-V, snapshots, backups Veeam contenant la machine virtuelle d'un DC ou d'un serveur sensible.
  • Memoire de processus tiers : navigateurs, RDP clients, outils d'admin qui maintiennent des hashes en cache.

Pre-requis et conditions de succes

Executer Pass-the-Hash requiert plusieurs conditions cumulatives, qui constituent autant de leviers defensifs.

  • Possession d'un hash NT valide non expire. Si le mot de passe a ete change, le hash est invalide.
  • Privileges locaux administrateur sur la machine source pour pouvoir patcher LSASS (mimikatz), ou alternativement utilisation d'un outil userland comme Impacket depuis Linux qui n'exige pas d'admin local sur la machine source.
  • Service NTLM accessible reseau sur la cible : SMB (445), WinRM (5985/5986), MSSQL (1433), HTTP NTLM (Sharepoint, Exchange OWA), RPC.
  • NTLM autorise sur la cible : si une GPO Network Security: Restrict NTLM bloque NTLM entrant, PtH echoue. La bascule vers Overpass-the-Hash + Kerberos est alors necessaire.
  • Privileges du compte cible sur le serveur destination : un hash de compte standard sans droits d'admin sur la cible permet juste une enumeration limitee.
  • Ports filtrables : un firewall bloquant SMB/WinRM/RPC inter-VLAN peut neutraliser le mouvement lateral.

Le scenario type est « compromission d'un poste utilisateur, dump LSASS, recuperation du hash de l'admin local d'or run sur 200 postes via GPO, PtH parallelise via NetExec sur tout le subnet ». C'est precisement contre ce scenario que Microsoft a concu LAPS et le modele Tier.

Limites et evolution : NTLMv1 vs NTLMv2 vs Kerberos

Pass-the-Hash a des limites claires que la defense doit connaitre :

  • Ne fonctionne que sur NTLM : si la cible n'accepte que Kerberos (typique des SPN HTTP/CIFS via FQDN), PtH echoue. Solution attaquante : Overpass-the-Hash.
  • Ne fonctionne pas sur les services proteges par MFA moderne (Entra ID, ADFS avec MFA, conditional access).
  • Ne fonctionne pas si le hash est obsolete : changement de mot de passe par l'utilisateur ou par LAPS rotation.
  • NTLMv1 vs NTLMv2 sur le wire : sans importance pour PtH lui-meme. La difference compte pour les attaques de capture-relay-cracking offline (Responder/NTLMRelayx) : NTLMv1 est cassable offline en quelques heures avec rainbow table sur 8 octets de hash NT, NTLMv2 ne l'est qu'en force brute sur le mot de passe.
  • Comptes Protected Users : ces comptes ne mettent pas leur hash NT en cache memoire et ne peuvent etre utilises qu'en Kerberos AES, neutralisant PtH (mais pas Pass-the-Ticket).

Mitigations Windows : Credential Guard, LSA Protection, Restricted Admin

Microsoft a publie plusieurs lignes de defense progressivement durcies depuis 2014. Une defense en profondeur 2026 combine ces mecanismes.

Credential Guard (Windows 10/Server 2016+)

Credential Guard est la mitigation la plus structurelle. Active par defaut sur Windows 11 Enterprise et Server 2025, elle isole les secrets LSA dans un processus appele LSAIso (LSA Isolated) execute dans un environnement Virtual Trust Level 1 protege par l'hyperviseur Hyper-V via Virtualization-Based Security (VBS). Le processus LSASS classique communique avec LSAIso uniquement via des RPC validees, sans jamais avoir acces aux hashes en clair memoire. Mimikatz sekurlsa::logonpasswords retourne alors uniquement « LSA Isolated Data: NtlmHash : encrypted ». Voir la documentation Microsoft Credential Guard.

Limites : Credential Guard ne protege que les derived credentials en cache, pas les hashes du SAM local ni du NTDS.dit. Un attaquant DA peut toujours faire un DCSync.

LSA Protection (RunAsPPL)

LSA Protection active LSASS en mode Protected Process Light (PPL) via la cle registre HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL=1. Cela empeche les processus non signes par Microsoft d'ouvrir un handle PROCESS_VM_READ sur LSASS, bloquant les dumps Mimikatz/procdump classiques. Bypass connus : PPLDump, PPLBlade, NanoDump --pid lsass.exe avec exploitation MiniDumpWriteDump via le service Comsvcs ou Werfault.

Restricted Admin Mode RDP

Restricted Admin mode (KB2871997) modifie le comportement RDP/PSRemoting pour ne pas envoyer les credentials du compte vers la machine distante. Au lieu de cela, l'authentification se fait par Network Logon (type 3) : aucun hash n'est mis en cache LSASS sur la machine cible, neutralisant le scenario classique « je RDP sur un serveur, l'admin de support y a laisse son hash ». Active via GPO ou cle DisableRestrictedAdmin=0.

Windows Defender Credential Stealing rules

Microsoft Defender for Endpoint inclut une regle ASR (Attack Surface Reduction) dediee : « Block credential stealing from the Windows local security authority subsystem » (GUID 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2). Recommandation Microsoft : activer en mode Enforce sur tous les endpoints.

Tier model et cloisonnement : LAPS, comptes admin separes

La mitigation strategique de Pass-the-Hash passe par l'architecture, non pas la technique. Microsoft preconise depuis 2014 le modele Tier 0/1/2 (rebaptise Enterprise Access Model en 2021) :

  • Tier 0 : DC, ADCS, ADFS, AAD Connect, comptes DA. Seuls les comptes Tier 0 administrent Tier 0.
  • Tier 1 : serveurs applicatifs, SQL, fichiers. Comptes admin serveur dedies, jamais loggues sur les postes.
  • Tier 2 : postes de travail, helpdesk. Comptes admin poste dedies, jamais loggues sur serveurs.

Cette separation empeche un PtH issu d'un poste compromis de pivoter vers un serveur ou un DC.

LAPS (Local Administrator Password Solution) et son successeur Windows LAPS integre nativement (Windows 10 22H2+, Server 2019+) randomisent automatiquement le mot de passe du compte admin local sur chaque machine et le stockent chiffre dans un attribut AD. Resultat : le hash NT de BUILTIN\Administrator est different sur chaque poste, neutralisant la propagation laterale par PtH du compte admin local universel — historiquement la pire pratique des environnements Microsoft. Pour la defense AD globale, voir notre guide securite Active Directory.

Detection : Event 4624 LogonType 9 et autres

Plusieurs signaux Windows Event Log et EDR permettent de detecter Pass-the-Hash avec une precision raisonnable.

Windows Security Event 4624 LogonType=9

Lorsque sekurlsa::pth ou un appel LogonUserExEx avec LOGON32_LOGON_NEW_CREDENTIALS est invoque, l'evenement 4624 est journalise avec LogonType=9 et LogonProcessName=seclogo (Secondary Logon). C'est l'indicateur primaire historique. Regle Sigma type :

title: Mimikatz Pass-the-Hash via NewCredentials Logon
detection:
  selection:
    EventID: 4624
    LogonType: 9
    LogonProcessName: 'seclogo'
    AuthenticationPackageName: 'Negotiate'
  condition: selection

Event 4648 — Logon with explicit credentials

L'evenement 4648 est genere lorsque PtH lance un processus avec des credentials explicites differents du compte courant. Couple a 4624/9, cela renforce la detection.

Microsoft Defender for Identity

Defender for Identity (MDI), anciennement Azure ATP, deploye via capteurs sur les DC, detecte specifiquement « Suspected identity theft (pass-the-hash) » en correlant des authentifications NTLM anormales depuis une machine non typique pour le compte. Integration native dans Microsoft Defender XDR et Sentinel.

Sentinel UEBA et regles analytics

Microsoft Sentinel propose des regles analytiques natives :

  • « Pass-the-hash attempt » base sur SecurityEvent 4624/4648.
  • « Anomalous NTLM authentication » via UEBA (anomaly score).
  • Regles communautaires sur le repo Azure-Sentinel.

Detection Sysmon : Event 10 ProcessAccess sur LSASS

Sysmon reste l'outil de detection comportementale gratuit le plus efficace. Trois evenements cles tracent les operations precurseurs a PtH (extraction de hash) :

  • Event 10 (ProcessAccess) : declenche lorsqu'un processus ouvre un handle vers lsass.exe avec GrantedAccess incluant 0x1010 (PROCESS_VM_READ + PROCESS_QUERY_LIMITED_INFORMATION) — signature classique Mimikatz.
  • Event 8 (CreateRemoteThread) : injection cross-process, precurseur de techniques PtH stealth.
  • Event 1 (Process Create) avec ligne de commande contenant sekurlsa, privilege::debug, -hashes, --ntlm-hash.

Configuration Sysmon recommandee : utiliser le template SwiftOnSecurity ou Olaf Hartong qui inclut la regle suivante :

<ProcessAccess onmatch="include">
  <TargetImage condition="image">lsass.exe</TargetImage>
  <GrantedAccess condition="contains">0x10</GrantedAccess>
</ProcessAccess>

Bonnes pratiques de durcissement 2026

Une posture defensive complete contre Pass-the-Hash combine les controles suivants :

  • Activer Credential Guard sur tous les endpoints Windows 10/11 Enterprise et serveurs membres compatibles (CPU SLAT + IOMMU + UEFI Secure Boot).
  • Activer LSA Protection (RunAsPPL) via GPO sur tous les serveurs et postes.
  • Deployer Windows LAPS sur 100% du parc, avec rotation tous les 30 jours et complexite >= 14 caracteres.
  • Implementer le modele Tier avec PAW (Privileged Access Workstations) pour Tier 0.
  • Auditer NTLM via les GPO Network Security: Restrict NTLM: Audit Incoming NTLM Traffic et Outgoing NTLM Traffic, puis migrer progressivement vers Kerberos uniquement.
  • Desactiver NTLMv1 integralement via LMCompatibilityLevel = 5 sur DC et clients.
  • Forcer SMB Signing et SMB Encryption sur les serveurs sensibles.
  • Activer Restricted Admin Mode pour les sessions RDP des comptes priviligies.
  • Ajouter les comptes priviligies au groupe Protected Users.
  • Configurer les ASR rules Defender bloquant le credential stealing.
  • Surveiller les Event 4624/9 et Sysmon Event 10 sur LSASS dans le SIEM.
  • Mener un pentest interne annuel ciblant explicitement les chemins PtH — voir notre offre pentest Active Directory.

CVE notables liees a Pass-the-Hash et NTLM

Plusieurs vulnerabilites historiques amplifient la portee de Pass-the-Hash en facilitant l'obtention initiale de hashes ou en contournant des mitigations :

  • CVE-2021-26414 (DCOM Hardening) : downgrade NTLM possible via DCOM si le client n'enforce pas l'integrite. Permet a un attaquant MITM de forcer NTLMv1 et faciliter le cracking offline.
  • CVE-2022-26925 (PetitPotam) : coercition d'authentification NTLM d'un DC vers un attaquant via MS-EFSRPC, permettant la capture du hash machine du DC. Combine avec ADCS ESC8, mene a la prise de domaine complete.
  • CVE-2021-36942 (Original PetitPotam) : identique, decouvert par GILLES Lionel.
  • CVE-2019-1040 (NTLM Relay Tampering) : bypass de la protection MIC NTLM permettant le relay vers des services proteges.
  • CVE-2022-30216 (Windows Server Service Tampering) : permet de modifier des entrees dans la base SAM/LSA.
  • CVE-2025-21275 (Windows AppX Deployment Service EoP) : escalation locale facilitant l'acces SeDebugPrivilege necessaire au dump LSASS.

Microsoft publie regulierement les NTLM hardening updates (KB5005413, KB5037422) que les administrateurs doivent appliquer integralement.

MITRE ATT&CK : mapping complet de Pass-the-Hash

Pass-the-Hash s'inscrit dans une chaine d'attaque MITRE ATT&CK que les SOC doivent cartographier :

  • T1003 — OS Credential Dumping : prerequis. Sous-techniques principales : T1003.001 (LSASS Memory), T1003.002 (Security Account Manager), T1003.003 (NTDS).
  • T1550 — Use Alternate Authentication Material : technique parente.
  • T1550.002 — Pass the Hash : la technique elle-meme. Tactique : Lateral Movement, Defense Evasion.
  • T1550.003 — Pass the Ticket : technique connexe Kerberos.
  • T1558 — Steal or Forge Kerberos Tickets : famille incluant Overpass-the-Hash, Golden Ticket, Silver Ticket, Kerberoasting.
  • T1021.002 — SMB/Windows Admin Shares : execution post-PtH typique (ADMIN$, C$, IPC$).
  • T1021.006 — Windows Remote Management : execution post-PtH via WinRM.
  • T1078.002 — Valid Accounts: Domain Accounts : reutilisation de credentials valides.

Cette cartographie permet aux equipes Detection Engineering de structurer leur couverture : pour chaque technique, definir au moins une regle Sigma, un cas d'usage Sentinel/Splunk et un test Atomic Red Team.

FAQ : questions frequentes sur Pass-the-Hash

Credential Guard suffit-il a stopper Pass-the-Hash ?

Credential Guard reduit considerablement la surface d'attaque mais ne suffit pas seul. Il protege les hashes derives en cache LSASS sur l'endpoint actif, mais ne protege pas les hashes stockes dans le SAM local, ni dans NTDS.dit, ni les credentials extraits via DPAPI ou backup. Une defense robuste combine Credential Guard avec LAPS, modele Tier, LSA Protection, ASR rules et detection SIEM. Microsoft considere d'ailleurs Credential Guard comme une deterrence, non une prevention absolue.

LAPS protege-t-il contre Pass-the-Hash ?

LAPS protege specifiquement contre la propagation laterale du compte admin local, qui est historiquement le scenario PtH le plus devastateur (un meme hash Administrator sur 5000 postes via image master). Avec LAPS, chaque machine a un mot de passe admin local unique et tournant, donc un hash unique. PtH reste possible sur la machine compromise, mais ne pivote plus vers les autres. LAPS ne protege pas contre PtH avec un compte de domaine.

Si je desactive NTLM completement, Pass-the-Hash disparait-il ?

La desactivation totale de NTLM (via Network Security: Restrict NTLM: NTLM authentication in this domain = Deny all) elimine bien Pass-the-Hash classique. Cependant, l'attaquant peut basculer vers Overpass-the-Hash qui utilise le hash NT pour demander un TGT Kerberos puis exploite Kerberos. La defense est donc partielle : il faut combiner avec Protected Users (qui force AES uniquement) et LAPS. La desactivation NTLM brise par ailleurs de nombreuses applications legacy — un audit prealable est imperatif via les GPO d'audit NTLM.

OAuth 2.0 et Kerberos remplacent-ils NTLM en 2026 ?

Pour les applications modernes oui : Microsoft 365, Azure / Entra ID, applications SaaS utilisent OAuth 2.0 / OpenID Connect avec MFA et conditional access — totalement immunises contre PtH. Pour le legacy on-premises, NTLM reste massivement deploye (file shares, applications metier, imprimantes, NAS). Microsoft a annonce la depreciation progressive de NTLM a partir de Windows 11 24H2 et Server 2025 avec deux remplacements : Kerberos avec IAKerb (Initial and Pass Through Authentication Using Kerberos) et Local KDC pour les comptes locaux. Cette migration s'etalera sur 5 ans.

Pass-the-Hash fonctionne-t-il contre Linux Samba ?

Oui, partiellement. Samba implemente NTLM/NTLMv2 cote serveur (smbd) et accepte les hashes NT pour l'authentification, donc PtH est exploitable contre des serveurs de fichiers Samba mal configures. Cote client, les outils Linux (smbclient, mount.cifs, Impacket) utilisent nativement les hashes via l'option --pw-nt-hash. Toutefois, Samba 4.18+ supporte Kerberos AES par defaut et peut etre configure en server signing = mandatory + client ntlmv2 auth = yes + client min protocol = SMB3 pour reduire la surface d'attaque NTLM.

Comment tester ma resistance a Pass-the-Hash ?

Trois approches complementaires : (1) exercice Atomic Red Team avec les tests T1550.002 (atomics 1 a 5) en environnement de pre-production ; (2) audit de configuration via PingCastle, Purple Knight ou les Microsoft Security Compliance Toolkit baselines pour verifier Credential Guard, LSA Protection et LAPS ; (3) mission de pentest interne dediee Active Directory simulant un attaquant ayant compromis un poste utilisateur — c'est typiquement l'objet de notre offre pentest AD.

Liens approfondis et ressources