Dans un environnement de bureau, les postes utilisateurs utilisent généralement le système d’exploitation Windows et s’authentifient donc via des protocoles développés par Microsoft.
Et pour centraliser la gestion de l’authentification, Microsoft propose son Active Directory (AD) qui s’appuie sur le protocole Kerberos. Cependant, certaines machines n’implémentent pas ce protocole et certains réseaux ne sont tout simplement pas pourvus d’un Active Directory. Dans ces cas de figure, il existe le protocole NTLM, qui peut fonctionner entre deux machines sans AD ou via le processus Netlogon.
Dans cet article, nous expliciterons le principe et le fonctionnement de l’authentification NTLM, tout en présentant, cas concrets à l’appui, une des attaques les plus courantes sur ce protocole, à savoir les attaques « NTLM Relay » ou attaques par relais NTLM.
Plan détaillé :
Qu’est-ce que NTLM ?
NTLM (New Technology LAN Manager) est une suite de protocoles d’authentification développés par Microsoft permettant de confirmer l’identité des utilisateurs et de protéger l’intégrité et la confidentialité de leurs activités sur un réseau.
L’authentification s’effectue via une communication directe entre un client et le serveur cible, communément appelé challenge/réponse NTLM.
Par ailleurs, NTLM est inclut dans la plupart des protocoles connus tels que HTTP, SMB, FTP, SQL, LDAP, etc. En revanche, il est important de noter que tous les échanges client-serveur sont effectués en clair sur le réseau.
Ainsi, en théorie, un attaquant en position Man in the Middle (MiTM) peut donc intercepter et rejouer toutes les communications. Mais pour sécuriser cette authentification et contrer ce défaut de chiffrement, il existe de nombreuses solutions éprouvées.
Comment fonctionne l’authentification NTLM ?
Le principe de l’authentification NTLM est le suivant :
- En premier lieu, le client indique au serveur qu’il souhaite s’authentifier.
- Puis, le serveur répond avec un défi, ou un challenge, qui n’est rien d’autre qu’une suite aléatoire de caractères.
- Ensuite, le client chiffre ce challenge avec son secret (hash NT de son mot de passe), et renvoie le résultat au serveur, c’est sa réponse.
NB : Le hash NT est souvent mentionné avec le hash LM. Et même si le hash LM n’est actuellement plus utilisé par les systèmes Windows récents, il peut toujours être présent dans le système de fichier par souci de rétrocompatibilité.
En effet, le hash LM fut l’ancienne méthode Windows pour le stockage de mots de passe.
Cependant, elle comportait de nombreux désavantages. Celle-ci ne considérait que les 14 premiers caractères du mot de passe et était insensible à la case. Cette méthode a donc été abandonnée au fur et à mesure des versions de Windows et le hash NT est devenu la méthode de stockage par défaut depuis Windows vista.
- Enfin, le serveur effectue la même opération avec le hash du mot de passe correspondant au nom de domaine et au nom d’utilisateur voulant s’authentifier. Il compare ensuite le résultat avec celui envoyé par le client. Si la comparaison est valide, le client est authentifié sur le serveur. Cette opération est possible car Windows stocke les condensats (NT et LM) des mots de passe utilisateurs locaux et distants dans la base de données SAM (Security Account Manager).
L’intérêt de cet échange est de permettre une authentification sans divulgation du mot de passe de l’utilisateur. On parle alors de preuve à divulgation nulle de connaissance, ce qui permet à un utilisateur de prouver qu’il détient réellement son secret sans jamais le partager.
Cependant, il arrive souvent que l’on fasse mention de l’expression « hash NTLM », ce qui est un abus de langage. En effet, certains appellent « hash NTLM » la réponse au challenge tandis que d’autres parlent de « hash NTLM » pour le condensant NT du mot de passe de l’utilisateur, ce qui se nomme en réalité le hash NT.
Afin d’éviter la confusion entre le protocole NTLM, la réponse au challenge NTLM, et le condensant NT du mot de passe utilisateur, nous allons utiliser les termes suivants :
- Réponse au challenge NTLM = hash NET-NTLM
- Condensant NT = hash NT
NTLM : un protocole d’authentification, deux versions (NTLMv1 et NTLMv2)
Le protocole NTLM se décline en deux versions ayant le même principe de fonctionnement mais une méthode de calcul du hash NET-NTLM différente.
La deuxième version du protocole a été publiée car le hash NET-NTLMv1 était trop facilement réversible pour récupérer le mot de passe originel (moins d’une journée pour un mot de passe de 8 caractères).
Ainsi, NTLMv2 permet de solidifier le hash en complexifiant les possibilités de retrouver un mot de passe, même en possession du hash NT-NTLM.
De plus, NTLMv2 introduit la notion de signature permettant de vérifier l’intégrité du challenge NTLM, ce qui réduit fortement les possibilités de compromission.
NTLMv1
Calcul du hash Net-NTLMv1 :
C = 8-byte server challenge, random
K1 | K2 | K3 = LM/NT-hash | 5-bytes-0
response = DES(K1,C) | DES(K2,C) | DES(K3,C)Exemple de hash :
netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736cNTLMv2
Calcul du hash Net-NTLMv2 :
SC = 8-byte server challenge, random
CC = 8-byte client challenge, random
CC* = (X, time, CC2, domain name)
v2-Hash = HMAC-MD5(NT-Hash, user name, domain name)
LMv2 = HMAC-MD5(v2-Hash, SC, CC)
NTv2 = HMAC-MD5(v2-Hash, SC, CC*)
response = LMv2 | CC | NTv2 | CC*Exemple de hash :
admin::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030Cependant, même si l’opération de recouvrement du mot de passe à partir d’un hash NET-NTLMv2 est plus long, elle reste possible via des outils comme hashcat. En effet, comme tout type de hash, c’est la complexité et la longueur du mot de passe ainsi que la puissance de calcul de la machine utilisée qui seront déterminants.
Dans cet article, nous ne nous attarderons pas sur ce type d’attaque. En effet, il existe d’autres techniques pour abuser de l’authentification NTLM, comme les attaques NTLM relay ou attaques par relais NTLM.
NTLM Relay : types d’attaques, exploitations et bonnes pratiques sécurité
L’attaque la plus connue sur l’authentification NTLM est certainement l’attaque par NTLM relay ou attaque par relais NTLM.
De façon générale, en informatique, une attaque par relais est le fait d’intercepter une information transitant sur un réseau et de la relayer vers une cible, qui n’est d’autre que le destinataire légitime de l’information.
Le protocole NTLM effectue le challenge/réponse en clair car le hash du mot de passe est prévu pour protéger ce secret. Il est alors possible pour un utilisateur malveillant en position Man In The Middle d’intercepter tous les challenges/réponses circulant sur le réseau.
Comme précisé dans la première partie de cet article, la réponse (hash NET-NTLM) au challenge NTLM est une condition suffisante pour authentifier un utilisateur sur le serveur cible.
Ainsi, si un attaquant intercepte une réponse valide et la relaye à la cible, il se retrouve authentifié à la place du client légitime.
Pour ce faire, l’attaquant doit effectuer les étapes suivantes :
- Se mettre en position Man in the Middle.
- Initier une demande de connexion vers le serveur cible en tant que l’utilisateur victime.
- Relayer le challenge à l’utilisateur victime.
- Relayer la réponse de l’utilisateur victime au serveur cible.
- Effectuer les actions qu’il souhaite dans la session ouverte par le serveur.
Maintenant que nous avons vu les différents éléments théoriques de cette attaque, nous allons voir un exemple concret réalisé lors d’un pentest interne afin de mettre en lumière les impacts et exploitations possibles.
Il existe une multitude de techniques pour se positionner en MitM : ARP Poisoning, DNS spoofing, mauvaise configuration de la stack IPv6 de Windows, etc. Ici, nous allons réaliser un empoisonnement de requête NTBS (NetBIOS) et/ou LLMNR.
NTBS et LLMNR Poisoning
Quel est le principe et le fonctionnement de NTBS et LLMNR ?
Ces deux protocoles ont été implémentés par Windows. LLMNR est le successeur de NetBIOS, mais pour des questions de rétrocompatibilité, les deux sont activés par défaut depuis Windows Vista.
Leur but est de suppléer le protocole DNS quand celui-ci échoue à résoudre une adresse. La grande différence c’est que leurs requêtes ne sont pas transmises vers un serveur en particulier (serveur DNS) mais diffusées sur le sous-réseau. Cela permet la découverte automatique mais offre la possibilité à n’importe quelle machine présente sur le sous-réseau de répondre à ces requêtes.
Par conséquent, lorsque vous utilisez le système d’exploitation Windows, la résolution des noms se fait dans l’ordre suivant :
- Requête DNS (envoyée vers le serveur configuré dans les paramètres réseau)
- Requête NTBS/LLMNR (diffusée sur le réseau)
Le processus de résolution de nom se déclenche dès que l’on recherche quelque chose sur le réseau via la barre d’adresse d’un navigateur (l’utilisation de LLMNR/Netbios est activé par défaut sous chrome), en utilisant un raccourci réseau ou via la barre de recherche Windows (avec le préfix \\).
De plus, si vous avez des raccourcis réseau non résolus par un DNS, Windows effectuera une requête LLMNR/Netbios tous les jours (temps du cache DNS par défaut).
Enfin, tous les fichiers « .Scf », « .url », « .lnk » pointant vers une image (png, ico, jpg) accessible sur un partage réseau non résolu par le DNS déclenchera automatiquement une requête LLMNR/Netbios dès que l’utilisateur accédera au dossier présentant ces fichiers. En effet, Windows essaiera de récupérer une miniature de l’image pour vous l’afficher dans l’explorateur de fichier.
Récupération du challenge NTLM via LLMNR Poisoning
Admettons donc qu’un utilisateur recherche le serveur « test ». Le système d’exploitation effectue les requêtes suivantes sur le réseau :
Comme vous pouvez le voir, nous avons la requête DNS puis la requête LLMNR qui est effectuée sur une adresse multicast.
Par conséquent, n’importe quelle machine sur le sous-réseau peut répondre à cette requête et donner son adresse IP pour le nom demandé.
Cette attaque peut être effectuée avec l’outil Responder.
Responder est un outil dont la fonctionnalité principale est de permettre l’empoisonnement des protocoles multicast tels que MDNS, NTBS ou LLMNR. Il permet également d’émuler plusieurs types de services comme SMB, HTTP, LDAP ou RDP.
Une attaque avec Responder peut se schématiser de la façon suivante :
En pratique :
Lancement de Responder sur la machine de l’attaquant :
sudo responder -I eth0De son côté, l’utilisateur saisi « \\test » dans une barre de recherche (menu démarrer, explorer Windows ou Chrome) :
Windows effectue alors une recherche de nom pour chaque nouvelle lettre entrée dans la barre de recherche. Le serveur DNS ne connaissant pas ce domaine, une requête LLMNR est envoyée et diffusée sur le réseau.
Notre programme Responder répond à cette requête par une demande d’authentification pour le nom de domaine « te ».
Cela permet d’initier un challenge NTLM avec la victime afin de récupérer son hash NTLMv2-SSP.
Une fois l’opération terminée, le programme Responder affiche le hash dans la console :
Nous venons d’effectuer une attaque d’empoisonnement LLMNR qui nous a permis de récupérer la réponse au challenge NTLM (hash NTLMV2-SSp ou Net-NTLmV2).
Cette réponse contient le hash NTLM de l’utilisateur légitime. Hash qu’il est possible de casser pour retrouver le mot de passe de l’utilisateur.
Toutefois, Dans une attaque NTLM relay, ce qui nous intéresse n’est pas de récupérer un mot de passe, mais la session active de notre victime.
En effet, l’attaque présentée permet de récupérer la réponse au challenge proposé par la machine de l’attaquant. Pour abuser d’une session, il nous faut récupérer un challenge validé par un serveur cible.
Nous devons donc modifier notre attaque.
Dans ce cas, le programme Responder (toujours déployé sur notre machine) sera utilisé seulement comme outil d’empoisonnement LLMNR et toutes les requêtes de connexion entrantes seront relayées vers un service cible (service compatible NTLM).
Un protocole bien connu comme cible de ce type d’attaque est le protocole SMB (samba). SMB est un protocole d’échange de fichiers qui supporte nativement l’authentification NTLM et qui, par défaut (sur SMBv1 et SMBv2) n’implémente pas la signature, une protection contre les attaques par relais.
NTLM relay sur les services SMB
Pour attaquer les services SMB du réseau, nous modifions le fichier de configuration du programme Responder afin qu’il ne démarre pas son serveur SMB.
nano /etc/responder/Responder.confLa modification s’effectue de la façon suivante :
Responder étant prêt, nous devons identifier les services SMB vulnérables aux attaques par relais.
Identification des services SMB vulnérables
Pour ce faire, nous allons utiliser l’utilitaire « crackmapexec » qui permet d’interagir facilement avec le service SMB de n’importe quelle machine.
Récupération de la liste des cibles vulnérables au SMB relay (l’argument –gen-relay-list permet de cibler les services SMB n’implémentant pas la signature) :
crackmapexec smb —gen-relay-list smb_targets.txt 192.168.1.0/24Une fois cette liste récupérée, nous allons utiliser l’outil « ntlmrelayx » afin qu’il relaye les challenges/réponses entre les services SMB vulnérables et les clients victimes.
De cette manière, Responder va empoissonner les requêtes LLMNR/NETBIOS émises par un client victime.
Puis, au lieu de générer un challenge, ntlmrelayx va initier une authentification avec le ou les services cibles (IP dans la liste « smb_target.txt »). Le challenge émis est relayé à la victime, puis la réponse au serveur.
Lancement de Ntlmrelayx contre les services cibles (smb_targets.txt) :
ntlmrelayx.py -socks -smb2support -tf smb_targets.txtLe paramètre « socks » permet d’indiquer à l’outil de stocker les sessions récupérées dans un service proxy socks sur la machine de l’attaquant.
Cela permettra à l’attaquant de réutiliser ces sessions avec d’autres outils à l’aide de l’utilitaire proxychains.
Par défaut, Ntlmrelayx ouvre un service socks sur le port 1080 de l’interface « localhost ». Ainsi, nous devons modifier la configuration de proxychains afin qu’il interagisse avec ce port.
sudo nano /etc/proxychains4.confPour ce faire, nous appliquons la configuration suivante :
Avec cette configuration, l’ensemble de nos outils sont maintenant prêts. Nous pouvons exécuter notre attaque :
Comme pour l’attaque précédente, suite à la maladresse d’un utilisateur (recherche d’un emplacement réseau non existant ou d’une recherche chrome), d’un lien réseau qui n’est plus résolu part le DNS interne ou si l’audit le permet un lien envoyé suite à une campagne de phishing ; Une requête LLMNR ou NBT-NS est envoyée sur le réseau. Notre outil Responder va procéder à son empoisonnement.
Maintenant que la victime communique avec nous et pense s’authentifier à un serveur, ntlmrelayx prend le relai et envoie une demande d’authentification en la personne de l’utilisateur piégé (utilisateur de la machine 192.168.1.162).
Le challenge proposé par le serveur est relayé à la victime et sa réponse au serveur. Si la réponse est validée par le serveur cible, la session ouverte est stockée dans le service socks ouvert par Ntlmrelayx.
Après le succès de l’attaque, le service socks contient les sessions suivantes :
Maintenant que nous somme en possessions de ces sessions, nous pouvons les utiliser pour interagir avec les services SMB des machines 192.168.1.161 et 192.168.1.205.
Exploitation
Dans un objectif pédagogique, nous développerons notre raisonnement sur le fondement de l’exemple présenté ci-dessus.
Autrement dit, nous nous plaçons dans l’hypothèse où l’attaquant parvient à se procurer les accès décrits par la capture d’écran, c’est-à-dire l’obtention de deux sessions valides de l’utilisateur TEST/TESTADMIN.
Dans notre exemple, cet utilisateur est un administrateur de domaine mais aucune des deux machines n’est l’Active Directory. A partir de cette situation initiale, nous allons dérouler l’ensemble des actions réalisables par un attaquant et voir comment nous pouvons compromettre l’ensemble du domaine à partir de cette session éphémère.
Dans un premier temps, quel que soit le niveau de privilèges, on profitera des accès obtenus pour inspecter le contenu des partages de fichiers. Cette inspection est à ce stade la seule action réalisable puisque la session obtenue sur le serveur 192.168.1.205 ne possède pas les privilèges administrateur.
Dans le cas où l’une des sessions obtenues possède les privilèges administrateur, il nous sera possible de compromettre la machine cible. En effet, l’accès à un service SMB permet bien plus de possibilités que le simple transfert de fichiers. Ce protocole peut également servir pour l’exécution de commande sur la machine distante. Pour se faire, nous pouvons utiliser SMBexec ou PSexec.
SMBexec fonctionne de la manière suivante :
- Création d’un service Windows (nommée BTOBTO). SMB peux utiliser les « named pipe », ce qui lui permet d’interagir avec l’API RPC de Windows (MSRPC). SMBExec profite de cette fonctionnalité pour communiquer avec le serveur RPC « Service Control Manager » (via le named pipe « \PIPE\svcctl ») afin de créer, démarrer et stopper un service.
- Le nom de ce service contient la commande à exécuter pour référence « cmd.exe » à l’aide de variable d’environnement (%COMSPEC%) qui contient la commande à exécuter et redirige la sortie de la commande vers un fichier temporaire.
- Exécution de ce service ce qui exécute le fichier C:\windows\temp\execute.bat.
- Récupère le fichier de sortie C:\__output
- Supprime le ficher C:\__output
- Affiche le contenu dans la console de l’attaquant.
Il faut donc à minima un accès en écriture sur un des disques du partage SMB (par défaut il faut un accès en écriture sur C$). De plus, Il est important de noter que SMBexec est moins sujet à la détection par les antivirus ou EDR que PSexec car il ne transfère et n’exécute pas de programme binaire sur la machine distante, seulement un service ainsi qu’un fichier texte sont créés.
Exécution de SMBexec (avec la session stockée dans le socks proxy via « proxychains ») :
Maintenant que nous avons une exécution de commande en tant qu’administrateur sur la machine (le compte relayé ayant les droits local d’administration). Il est possible de créer un nouveau compte administrateur local sur la machine victime. Cela nous permettra de nous connecter de façon pérenne et de ne plus compter sur notre session éphémère. (A noter qu’il n’est pas possible de créer de compte directement lié au domaine car cette action ne peut être réalisé que sur l’Active Directory).
Par cette action, nous sommes passé d’un hash NET-NTLM (potentiellement non brute forçable) à un compte administrateur local.
Une fois cet utilisateur créé, nous pouvons extraire la mémoire du processus LSASS (processus qui contient tous les hash NT des utilisateurs connectés) sur la machine.
NB : il est tout as fait possible de ne pas créer cet utilisateur et d’utiliser directement secretdump avec proxychains. Toutefois, la création de cet utilisateur, permet une connexion légitime à la machine concernée.
Par conséquent, il sera possible de se connecter avec le compte créé et désactiver l’antivirus. Cela facilitera la récupération des hashs (via mimikatz, secretdump ou crackmapexec).
Avec crackmapexec cela donne les commandes suivantes :
Avec le compte admin local :
#~ cme smb 192.168.1.161 -u testvaadata -p te5tV00daat7Admin -M lsassy --local-authAvec le compte TEST/TESTADMIN (se fait plus facilement détecter par l’Anti-Virus) :
#~ proxychains4 cme smb 192.168.1.161 -u TESTADMIN -d test -M lsassy Le hash ainsi récupéré nous permet par la suite de nous authentifier sur l’Active Directory via la méthode « Pass The Hash » implémentée par plusieurs outils dont crackmapexec.
En effet, comme nous l’avons vu, le condensat NT est la seule condition pour valider un challenge NTLM. Nous pouvons donc valider les challenges de tous les serveurs dont l’utilisateur à accès. Nous pouvons même dire qu’avoir le hashNT d’un utilisateur équivaut à avoir son mot de passe en clair.
Les limites de l’attaque
Une des difficultés de l’attaque NTLM relay est le fait de se mettre en position « Man In The Middle ».
En effet, lors d’un pentest réseau, il est probable que l’exemple présenté ci-dessus échoue car les protocoles de découverte automatique du réseau sont désactivés.
Toutefois, comme mentionné précédemment d’autres méthodes peuvent permettre à un attaquant de se mettre en position MiTM.
- La détection automatique de proxy (WAPD) est activée sur les machines utilisateurs peut aussi être empoisonné par Responder.
- Si l’IPv6 n’est pas désactivé des machines utilisateurs, il est possible d’abuser des requêtes (DHCPv6) pour configurer un DNS corrompu (notre machine) comme serveur de résolution des noms solution de noms d’IPv6 pour se mettre en MiTM.
- L’ARP Spoofing est aussi un moyen simple de se mettre en MiTM. La seule limitation est le fait que l’attaquant n’empoisonnera que les machines dans son sous réseau (limitation du protocole ARP).
Globalement, toutes les méthodes de spoofing classique pouvant mettre un attaquant en MitM peuvent être utilisée pour commencer une attaque par relais.
Si malgré toutes ces techniques, l’attaquant ne parvient pas à se placer en « Man In The Middle », il n’en demeure pas moins que l’attaquant peut forcer la réauthentification sur une machine cible. Dans ce cas, on parle de « coerced attacks ».
Parmi elles, on retrouve notamment l’exploitation de la vulnérabilité PrintNighmare mise en évidence en 2021. Cette vulnérabilité permet à n’importe quel utilisateur du domaine d’interagir via SMB au travers du « named pipe » « \pipe\spoolss » avec le service RPC MS-RPRN. En procédant de cette façon, l’attaquant peut réauthentifier le service sur la machine de son choix et effectuer un relais.
Malgré les efforts fournis par Microsoft pour limiter l’exploitation de PrintNightmare, les « coerced attacks » se sont développées sur d’autres services tels que MS-FSRVP, MS-DFSNM et MS-EFSR. Devant l’utilisation persistante de cette technique, Microsoft a estimé que le problème ne venait pas de ces services mais de l’absence de mise en place de protection contre le relais.
Nous reviendrons dans le détail de ces attaques dans un autre article. Cependant, il nous semblait important de les mentionner pour montrer que le relais est possible via diverses techniques.
Comment prévenir les attaques NTLM relay ?
Pour prévenir les attaques NTLM relay, il est possible de contrer chacune des méthodes permettant d’obtenir un hash NET-NTLM à savoir :
- Désactiver le(s) protocoles LLMNR/NETBIOS,
- Désactiver tous les services Microsoft vulnérables aux « coerced attacks »,
- Paramétrer une table ARP statique, etc.
Cependant, nous vous déconseillons l’implémentation de ces méthodes à cause de leur difficulté de mis en œuvre.
La méthode la plus efficace pour contrer le relais est de mettre en place ces actions sur les serveurs.
- Désactiver l’authentification NTLM sur votre réseau et la déléguer uniquement à Kerberos si possible
- Activer la signature sur SMB et LDAP.
- Le protocole HTTPS ne supporte pas la signature. Par conséquent, vous pouvez désactiver le protocole NTLM pour les services HTTPS spécifiquement, ou vous pouvez utiliser la protection EPA (Extended Protection Authentication). En somme, cette protection ajoute la signature aux protocoles qui ne l’implémente pas.
Le tableau ci-dessous résume l’exploitabilité de l’attaque NTLM relay en fonction des protocoles et des protection activés (source : www.thehacker.recipe).
Sources :
SMB exec
Smb rpc service: https://blog.openthreatresearch.com/ntobjectmanager_rpc_smb_scm
SMEXEC explication : https://u0041.co/blog/post/2
Code : https://github.com/fortra/impacket/blob/master/examples/smbexec.py
Authentification NTLM :
https://beta.hackndo.com/ntlm-relay/
https://learn.microsoft.com/en-us/windows/win32/secauthn/microsoft-ntlm
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/5e550938-91d4-459f-b67d-75d70009e3f3
Named pipe : https://learn.microsoft.com/en-us/windows/win32/ipc/named-pipes
Les contres mesures et coerced attack : https://www.thehacker.recipes/ad/movement/ntlm/relay
Auteur : Eliot RABAUD – Pentester @Vaadata