Lors de nos tests d’intrusion interne, il nous arrive régulièrement de compromettre l’Active Directory sans utiliser le moindre mot de passe. Cela est possible grâce à une attaque emblématique : le Pass-the-Hash (PtH).
Cette technique permet à un attaquant de s’authentifier sur un système Windows en réutilisant directement le hash du mot de passe d’un utilisateur, plutôt que le mot de passe lui-même.
Dans un précédent article, nous avions détaillé la nature du hash NTLM et le fonctionnement de l’authentification NTLM. Pour rappel, un hash NTLM est une représentation irréversible du mot de passe d’un utilisateur Windows, calculée selon l’algorithme MD4. De fait, deux mots de passe identiques produisent systématiquement le même hash, mais il est théoriquement impossible de retrouver le mot de passe initial à partir de ce hash seul.
Ce hash est utilisé par le protocole NTLM pour authentifier un utilisateur via un mécanisme de challenge/réponse. Ainsi, lors d’une authentification NTLM, le mot de passe n’est jamais envoyé directement : seul le hash est utilisé pour prouver l’identité de l’utilisateur.
Cependant, cette conception a conséquence majeure : détenir le hash NTLM d’un compte revient à détenir son mot de passe. En effet, Windows autorise l’authentification en utilisant directement ce hash, sans exiger la connaissance du secret d’origine. C’est précisément ce comportement qui rend possibles des attaques Pass-the-Hash. Un attaquant ayant compromis un poste peut extraire les hashes stockés en mémoire ou sur disque, puis les réutiliser pour effectuer des mouvements latéraux au sein du réseau.
Dans cet article, nous présenterons le modèle d’authentification Windows, en abordant notamment LSA, SAM et les SSP. Nous détaillerons ensuite le fonctionnement de l’attaque Pass-the-Hash et de ses différentes variantes (Pass-the-Ticket, Pass-the-Key et Pass-the-Certificate). Enfin, nous verrons leurs limites et les mécanismes existants pour s’en protéger.
Guide complet sur les attaques Pass-the-Hash
Secrets d’authentification sous Windows
Avant d’entrer dans le vif du sujet, il nous faut des secrets. Et nous disposons de différents moyens pour en trouver.
Tout commence souvent par un poste de travail compromis. Une fois des accès administrateur obtenus, un attaquant peut extraire différents secrets manipulés par le système d’authentification Windows, dont le cœur est le LSA (Local Security Authority).
Il est important de ne pas confondre le composant LSA qui est un modèle logique qui définit la manière dont Windows gère l’authentification et le processus lsass.exe, qui en est l’implémentation concrète. C’est lsass.exe qui charge les Security Support Providers (SSP), stocke et manipule en mémoire les « credentials », les jetons d’accès, et plus largement l’ensemble du contexte d’authentification.
Microsoft résume cette architecture avec le schéma suivant :
Ainsi, le processus LSASS (LSA Server Service) est au cœur du LSA. Il reçoit les identifiants de connexion principalement par le processus secure32 et communique ensuite avec différents Security Support Providers (SSP). Ces SSPs sont utilisés pour invoquer différents protocoles d’authentification. Ceux qui nous intéresse ici sont le SSP Msv1_0 qui gère le protocole NTLM et Kerberos qui gère… l’authentification Kerberos !
Si c’est une authentification à un compte local, le provider MSV1_0 va se référer à la base SAM. SAM (Security Account Manager) est une base de registre protégée dans laquelle Windows stocke de manière persistante les comptes locaux de la machine ainsi que leurs hash NTLM. On y trouve par exemple les identifiants du compte administrateur local ou des utilisateurs créés spécifiquement sur cette machine.
Les hash sont chiffrés à l’aide d’une clé dérivée du registre SYSTEM. Cependant, un attaquant disposant d’un accès administrateur peut contourner cette protection et extraire ces secrets hors ligne.
La SAM constitue toutefois une source limitée : elle ne contient que les comptes locaux, pas ceux du domaine Active Directory.
Récupération de secrets dans la base SAM
Pour récupérer le contenu de la base SAM, il faut disposer des droits SYSTEM ou du privilège SeBackupPrivilege permettant d’effectuer une sauvegarde de la ruche SAM. En plus de la ruche SAM, il faut récupérer la ruche SYSTEM qui contient la « bootkey » qui chiffre les données stockées dans la ruche SAM.
Avec Powershell, cela se fait facilement avec les commandes suivantes :
reg save HKLM\SAM sam.save
reg save HKLM\SYSTEM system.save
Une fois ces ruches récupérées, on peut utiliser l’outil secretsdump pour déchiffrer la SAM et accéder aux hash NTLM :
secretsdump -sam sam.save -system system.save LOCAL
D’autres outils comme mimikatz ou NetExec permettent également l’extraction de la base SAM. L’exemple suivant permet de récupérer les hash NTLM dans la base SAM avec mimikatz :
privilege::debug #On passe en mode debug
token::elevate #On impersonifie le token access de l’administrateur local
lsadump::sam #On dump la base SAM
Extraction de hash dans le service LSASS
Les autres secrets sont directement dans le processus LSASS. C’est en effet lui qui gère l’authentification, applique les politiques locales et génère les jetons d’accès qui déterminent les privilèges d’un utilisateur une fois connecté.
Un jeton d’accès (access token) est un objet interne contenant l’identité de l’utilisateur, ses groupes, ses privilèges et d’autres attributs nécessaires à l’autorisation. Toute action système passe par ce jeton, ce qui en fait une cible précieuse pour l’élévation ou l’usurpation de privilèges.
LSASS conserve donc en mémoire des éléments sensibles : hash NTLM, tickets Kerberos, clés de session, jetons d’accès, etc. Avec des droits administrateurs ou SYSTEM, un attaquant peut lire la mémoire de LSASS et extraire ces secrets.
Ainsi, un attaquant ayant un accès administrateur à un hôte Windows peut soit extraire les hash présents sur la machine via la SAM, soit les récupérer en mémoire via LSASS.
De nombreux outils permettent de réaliser ces actions à distance comme LSASSY ou encore NetExec.
Avec mimikatz, il faut utiliser la commande suivante :
Sekurlsa ::logonpasswords
Comprendre les attaques Pass-the-Hash, Pass-the-Ticket, Pass-the-Key et Pass-the-Certificate
Dans les environnements Windows et Active Directory, l’authentification repose sur différents types de secrets : hash NTLM, tickets Kerberos ou certificats.
C’est ainsi qu’est apparue toute une famille de techniques dont le principe est toujours le même : réutiliser un secret existant pour se faire passer pour un autre utilisateur, sans connaître son mot de passe ni compromettre son poste initial.
Le Pass-the-Hash (PtH) n’en est que la version la plus connue. À côté de lui existent d’autres techniques :
- Pass-the-Ticket pour injecter des tickets Kerberos,
- Pass-the-Certificate pour exploiter des certificats et clés associées,
- Pass-the-Key (Overpass-the-Hash) pour convertir un hash NTLM en identité Kerberos,
Ensemble, ces techniques forment le cœur du mouvement latéral dans un réseau compromis.
Pass-the-Hash
Fonctionnement de l’attaque Pass-the-Hash
Le Pass-the-Hash est une technique qui exploite une particularité historique du protocole NTLM : le hash NTLM d’un utilisateur peut être utilisé comme substitut du mot de passe, sans qu’il soit nécessaire de connaître le mot de passe lui-même.
Concrètement, lors des audits internes, après avoir compromis un premier poste, on va récupérer les secrets de la machine compromise et essayer les hash NTLM sur les autres machines, dans l’espoir d’accéder à de nouvelles ressources.
Pour ce faire, on utilise l’outil NetExec :
nxc smb <plage-ip> -u <user> -H <hash-NTLM>Dans l’exemple suivant, on constate qu’on peut s’authentifier avec le compte « daenerys.targaryen » sur la machine avec son hash NTLM et accéder, par exemple, aux partages réseaux :
Le compte « daenerys.targaryen » étant administrateur du système cible, il est même possible d’exécuter des commandes sur ce système :
Prévenir les attaques Pass-the-Hash
Restreindre NTLM
Pour réussir un Pass-the-Hash, il faut que la machine accepte l’authentification NTLM. Nous rencontrons parfois (trop peu souvent) une configuration durcie des postes de travail qui refuse l’authentification NTLM.
Pour ce faire, il est nécessaire d’appliquer la GPO suivante :
Network Security: Restrict NTLM: NTLM authentication in this domain => Deny All
Attention toutefois, ce paramétrage peut être contraignant. Il convient de s’assurer qu’aucun de vos services critiques ne repose sur le protocole NTLM pour s’authentifier et qu’ils supportent l’authentification Kerberos.
Il est recommandé dans un premier temps de paramétrer Network Security: Restrict NTLM: Audit Incoming NTLM Traffic => Enable auditing for domain accounts etNetwork Security: Restrict NTLM: Audit NTLM authentication in this domain => Enable all afin d’analyser les authentifications NTLM qui sont réalisées.
Maintenant, il n’est plus possible d’utiliser le hash NTLM de l’utilisateur pour s’authentifier sur la machine :
Ajouter les comptes utilisateurs sensibles au groupe « Protected users »
Il peut également être envisagé d’ajouter les comptes utilisateurs sensibles au groupe « Protected users ». Ce groupe spécifique de l’Active Directory bénéficie d’une sécurité durcie. En effet, les comptes de ce groupe qui s’authentifient auprès d’une machine du domaine ne peuvent pas effectuer les opérations suivantes :
- S’authentifier avec l’authentification NTLM ;
- Utilisez des types de chiffrement DES ou RC4 dans la pré-authentification Kerberos.
- Déléguer avec une délégation contrainte ou sans contrainte.
- Renouveler des tickets TGT Kerberos au-delà de la durée de vie initiale de 4 heures ;
Ainsi après avoir ajouté le compte « daenerys.targaryen » au groupe « Protected Users », il n’est plus possible d’utiliser le protocole NTLM pour s’authentifier à la machine avec ce compte, comme le montre la capture suivante :
De plus, les hash NTLM des comptes du groupe « Protected Users » ne sont plus stockés en mémoire par le processus lsass.exe.
Sur les captures suivantes, nous constatons que le hash NTLM du compte « daenerys.targaryen » n’est plus présent, contrairement au hash du compte « jorah.mormont » qui ne fait pas partie du groupe « protected users ».
Pass-the-Ticket (PtT)
Principe de l’attaque Pass-the-Ticket
Dans un environnement Active Directory moderne, Kerberos est le protocole d’authentification par défaut. Lorsqu’un utilisateur s’authentifie, il obtient un ticket TGT (Ticket Granting Ticket) émis par le contrôleur de domaine, puis des tickets de service (TGS) pour accéder aux ressources du réseau.
Sous Windows, les tickets Kerberos sont stockés en mémoire dans un format propriétaire appelé KIRBI. Les systèmes Linux et UNIX, quant à eux, s’appuient sur l’implémentation MIT Kerberos et utilisent des tickets au format CCACHE.
Le Pass-the-Ticket est une technique qui exploite une particularité du protocole Kerberos : un ticket Kerberos déjà émis pour un utilisateur peut être réutilisé tel quel, sans connaître son mot de passe ni interagir à nouveau avec le contrôleur de domaine.
Comme pour Pass-the-Hash, il ne s’agit pas d’une vulnérabilité mais d’un détournement d’un fonctionnement parfaitement normal. Avec Kerberos, tout ticket valable est légitime, quelle que soit la manière dont il a été obtenu.
Concrètement, lors d’un pentest interne, après la compromission d’un poste, on peut extraire les tickets Kerberos présents en mémoire et les injecter dans une nouvelle session afin d’usurper l’identité associée. Cela permet d’accéder directement à des ressources Active Directory.
Le Pass-the-Ticket s’applique aussi bien aux tickets TGT qu’aux tickets de service TGS, les premiers offrants souvent davantage de possibilités de mouvement latéral.
Déroulé de l’attaque Pass-the-Ticket
Cette fois ci, nous allons utiliser Rubeus pour extraire les tickets (d’autres outils comme mimikatz le font très bien également) qui se trouvent… dans le processus LSASS !
Pour cela, on utilise la commande suivante :
Rubeus.exe dump /service:krbtgtAvec cette commande, on récupère tous les tickets TGT au format kirbi encodé en base64.
Le ticket peut être directement injecté dans la session en cours avec la commande suivante :
Rubeus.exe ptt /ticket :doIF<kirbi base64 TGT>
Il est maintenant possible d’utiliser les privilèges liés à ce TGT.
Conversion des tickets
Pour pouvoir utiliser ce ticket avec un poste UNIX, il est nécessaire de convertir ce fichier .kirbi en fichier .ccache. En effet, les systèmes UNIX implémente le standard MIT Kerberos contrairement à Microsoft, ce qui nécessite un petit jeu de conversion pour pouvoir utiliser ces ticket Kerberos.
Cette conversion peut se faire avec l’outil « ticketConverter »
base64 -d tgt.b64 > tgt.kirbi
ticketConverter.py tgt.kirbi tgt.ccacheUne fois converti au format .ccache, la majorité des outils utilisés lors des audits interne implémente l’authentification Kerberos avec l’option -k/–use-kcache, après avoir définit la variable d’environnement KRB5CCNAME sur notre fichier .ccache
export KRB5CCNAME=$path_to_ticket.ccacheNous pouvons maintenant utiliser le ticket TGT compromis avec nos outils et continuer notre compromission du réseau interne :
nxc smb <TARGET> --use-kcache -u “<username>”
Note : Rubeus.exe est un outil développé spécifiquement pour interagir avec Kerberos et en abuser. Il est également très utilisé pour forger les golden, silver et diamond tickets qui seront abordé dans un article futur.
Bien évidemment, mimikatz permet également de récupérer ces tickets directement au format kirbi (non encodé en base64) avec la commande suivante :
Mimikatz# sekurlsa::tickets /exportDepuis la version 1.5.0, netexec permet également de récupérer les tickets TGT au format ccache ou kirbi :
nxc smb <ip> -u <username> -p <password> -M lsassy -o SAVE_DIR="./tickets" SAVE_TYPE="ccache"
Pass-the-Key (Overpass-the-Hash)
Qu’est-ce qu’un attaque Pass-the-Key ?
Le Pass-the-Key désigne la possibilité d’obtenir un ticket TGT d’un utilisateur sans connaître son mot de passe mais en utilisant ses clés secrètes (DES, RC4, AES128 or AES256).
L’utilisation du hash NTLM (RC4) pour réaliser le Pass-the-Key est la plus connue, elle est même nommée « l’Overpass-the-Hash ». Cette technique s’appuie sur le fait que, dans un environnement Active Directory, le hash NTLM d’un utilisateur peut servir indirectement à obtenir des tickets Kerberos, sans que le mot de passe en clair ne soit jamais connu.
Là où le Pass-the-Hash permet d’abuser directement des mécanismes NTLM, l’Overpass-the-Hash vise à utiliser un hash NTLM pour obtenir un ticket Kerberos, afin de plus facilement compromettre des environnements où NTLM est limité, surveillé ou partiellement désactivé.
Fonctionnement de l’attaque Pass-the-Key
Sur le plan technique, cette approche exploite le fonctionnement interne de l’authentification Windows : lors d’une authentification Kerberos, le secret de l’utilisateur est utilisé pour dériver des clés cryptographiques servant à la génération du TGT. Lorsque seules certaines méthodes sont disponibles, le hash NTLM peut être utilisé pour initier une authentification Kerberos valide. Le contrôleur de domaine ne fait alors aucune distinction entre un secret issu d’un mot de passe et un secret fourni sous forme de hash, tant que les calculs cryptographiques sont corrects.
Dans un contexte d’audit interne, l’Overpass-the-Hash permet ainsi de contourner les limitations du Pass-the-Hash classique, notamment lorsque les services cibles privilégient Kerberos ou refusent les authentifications NTLM. Une fois un ticket Kerberos obtenu, l’attaquant peut interagir avec les ressources du domaine de manière légitime, en utilisant les mêmes mécanismes qu’un utilisateur authentifié normalement. Cette technique démontre que tant que les NTLM peuvent être utilisé, Kerberos n’est jamais totalement isolé.
Avec l’outil getTGT.py (de la suite Impacket), il est ainsi possible de récupérer un ticket TGT depuis un hash NTLM compromis :
getTGT.py -dc-ip "<dc-ip>" -hashes "<hash-NTLM>" "<domain>"/"<username>"Dans la capture ci-dessous, nous récupérerons un ticket TGT que nous pouvons par la suite utiliser avec l’option « –use-kcache » de netexec.
Pass-the-Certificate
Après les mécanismes basés sur les secrets symétriques (hash NTLM) et les tickets Kerberos, il existe une troisième famille de techniques d’usurpation d’identité reposant sur la cryptographie asymétrique : le Pass-the-Certificate.
En quoi consiste le Pass-the-Certificate ?
Cette approche s’appuie sur l’utilisation de certificats X.509 et de clés privées comme moyen d’authentification, un mécanisme de plus en plus répandu dans les environnements Active Directory modernes via Active Directory Certificate Services (AD CS).
Dans un domaine AD, un certificat peut être associé à un utilisateur ou à un ordinateur et servir de facteur d’authentification fort, notamment via PKINIT (Public Key Cryptography for Initial Authentication in Kerberos). Contrairement à NTLM ou Kerberos classique, l’authentification ne repose plus sur un mot de passe ou un secret partagé, mais sur la possession d’une clé privée correspondant à un certificat reconnu par l’autorité de certification du domaine. Du point de vue du contrôleur de domaine, toute entité capable de prouver la possession de cette clé privée est considérée comme légitime.
Ainsi, un attaquant en possession du certificat et de sa clé privée peut usurper l’identité auquel le certificat est lié.
Fonctionnement de l’attaque Pass-the-Certificate
Les certificats peuvent être trouvés à plusieurs endroits, comme dans le magasin de certificats Windows, mais le plus courant, lors d’audits internes, c’est de découvrir des certificats exportés au format PFX ou P12, parfois accompagnés de leur clé privée, stockés dans des partages réseaux ou sur des postes d’administration. Ces éléments peuvent également se retrouver dans des archives applicatives ou à des scripts d’administration ayant été conçus pour faciliter des déploiements ou des automatisations.
Mimikatz peut être utilisé pour extraire les certificats d’un poste compromis :
crypto::capi
privilege::debug
crypto::certificates /systemstore:local_machine /store:my /export
Une fois en possession d’un certificat au format PFX, on peut l’utiliser pour s’authentifier et récupérer le hash NTLM du compte associé au certificat :
certipy auth -pfx administrator.pfx -dc-ip 10.6.10.12Mesures de prévention
Le point commun à l’ensemble de ces techniques est clair : la récupération et la réutilisation de secrets d’authentification déjà présents sur les postes ou les serveurs.
Dans la majorité des scénarios, le point de départ est la compromission d’un poste de travail, à partir duquel l’attaquant extrait des secrets stockés :
- en mémoire, dans le processus lsass.exe ;
- de manière persistante, dans la base SAM voire directement dans des répertoires du poste de travail (qui peuvent en plus être partagés sur le réseau) .
Les mesures de prévention efficaces visent donc avant tout à réduire la présence de ces secrets et à limiter leur exploitation.
Comme vu dans la partie Pass-the-Hash, l’ajout des comptes sensibles (administrateurs, comptes à privilèges, comptes techniques critiques) au groupe « Protected Users » constitue une mesure particulièrement efficace.
Ce groupe permet notamment de :
- empêcher l’utilisation de NTLM ;
- éviter le stockage du hash NTLM en mémoire ;
- forcer l’utilisation d’algorithmes Kerberos modernes (AES) ;
- limiter la durée de vie des TGT et interdire certaines formes de délégation.
Cela réduit drastiquement l’efficacité des attaques de type Pass-the-Hash, Pass-the-Key et, dans une certaine mesure, Pass-the-Ticket.
Interdire l’utilisation de NTLM permet également de se prémunir des attaques Pass-the-Hash.
LSASS peut faire l’objet d’un durcissement pour empêcher l’extraction de secrets en mémoire. Tout d’abord, LSASS peut être activé en mode protégé (RunAsPPL). Le mode « Protected Process Light » empêche les processus non autorisés de lire la mémoire de LSASS. Bien qu’il ne bloque pas toutes les attaques, il complique fortement l’utilisation d’outils comme Mimikatz ou Rubeus.
Il est également possible d’activer Credential Guard (par défaut depuis Windows 11 version 22H2). Credential Guard est une fonctionnalité de sécurité Windows qui isole les secrets d’authentification dans un environnement sécurisé basé sur la virtualisation (VBS). Les credentials ne sont plus directement accessibles par le processus lsass.exe, mais stockés dans un conteneur protégé auquel même un attaquant disposant de privilèges SYSTEM ne peut pas accéder. Cela empêche efficacement l’extraction de secrets en mémoire.
La documentation Microsoft permet d’en apprendre plus sur la protection de LSA et Credential Guard.
Sources :
https://learn.microsoft.com/fr-fr/windows/win32/secauthz/access-tokens
https://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating-Pass-the-Hash-Attacks-and-Other-Credential-Theft-Version-2.pdf
https://learn.microsoft.com/fr-fr/windows/win32/secauthn/lsa-authentication
https://learn.microsoft.com/fr-fr/windows/win32/secauthn/lsa-authentication-model
https://beta.hackndo.com/pass-the-hash
https://beta.hackndo.com/remote-lsass-dump-passwords
https://github.com/gentilkiwi/mimikatz
Auteur : Adrien HOC – Pentester @Vaadata