mitm6 : quand IPv6 laissé actif ouvre la porte de l’Active Directory

Lors des audits internes, le même constat revient régulièrement : un réseau où tout semble propre côté IPv4, pare-feu en place, VLAN cloisonnés, correctifs appliqués. Et pourtant, un seul poste de travail peut suffire à basculer le domaine entier en moins d’une heure. Parmi les portes d’entrée les plus discrètes dans ce cas, l’une tient à un protocole que presque personne ne surveille : IPv6, activé par défaut sur Windows et laissé sans configuration. Cet article détaille l’attaque mitm6 étape par étape, avec le contexte qui explique pourquoi elle reste aussi efficace des années après sa publication.

IPv6 : le protocole que personne ne configure

Depuis Windows Vista, IPv6 est actif par défaut sur tous les postes et tous les serveurs. Mieux (ou pire, selon le point de vue) : la pile réseau de Windows préfère IPv6 à IPv4. Cette préférence n’a rien d’arbitraire, elle découle de la RFC 6724 qui définit l’ordre de sélection des adresses. Concrètement, quand une machine démarre ou renouvelle sa configuration, elle diffuse des sollicitations pour découvrir un routeur et un serveur d’adressage : des messages Router Solicitation et des requêtes DHCPv6. Dans la quasi-totalité des réseaux d’entreprise, personne ne répond, car aucun service IPv6 n’a jamais été déployé. Le poste reste donc en attente, sans passerelle ni serveur DNS IPv6, jusqu’au jour où un attaquant décide très volontiers de lui en fournir.

Pour rappel, un serveur DNS traduit les noms lisibles (comme fichiers.entreprise.local) en adresses réseau. Celui qui contrôle le DNS d’une machine contrôle en grande partie ce qu’elle contacte, et peut donc l’aiguiller vers des serveurs de son choix.

Cette situation, un protocole allumé mais jamais administré, crée exactement le vide qu’un intrus vient combler. La recherche à l’origine de l’attaque, publiée par le chercheur Dirk-jan Mollema, a montré qu’il suffisait de répondre poliment à ces sollicitations pour insérer une machine pirate au cœur des échanges.

mitm6 : se faire passer pour le DNS

L’outil mitm6 écoute le segment réseau et répond à ces sollicitations laissées orphelines. Il attribue au poste Windows une adresse IPv6 et, surtout, s’annonce comme serveur DNS IPv6 de la machine via une réponse DHCPv6. Comme Windows privilégie IPv6, le poste bascule aussitôt : il envoie désormais ses requêtes de résolution de noms à l’attaquant plutôt qu’au DNS légitime du domaine.

mitm6 -d entreprise.local

L’option -d restreint l’empoisonnement au domaine visé, pour rester discret et éviter de perturber tout le réseau. À partir de là, l’attaquant répond aux résolutions par ses propres adresses et capte les authentifications automatiques que Windows émet en permanence vers les serveurs internes, sans la moindre action de l’utilisateur.

WPAD : le complice qui déclenche l’authentification

Reste à provoquer une authentification exploitable. C’est là qu’intervient WPAD (Web Proxy Auto-Discovery), un mécanisme par lequel les navigateurs et de nombreux composants Windows cherchent automatiquement un fichier de configuration de proxy sur le réseau. mitm6 répond à la requête pour wpad, présente un faux fichier de configuration, et le poste tente alors de s’authentifier auprès du proxy pirate. Windows envoie spontanément l’identité de l’utilisateur connecté, sous forme d’une authentification NTLM, sans jamais demander confirmation.

En clair : l’utilisateur ne clique sur rien et ne saisit aucun mot de passe. Son poste offre de lui-même son identité au premier serveur qui la réclame poliment.

Le relais NTLM : de l’écoute à la prise de contrôle

