La plupart des équipes réseau ont coché la case : "IPv6 désactivé". Sauf que désactiver IPv6 dans Windows, ce n'est pas ce que fait l'interface graphique par défaut. Ce qu'elle fait, c'est décocher l'adaptateur IPv6 dans les propriétés de la carte réseau, ce qui n'empêche ni les annonces DHCPv6, ni la résolution mDNS, ni les adresses link-local. Le protocole reste actif dans la pile réseau. Et ça change tout.
Comprendre l'exploitation DHCPv6 dans un réseau Windows
Dans tout réseau Windows où IPv6 n'est pas activement bloqué au niveau du commutateur ou du pare-feu, les machines écoutent en permanence les annonces DHCPv6 sur le groupe multicast ff02::1:2. Aucune configuration préalable n'est nécessaire côté victime : c'est le comportement par défaut de Windows depuis Vista.
Un attaquant positionné sur le même segment réseau peut démarrer un serveur DHCPv6 malveillant, comme celui intégré à l'outil mitm6. Ce serveur répond aux sollicitations DHCPv6 des clients en leur attribuant une adresse IPv6 link-local et, surtout, en se désignant lui-même comme serveur DNS prioritaire pour IPv6. La machine victime met alors à jour sa table de résolution DNS : les futures requêtes DNS peuvent être acheminées vers l'attaquant.
Ce mécanisme n'est pas un bug de Windows. C'est RFC-conforme. La préférence accordée à IPv6 sur IPv4 dans la pile Windows fait le reste : dès qu'une réponse IPv6 est disponible, elle prend le dessus sur la réponse IPv4.
De la résolution DNS corrompue au relais NTLM
Une fois que l'attaquant contrôle la résolution DNS des clients, il peut répondre à n'importe quelle requête de nom, y compris celles vers des ressources internes légitimes comme des partages SYSVOL, des serveurs d'authentification web ou des hôtes sur l'intranet. La machine victime tente de s'authentifier auprès de la fausse destination en utilisant NTLM, le protocole d'authentification Windows par défi-réponse.
À ce stade, deux chemins s'ouvrent. Le premier : capturer le hash NTLMv2 transmis lors de la tentative d'authentification, puis le soumettre à une attaque par dictionnaire hors ligne. Le second, plus puissant : relayer immédiatement ce hash vers une cible réelle du réseau, comme LDAP ou SMB sur un contrôleur de domaine. Si la victime dispose de droits suffisants, l'attaquant peut créer un compte machine, modifier des ACL LDAP ou accéder à des partages sensibles, le tout sans jamais casser le mot de passe.
L'outil ntlmrelayx de la suite Impacket automatise cette chaîne. Dans un scénario type, mitm6 gère le DHCPv6 et la fausse résolution DNS, tandis que ntlmrelayx reçoit les authentifications et les relaie vers LDAP sur le DC. Si LDAP signing n'est pas enforced, l'opération peut aboutir à une délégation de droits ou à la création d'un objet persistant dans l'Active Directory.
Pourquoi "désactiver" IPv6 sans le neutraliser vraiment ne protège pas
Voici où beaucoup d'organisations se trompent. Décocher IPv6 dans les propriétés de la carte réseau ne supprime pas la pile IPv6 de Windows. Les adresses link-local (préfixe fe80::) restent assignées automatiquement à chaque interface. Le service mDNS continue d'opérer. Les annonces de routeur (Router Advertisements) sont toujours écoutées.
Pour neutraliser réellement IPv6 sur un poste Windows, il faut agir via la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents avec la valeur 0xFF, ou passer par une GPO qui désactive la liaison IPv6 sur toutes les interfaces. Même dans ce cas, si les commutateurs réseau n'ont pas de filtres RA Guard ou DHCPv6 snooping configurés, un attaquant sur le segment peut quand même envoyer des annonces qui seront traitées par des machines moins bien configurées.
Sur des parcs hétérogènes comme on en rencontre fréquemment dans les entreprises marocaines ou ouest-africaines, où coexistent des postes sous Windows 10, des serveurs 2012 non migrés et des équipements réseau anciens sans support VLAN avancé, la surface d'attaque est particulièrement large. La désactivation partielle d'IPv6 donne une fausse impression de sécurité sans réduire réellement le risque.
Mesures de protection réellement efficaces
La défense passe par plusieurs couches complémentaires. Au niveau réseau, activer le DHCPv6 snooping et le RA Guard sur les commutateurs managés est la première barrière. Ces fonctions bloquent les annonces DHCPv6 et les Router Advertisements provenant de ports non autorisés, empêchant l'émergence d'un serveur DHCPv6 pirate.
Renforcer l'authentification NTLM côté Active Directory
Sur les contrôleurs de domaine, activer le LDAP signing et le LDAP channel binding est non négociable. Ces paramètres, désactivés par défaut avant Windows Server 2019, empêchent le relais vers LDAP même si l'attaquant a capturé un hash valide. L'activation se fait en GPO via Domain Controller: LDAP server signing requirements.
Surveiller les événements réseau liés à IPv6
Les solutions SIEM doivent intégrer des règles de détection pour les pics soudains de trafic DHCPv6, les adresses link-local inconnues apparaissant sur des segments normalement IPv4-only, et les authentifications NTLM vers des destinations inhabituelles. Ce type de visibilité est précisément ce que permettent les cas d'usage SOC entraînés sur des environnements Active Directory réalistes, où le trafic IPv6 malveillant est simulé pour apprendre à le reconnaître.
Activer SMB signing sur tous les postes et serveurs du domaine réduit également l'attractivité du relais SMB. Ce n'est pas une mesure spécifique à IPv6, mais elle supprime l'un des débouchés les plus dangereux de la chaîne d'attaque.
Ce que révèle cette attaque sur la posture de sécurité globale
L'attaque DHCPv6 / relais NTLM est symptomatique d'un problème plus profond : la tendance à traiter les protocoles non utilisés comme des protocoles inexistants. IPv6 est actif. mDNS est actif. LLMNR est actif. Dans la majorité des environnements Windows non durcis, ces trois protocoles peuvent être détournés pour capturer des hashs d'authentification sans aucune interaction de l'utilisateur autre qu'une connexion réseau ordinaire.
Évaluer son exposition réelle à ce type d'attaque suppose d'aller au-delà d'un audit de configuration statique. Un diagnostic de maturité cyber qui simule ces vecteurs en conditions réelles donne une image bien plus fidèle de ce qu'un attaquant interne ou un prestataire compromis pourrait faire en quelques minutes sur un réseau d'entreprise.
Questions fréquentes
Est-ce qu'une machine Windows écoute DHCPv6 même si IPv6 semble désactivé ?
Oui. Décocher IPv6 dans les propriétés de la carte réseau ne désactive pas la pile IPv6 dans le noyau Windows. Les adresses link-local restent assignées et les annonces DHCPv6 sont toujours traitées. La désactivation complète nécessite une modification du registre ou une GPO dédiée.
Faut-il obligatoirement casser le hash NTLM pour que cette attaque réussisse ?
Non, c'est précisément ce qui la rend dangereuse. Le relais NTLM permet d'utiliser le hash capturé directement contre une autre cible du réseau, sans jamais le déchiffrer. Si LDAP signing n'est pas activé sur le contrôleur de domaine, l'attaquant peut agir dans l'Active Directory avec les droits de la victime.
DHCPv6 snooping est-il suffisant comme protection ?
C'est une mesure nécessaire mais pas suffisante seule. Il faut la combiner avec LDAP signing, SMB signing, et idéalement la désactivation de LLMNR et NetBIOS over TCP/IP. La défense en profondeur réduit chaque étape de la chaîne d'attaque.
Cette attaque est-elle détectable par un SIEM classique ?
Elle peut l'être, mais cela suppose des règles de corrélation spécifiques : trafic DHCPv6 sur des segments IPv4-only, apparition d'adresses fe80:: inconnues, et authentifications NTLM vers des destinations non répertoriées. Sans ces règles, l'attaque passe inaperçue dans les logs standards.