LLMNR : empoisonnement et abus réseau

LLMNR (Link-Local Multicast Name Resolution) est un protocole réseau Microsoft introduit avec Windows Vista. Il permet à une machine de résoudre un nom d'hôte via multicast IPv4/IPv6 (adresse 224.0.0.252, port UDP 5355) lorsque le DNS classique échoue. L'empoisonnement et les abus réseau liés à LLMNR exploitent une faiblesse fondamentale : n'importe quelle machine sur le segment local peut répondre à une requête LLMNR, sans authentification préalable. Un attaquant positionné sur le réseau répond à ces requêtes en se faisant passer pour la ressource cherchée. La victime envoie alors ses identifiants sous forme de hachage NTLMv1 ou NTLMv2 pour s'authentifier auprès de l'attaquant. Ce mécanisme ne nécessite aucun accès préalable au réseau cible. Il suffit d'être sur le même segment broadcast. LLMNR fonctionne conjointement avec NBT-NS (NetBIOS Name Service, port UDP 137), qui présente la même vulnérabilité. Ces deux protocoles constituent un vecteur d'attaque de premier plan dans les audits Active Directory. Leur présence est quasi systématique dans les environnements Windows non durcis.

La détection d'un empoisonnement LLMNR repose sur plusieurs sources de logs et d'alertes réseau. Côté capture réseau, une sonde IDS/IPS ou un outil comme Zeek peut détecter des réponses LLMNR anormales : une même adresse IP répondant à de nombreuses requêtes LLMNR multicast vers des hôtes variés est un indicateur fort d'un outil comme Responder actif sur le réseau. Les requêtes LLMNR génèrent du trafic UDP vers 224.0.0.252 sur le port 5355. Un volume inhabituel de trafic vers cette adresse multicast doit alerter le SOC. Côté Windows, les événements ID 4648 (tentative d'ouverture de session avec credentials explicites) et ID 4625 (échec d'authentification) dans le journal Security peuvent signaler des tentatives d'authentification vers une machine inconnue. L'activation de l'audit des connexions réseau et l'usage d'un SIEM permettent de corréler ces événements avec des pics de requêtes LLMNR. Des honeypots internes répondant à des noms fictifs (ex. : partage inexistant) peuvent aussi servir de canaris : toute tentative d'authentification vers ces leurres indique une activité d'empoisonnement en cours. Microsoft Defender for Endpoint génère des alertes spécifiques sur la présence de Responder détecté via ses signatures comportementales.

Côté Red Team, l'outil de référence est Responder (lgandx), qui écoute passivement les requêtes LLMNR et NBT-NS sur le réseau local. Dès qu'une machine envoie une requête non résolue par DNS, Responder répond et capture le hachage NTLMv2 de la victime. Ces hachages peuvent être soumis à un craquage offline via Hashcat (mode -m 5600 pour NTLMv2) ou utilisés dans une attaque NTLM Relay avec ntlmrelayx (impacket), pour s'authentifier directement sur d'autres services réseau sans casser le mot de passe. Le NTLM Relay est particulièrement redoutable contre SMB si la signature SMB n'est pas imposée, ou contre LDAP pour créer des comptes ou modifier des ACL dans l'Active Directory. Côté durcissement, la contre-mesure principale est la désactivation de LLMNR via GPO (Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution) et la désactivation de NBT-NS dans les propriétés TCP/IP de chaque interface. La signature SMB obligatoire (RequireSecuritySignature) bloque les attaques NTLM Relay sur SMB. Enfin, segmenter le réseau pour limiter les domaines broadcast réduit mécaniquement la surface d'exposition à ces attaques.