Intercepter du DNS et récolter une authentification ne suffit pas encore. La seconde brique, la plus décisive, est le relais d’authentification NTLM, réalisé avec ntlmrelayx, un outil de la suite Impacket. Le principe est élégant et redoutable : au lieu de tenter de casser un mot de passe, l’attaquant relaie l’authentification reçue, telle quelle, vers un service de l’Active Directory, typiquement le LDAP d’un contrôleur de domaine. Ce rejeu n’est toutefois possible que si le service visé n’impose pas la signature de ses échanges : sans signature LDAP (ou SMB), rien ne lie l’authentification au serveur légitime et l’attaquant peut la rejouer ailleurs. Un prochain article sera consacré à ces mécanismes de signature et à la façon dont ils coupent court au relais NTLM.

ntlmrelayx.py -6 -t ldaps://dc.entreprise.local -wh attaquant-wpad --delegate-access

En clair : la machine cible croit parler à un serveur légitime, mais parle en réalité à l’attaquant, qui rejoue immédiatement cette identité auprès de l’annuaire, avec tous les droits qui l’accompagnent.

Selon les privilèges de l’identité relayée, l’impact monte en puissance :

• lire l’intégralité de l’annuaire Active Directory, y compris la cartographie des groupes et des administrateurs ;
• créer un nouveau compte machine ou utilisateur entièrement contrôlé par l’attaquant ;
• configurer une délégation de droits (via l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity) permettant d’usurper d’autres comptes, parfois jusqu’à l’administrateur du domaine.

Le tout sans exploiter la moindre faille logicielle : uniquement des fonctions natives de Windows détournées de leur usage. Aucun correctif de sécurité ne « répare » ce comportement, car il s’agit d’un fonctionnement prévu du protocole.

Comment l’attaque se déroule lors d’un audit interne

Menée au cours d’un audit interne, cette attaque IPv6 se déroule presque toujours de la même manière. Une machine est branchée sur une prise réseau d’un espace de travail ouvert, souvent une salle de réunion accessible. mitm6 démarre et, en quelques minutes, les premiers postes en cours de démarrage ou de réveil basculent leur DNS. ntlmrelayx collecte les authentifications entrantes et les relaie vers un contrôleur de domaine. Si une seule de ces authentifications appartient à un compte disposant de droits d’écriture sur l’annuaire, la partie est jouée : de quoi créer un compte, poser une délégation et, de proche en proche, remonter jusqu’aux droits d’administration du domaine. Le tout reste passif du point de vue de l’utilisateur, qui continue de travailler sans rien remarquer.

L’impact métier est à la hauteur : la compromission d’un contrôleur de domaine, c’est le contrôle des accès de toute l’organisation, la capacité de lire les partages de fichiers, de déployer un rançongiciel à grande échelle ou d’exfiltrer des données. Une prise réseau mal cloisonnée dans un hall d’accueil devient alors le point de départ d’un incident majeur.

Détecter l’attaque sur le réseau

Ces échanges laissent des traces caractéristiques : un poste qui se met soudain à distribuer des configurations IPv6, des Router Advertisement inattendus, l’apparition d’un serveur DHCPv6 là où il n’y en a jamais eu, un flot d’authentifications relayées vers les contrôleurs de domaine. La BOX Oxyscan surveille ces signaux directement sur le réseau et remonte l’apparition d’un serveur DHCPv6 ou DNS IPv6 illégitime, un indice fort qu’une attaque de type mitm6 est en cours. Déployée en continu, elle permet d’identifier, sur l’ensemble d’un parc, les machines exposées à ce type d’interception. Détecter tôt cette phase de mise en place, c’est couper l’attaque avant le premier relais réussi.

Sur le réseau, ces messages sont visibles à la capture : dès que l’outil entre en action, les annonces de routeur et les sollicitations de voisin en ICMPv6 se multiplient.

Corriger la faille : neutraliser IPv6 sans le désactiver

