Capturer du NetNTLMv2 avec Responder et le casser hors ligne

Le chemin le plus rapide vers un environnement Active Directory, c'est souvent de laisser le réseau vous tendre un hash. Vous ne piégez personne, vous n'exploitez aucune CVE. Vous vous posez sur le fil, vous répondez à une requête de résolution de nom que personne ne devrait émettre, et un utilisateur du domaine s'authentifie auprès de vous.

Cette authentification est une réponse NetNTLMv2, et la capturer est le pain quotidien du pentest interne.

Pourquoi le hash vous tombe dans les mains

Windows résout les noms dans un ordre précis. DNS d'abord. Quand le DNS échoue, l'hôte se rabat sur des protocoles de diffusion : LLMNR (UDP 5355), NBT-NS (UDP 137), et sur les piles récentes le mDNS. Ces protocoles font confiance au premier qui répond. Aucune authentification sur la réponse.

Donc quand un utilisateur tape un chemin de partage de travers, se trompe de nom d'hôte, ou qu'un service va chercher wpad à l'aveugle, la requête rate le DNS et part en diffusion dans tout le domaine de broadcast. Responder y répond. Il prétend être l'hôte que la victime cherchait, la victime tente de s'authentifier en SMB ou HTTP, et Responder ramasse l'échange NetNTLMv2.

responder -I eth0 -wv

-I choisit l'interface. -w lance le proxy WPAD pirate, -v est verbeux pour voir les captures défiler. Par défaut il empoisonne LLMNR, NBT-NS et MDNS et monte des écouteurs SMB et HTTP pour récolter la réponse. Laissez-le tourner sur une mission tranquille et les captures s'accumulent toutes seules.

mitm6 est le cousin IPv6. La plupart des réseaux sont en double pile mais n'ont jamais configuré DHCPv6, alors mitm6 devient le serveur DNS IPv6 pirate, et vous empoisonnez de vraies résolutions DNS au lieu d'attendre un repli. Couplez-le à ntlmrelayx et la capture se transforme en relais.

Ce qu'est réellement un NetNTLMv2

La ligne que Responder dépose ressemble à ceci :

jdoe::CONTOSO:1122334455667788:6E0C...A1:0101000000000000...

C'est le format NetNTLMv2, et sa structure compte :

user::DOMAINE:defiserveur:HMAC:blob

Le defiserveur est l'aléa de 8 octets que le serveur (vous, l'écouteur pirate) a envoyé. Le HMAC est un HMAC-MD5 clé sur le hash NT du mot de passe de l'utilisateur, calculé sur le défi et le blob. Le blob transporte le défi client, un horodatage et des informations de cible.

Le mot de passe en clair ne traverse jamais le fil. Ce que vous avez, c'est une réponse qui prouve que l'utilisateur connaît le mot de passe, liée à un défi que vous avez choisi. Cette liaison est tout l'enjeu, et c'est pour ça que ce n'est pas un identifiant réutilisable.

Le NetNTLMv2 ne sert pas au pass-the-hash

Ça coince tout le temps. Vous avez capturé un hash, donc vous voulez le passer. Vous ne pouvez pas.

Le pass-the-hash rejoue le hash NT statique, les 16 octets stockés dans la SAM ou le NTDS. Le NetNTLMv2 n'est pas ça. C'est une sortie HMAC calculée en direct contre un défi à usage unique. Le rejouer ne donne rien : l'authentification suivante utilise un autre défi serveur, et votre vieux HMAC ne validera pas.

Vous avez exactement deux coups. Le casser pour retrouver le mot de passe, ou le relayer avant que la session ne meure.

Le casser

Mettez la ligne complète dans un fichier et pointez hashcat sur le mode 5600 :

hashcat -m 5600 capture.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Le NetNTLMv2 est du HMAC-MD5, donc rapide. Un seul GPU moderne le mâche à des milliards par seconde, donc ça se comporte comme casser du NTLM directement : un dictionnaire plus un jeu de règles liquide les mots de passe faibles en quelques minutes. John fait le même travail :

john --format=netntlmv2 --wordlist=rockyou.txt capture.txt

Le piège est toujours le même. Hash rapide, mot de passe faible, vous gagnez vite. Hash rapide, quatorze caractères aléatoires, vous ne gagnez jamais. Le cassage retrouve le clair, ce qui vaut plus qu'un relais parce que vous pouvez réutiliser un mot de passe sur tout le domaine. Un relais ne vous donne qu'une session sur une seule machine.

Quand relayer plutôt

Si le mot de passe est assez solide pour que le cassage soit perdu d'avance, vous n'en avez pas besoin. Relayez l'authentification directement vers un autre hôte tant que la session est vivante.

ntlmrelayx.py -tf targets.txt -smb2support

La condition dure : la signature SMB ne doit pas être imposée sur la cible. La signature lie la session authentifiée au canal, donc une réponse relayée échoue au contrôle d'intégrité. Les contrôleurs de domaine imposent la signature par défaut. Les serveurs membres et les postes de travail, très souvent non, et ce sont vos cibles de relais. Relayez vers SMB pour l'exécution de commandes ou vers LDAP pour des tours comme le RBCD, et vous obtenez l'accès sans jamais connaître le mot de passe.

Un relais contourne aussi entièrement le problème du mot de passe fort. L'utilisateur pourrait avoir une phrase de passe de soixante caractères que ça vous serait égal, puisque vous ne la cassez jamais. Vous empruntez simplement l'authentification.

Le point de vue du défenseur

Tuez d'abord la surface d'empoisonnement. Désactivez LLMNR et NBT-NS via la stratégie de groupe et l'étendue DHCP respectivement, car presque rien de légitime n'en a besoin une fois le DNS sain. Cela seul retire l'essentiel de la prise de Responder. Désactivez le mDNS quand c'est possible, et si vous n'utilisez pas IPv6, coupez-le ou fixez DHCPv6 pour que mitm6 n'ait rien à détourner.

Imposez ensuite la signature SMB partout, pas seulement sur les DC. La signature requise transforme une capture réussie en cul-de-sac, car l'attaquant peut capturer toute la journée sans jamais relayer. Combinez-la au channel binding (EPA) sur les points d'accès HTTP et LDAP pour fermer les chemins de relais qui ne passent pas par SMB.

Et le correctif structurel qui survit à tout : des mots de passe assez longs pour que la capture, même quand elle arrive, ne casse jamais. Si la signature est active et le mot de passe solide, l'attaquant se retrouve avec un hash bon à rien. C'est l'état où vous voulez chaque poste de travail.