Dans un environnement Active Directory compromis, l'attaquant n'a généralement pas besoin de craquer un seul mot de passe. Il lui suffit de récupérer les bons artefacts d'authentification, puis de les rejouer. C'est là que Pass-the-Hash et Pass-the-Ticket entrent en scène, deux techniques distinctes dans leur mécanique, mais identiques dans leur finalité : se propager latéralement en usurpant des identités légitimes.
Comment fonctionne le Pass-the-Hash
Le Pass-the-Hash (PtH) exploite le protocole NTLM. Lors d'une authentification NTLM, Windows n'envoie jamais le mot de passe en clair : il transmet un hash dérivé de ce mot de passe. Si un attaquant parvient à extraire ce hash depuis la mémoire du processus lsass.exe, il peut l'injecter directement dans une session d'authentification sans jamais connaître le mot de passe originel.
Avec Mimikatz, la commande sekurlsa::logonpasswords suffit à extraire les hashes NTLM stockés dans LSASS. Ensuite, sekurlsa::pth /user:admin /domain:corp.local /ntlm:<hash> /run:cmd.exe ouvre un shell Windows avec les jetons d'accès de l'utilisateur ciblé. L'attaquant peut alors accéder à des partages réseau, des services RPC ou des consoles d'administration comme s'il était l'utilisateur légitime, sans déclencher d'alerte de mot de passe incorrect.
Pourquoi NTLM reste dangereux même en 2025
NTLM est un protocole ancien, mais il reste activé par défaut dans la plupart des environnements AD pour des raisons de compatibilité. Tant que des systèmes anciens, des imprimantes réseau ou des applications métier l'exigent, désactiver complètement NTLM reste difficile en production. C'est cette inertie technologique qui maintient PtH comme vecteur viable.
Pass-the-Ticket : l'exploitation du protocole Kerberos
Le Pass-the-Ticket (PtT) opère sur une logique différente. Kerberos s'appuie sur des tickets signés par le KDC (Key Distribution Center). Un Ticket Granting Ticket (TGT) prouve l'identité d'un utilisateur auprès du KDC, tandis qu'un Ticket de Service (TGS) autorise l'accès à une ressource spécifique. Si un attaquant vole l'un de ces tickets depuis la mémoire, il peut le réinjecter dans sa propre session et accéder aux ressources associées.
Rubeus est l'outil de référence pour cette technique. La commande Rubeus.exe dump /luid:<id> extrait les tickets Kerberos actifs. Rubeus.exe ptt /ticket:<base64_ticket> les injecte ensuite dans la session courante. Contrairement au PtH, cette approche ne génère aucune authentification NTLM : tout transite via Kerberos, ce qui rend la détection plus difficile pour les outils qui surveillent exclusivement NTLM.
Golden Ticket et Silver Ticket : les variantes avancées
Le PtT ouvre la porte à deux variantes particulièrement destructrices. Le Golden Ticket consiste à forger un TGT arbitraire en utilisant le hash du compte krbtgt — le compte qui signe tous les tickets Kerberos du domaine. Une fois ce hash obtenu, l'attaquant peut créer des tickets valides pour n'importe quel utilisateur, y compris des comptes inexistants, pour une durée de son choix. Le Silver Ticket, lui, forge directement un TGS pour un service précis en utilisant le hash du compte de service, sans même contacter le KDC.
Tableau comparatif des deux vecteurs
Les deux techniques ciblent la mémoire de processus pour voler des artefacts d'authentification, mais leurs différences sont importantes pour la détection et la remédiation. PtH dépend de NTLM et génère des événements Windows identifiables (Event ID 4624, type de connexion 3). PtT reste dans l'écosystème Kerberos et est beaucoup plus silencieux sur les endpoints classiques. PtH fonctionne sur n'importe quel service acceptant NTLM ; PtT est limité aux services intégrés à Kerberos, mais cela couvre la quasi-totalité d'un environnement AD standard.
Pourquoi Credential Guard neutralise ces deux vecteurs
Credential Guard isole LSASS dans un environnement d'exécution sécurisé basé sur la virtualisation (VSB, Virtualization Based Security). Concrètement, le processus LSASS protégé tourne dans une enclave matérielle que le noyau Windows lui-même ne peut pas adresser directement. Mimikatz, qui injecte du code dans LSASS ou lit sa mémoire via des handles noyau, se retrouve bloqué : les secrets (hashes NTLM, tickets Kerberos) ne sont plus accessibles depuis le ring 0 classique.
Pour PtH, l'impact est direct : sans accès aux hashes NTLM en mémoire, pas d'extraction, pas de rejeu. Pour PtT, Credential Guard empêche l'extraction des tickets Kerberos stockés dans LSASS, rendant les commandes sekurlsa::tickets de Mimikatz et Rubeus.exe dump inefficaces contre les sessions protégées.
Les limites réelles de Credential Guard
Credential Guard est une protection solide, mais elle n'est pas une solution universelle. Plusieurs limites méritent d'être comprises clairement avant de considérer que le problème est réglé.
Couverture partielle des comptes
Les comptes de domaine interactifs bénéficient de la protection VSB, mais les comptes de service configurés avec une authentification déléguée (Kerberos non contrainte) peuvent encore exposer des tickets exploitables. De même, si un serveur membre du domaine n'a pas Credential Guard activé, il reste une cible valide même si les postes clients sont protégés.
Contournements documentés
Des recherches publiées montrent que certaines configurations de délégation Kerberos non contrainte permettent de capturer des TGT directement via des techniques de coercition d'authentification (comme PetitPotam ou PrinterBug), sans jamais toucher à LSASS. Credential Guard ne protège pas contre ces vecteurs réseau. Par ailleurs, sur des systèmes où le mode noyau peut être altéré via des pilotes vulnérables (BYOVD), la frontière VSB peut être contournée.
Compatibilité et déploiement
Credential Guard nécessite du matériel compatible UEFI Secure Boot et TPM 2.0, ainsi qu'une version de Windows Pro ou Enterprise. Dans les parcs hétérogènes courants au Maroc et en Afrique subsaharienne, une fraction significative des endpoints ne remplit pas ces prérequis, laissant des zones d'ombre dans la posture de défense globale. La protection est aussi incompatible avec certaines solutions de virtualisation imbriquée.
Ce que Credential Guard ne remplace pas
Même parfaitement déployé, Credential Guard ne protège pas contre le vol de credentials via des keyloggers, les attaques sur la base NTDS.dit du contrôleur de domaine, ou l'abus de permissions AD mal configurées. Il réduit la surface d'attaque en mémoire, rien de plus.
Questions fréquentes
Quelle est la différence principale entre Pass-the-Hash et Pass-the-Ticket ?
PtH exploite le protocole NTLM en rejouant un hash extrait de LSASS, tandis que PtT opère sur Kerberos en réinjectant des tickets volés. Les deux évitent l'usage du mot de passe en clair, mais leurs mécanismes d'authentification sous-jacents sont différents, ce qui implique des stratégies de détection distinctes.
Credential Guard protège-t-il contre les Golden Tickets ?
Credential Guard empêche l'extraction du hash krbtgt depuis LSASS sur les machines protégées. Mais si ce hash est obtenu autrement, par exemple via une attaque DCSync sur le contrôleur de domaine, la protection ne s'applique plus. La sécurisation du compte krbtgt et la surveillance des réplications AD restent indispensables.
Peut-on détecter ces attaques sans EDR avancé ?
Partiellement. Les Event IDs Windows (4624, 4768, 4769) fournissent des signaux utiles, notamment pour détecter des connexions NTLM anormales ou des demandes de tickets Kerberos inhabituelles. Mais sans corrélation dans un SIEM et sans baseline comportementale, ces événements passent facilement inaperçus dans le volume d'un Active Directory actif.
Rubeus est-il détecté par les antivirus classiques ?
Les signatures de Rubeus sont connues des antivirus, mais des variantes obfusquées ou recompilées contournent facilement ces détections. C'est pourquoi la défense en profondeur, combinant Credential Guard, surveillance Kerberos et EDR comportemental, est préférable à une approche basée uniquement sur la détection de signatures.