LLMNR Poisoning

Qu'est-ce que le LLMNR Poisoning ?

Le LLMNR Poisoning (empoisonnement LLMNR) est une attaque de type man-in-the-middle qui exploite le protocole Link-Local Multicast Name Resolution, un mécanisme de résolution de noms utilisé par Windows en dernier recours lorsque le DNS échoue. L'attaquant, positionné sur le même segment réseau que ses victimes, répond aux requêtes de résolution diffusées en multicast en se faisant passer pour la machine recherchée. La victime lui adresse alors spontanément une authentification NTLM, livrant un condensat NetNTLMv2 exploitable hors ligne ou relayable en temps réel.

Cette technique reste, plus de quinze ans après sa découverte, l'un des vecteurs d'entrée les plus rentables des tests d'intrusion internes en environnement Active Directory. Elle ne nécessite ni vulnérabilité logicielle, ni exploit : elle abuse simplement d'un comportement par défaut de Windows.

Fonctionnement technique

Lorsqu'un poste Windows doit résoudre un nom d'hôte, il suit une cascade précise :

• consultation du cache local et du fichier hosts ;
• requête DNS unicast vers les serveurs configurés ;
• en cas d'échec, diffusion d'une requête LLMNR (UDP/5355, multicast 224.0.0.252 en IPv4 et FF02::1:3 en IPv6) ;
• puis, si nécessaire, une requête NBT-NS (NetBIOS Name Service, UDP/137) en broadcast ;
• éventuellement mDNS (UDP/5353) sur les systèmes récents.

Ces trois derniers protocoles n'intègrent aucune authentification de la réponse : le premier hôte du segment qui répond est considéré comme légitime. L'attaquant écoute donc le trafic multicast et répond systématiquement « oui, c'est moi » à chaque requête, en indiquant sa propre adresse IP.

La victime ouvre alors une session SMB vers l'attaquant. Windows, par commodité, tente une authentification NTLM automatique avec les identifiants de l'utilisateur connecté. Le protocole étant de type challenge-response, l'attaquant émet un challenge de 8 octets et récupère la réponse : un condensat NetNTLMv2 contenant le nom d'utilisateur, le domaine et le HMAC-MD5 dérivé du mot de passe.

Exemples concrets

L'outil de référence est Responder (Laurent Gaffié), lancé en une commande :

• responder -I eth0 -wd — active les serveurs SMB/HTTP/LDAP factices et l'empoisonnement LLMNR, NBT-NS et mDNS.

Les déclencheurs les plus fréquents dans la vraie vie sont d'une banalité désarmante :

• une faute de frappe dans un chemin réseau : \\srvfichier tapé \\srvfichiers ;
• un lecteur réseau mappé pointant vers un serveur décommissionné mais toujours présent dans une GPO ;
• une imprimante ou un partage référencé dans un vieux script de logon ;
• le WPAD (Web Proxy Auto-Discovery), qui interroge l'hôte wpad à chaque démarrage de navigateur — un cas particulier redoutablement efficace.

Le condensat obtenu est ensuite cassé hors ligne avec hashcat en mode -m 5600 ou john --format=netntlmv2. Sur des mots de passe utilisateurs classiques (Societe2026!, Printemps25*), le taux de réussite dépasse couramment 30 à 50 % en quelques heures.

De l'empoisonnement au relais NTLM

Lorsque le mot de passe résiste au cassage, l'attaquant bascule sur le NTLM Relay : au lieu de conserver le condensat, il le rejoue immédiatement vers une cible tierce (serveur de fichiers, LDAP, ADCS) avec ntlmrelayx.py de la suite Impacket. Si la signature SMB n'est pas exigée sur la cible, l'authentification aboutit et l'attaquant hérite des droits de la victime. Combiné à une attaque ESC8 (AD CS), ce relais permet d'obtenir un certificat d'authentification de machine et, de proche en proche, une compromission complète du domaine.

Concepts liés

• Pass-the-Hash : exploite le hash NTLM stocké, alors que le NetNTLMv2 issu du poisoning n'est pas réutilisable tel quel.
• Kerberoasting et AS-REP Roasting : autres techniques de récupération de condensats en environnement Active Directory.
• ARP Spoofing et DHCPv6 Spoofing (mitm6) : approches voisines d'usurpation de couche réseau, souvent chaînées avec Responder.
• Mouvement latéral et élévation de privilèges : phases suivantes du scénario d'attaque.

Bonnes pratiques de protection

• Désactiver LLMNR par GPO : Configuration ordinateur → Modèles d'administration → Réseau → Client DNS → Désactiver la résolution de noms multicast (clé EnableMulticast=0).
• Désactiver NBT-NS sur toutes les interfaces, idéalement via l'option DHCP 001 du fournisseur Microsoft (valeur 0x2) pour couvrir le parc automatiquement.
• Neutraliser WPAD en créant une entrée DNS statique wpad pointant vers une adresse inexploitable, et en désactivant le service WinHTTP Web Proxy Auto-Discovery.
• Imposer la signature SMB (Require SMB signing) et le channel binding LDAP pour bloquer le relais.
• Renforcer la politique de mots de passe : passphrases de 14 caractères minimum, filtrage des mots de passe compromis.
• Superviser le trafic UDP/5355 et UDP/137 : un hôte répondant massivement à ces requêtes est un signal d'alerte fiable dans un SIEM.
• Déployer des comptes leurres (honeytokens) déclenchant une alerte à la moindre tentative d'authentification.

La désactivation de LLMNR et NBT-NS reste, dans la grande majorité des réseaux d'entreprise modernes, sans impact fonctionnel : un DNS interne correctement configuré couvre tous les besoins de résolution légitimes.