La première réaction, couper purement et simplement IPv6, est rarement la bonne. Microsoft déconseille cette désactivation totale, car Windows est testé avec IPv6 actif et certains composants (Exchange, clusters de basculement) peuvent mal se comporter sans lui. L’objectif n’est donc pas de supprimer IPv6, mais d’empêcher un poste d’accepter une configuration IPv6 distribuée par un inconnu.

La mesure la plus propre consiste à bloquer, via le pare-feu Windows et déployé par GPO sur tout le domaine, les deux briques dont l’attaque a besoin : les réponses DHCPv6 et les annonces de routeur. Trois règles prédéfinies passent à Bloquer :

• (Entrante) Core Networking, Dynamic Host Configuration Protocol for IPv6 (DHCPV6-In), port UDP 546 ;
• (Entrante) Core Networking, Router Advertisement (ICMPv6-In), ICMPv6 type 134 ;
• (Sortante) Core Networking, Dynamic Host Configuration Protocol for IPv6 (DHCPV6-Out).

Cette configuration neutralise l’attaque tout en conservant les adresses IPv6 de lien local, elle n’a donc pas d’effet de bord sur les composants Windows.

Côté réseau, les fonctions RA Guard et DHCPv6 Guard viennent en complément sur les commutateurs : elles bloquent en bordure les annonces de routeur et les réponses DHCPv6 émises depuis un port non autorisé, et protègent aussi les machines Linux et macOS que le durcissement Windows ne couvre pas. Sur ces systèmes, les annonces de routeur peuvent également être refusées localement (par exemple sysctl net.ipv6.conf.all.accept_ra=0 sous Linux).

Une variante consiste à rendre IPv4 prioritaire sur IPv6, ce qui retire à la configuration distribuée par l’attaquant sa priorité sur la configuration légitime. Ce réglage se déploie lui aussi par GPO, via une préférence de registre :

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
DisabledComponents = 0x20 (DWORD 32 bits)

En dernier recours seulement, si une politique interne impose la désactivation complète d’IPv6, elle se réalise par PowerShell sur chaque machine. La même famille de commandes permet d’ailleurs de vérifier l’état du protocole sur les cartes réseau :

Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6

Cette méthode ne couvre toutefois que les cartes réseau existantes et ne se déploie pas nativement par GPO, contrairement aux deux précédentes. Enfin, quelle que soit l’option retenue, la signature SMB, la signature LDAP et la liaison de canal LDAP restent indispensables : même si un poste se laissait piéger, ces protections empêchent la réutilisation de l’authentification interceptée, donc le relais qui fait tout l’intérêt de l’attaque.

Conclusion

mitm6 illustre un principe qui se vérifie à chaque mission : une fonctionnalité activée par défaut et jamais configurée reste une surface d’attaque à part entière. IPv6 n’est pas dangereux en soi, c’est son abandon qui l’est. Quelques mesures ciblées referment la brèche sans casser l’existant, et la plupart sont recommandées de longue date par l’ANSSI dans ses guides de durcissement de l’Active Directory.

Conseils : désactiver IPv6 sur les postes uniquement s’il n’est pas utilisé (et proprement, via stratégie de groupe, plutôt que par une manipulation improvisée), activer le DHCPv6 Guard et le RA Guard sur les commutateurs pour bloquer les annonces pirates, imposer la signature LDAP ainsi que le channel binding (Extended Protection for Authentication) sur les contrôleurs de domaine afin de rendre tout relais inopérant, et cloisonner les prises réseau accessibles au public.

Pour aller plus loin

• MITRE ATT&CK, technique T1557 (Adversary-in-the-Middle), la référence qui classe et documente les attaques par interception et relais.
• ANSSI, guides de sécurisation d’Active Directory et de durcissement de Windows.
• Projet mitm6 de Dirk-jan Mollema, la recherche et l’outil à l’origine de la technique.
• Suite Impacket (ntlmrelayx), la boîte à outils open source utilisée pour le relais NTLM.
• Microsoft Learn, activer la signature LDAP sur les contrôleurs de domaine.