Votre domaine interne appartient déjà à quelqu’un d’autre

Que se passe-t-il lorsque votre nom de domaine interne est en réalité enregistré et exploité par quelqu’un d’autre ? Des identifiants fuitent, des e-mails partent au mauvais endroit, des chaînes de déploiement récupèrent du code depuis des sources non fiables. Et la plupart du temps, personne ne s’en aperçoit pendant des années. Présentée à BarbHack 2026, cette recherche a mesuré le phénomène à l’échelle d’Internet, puis l’a exploité pour de vrai. Le résultat est difficile à ignorer.

Septième volet de notre couverture de BarbHack, et probablement celui qui concerne le plus grand nombre d’organisations, y compris celles qui n’ont pas d’équipe sécurité.

La démonstration : entrer chez Initech sans rien casser

Le principe est posé sur une entreprise fictive, « Initech », avec une surface d’attaque externe on ne peut plus banale : un portail client, un serveur de messagerie, un VPN. Rien d’exotique.

Première étape, faire parler le serveur. Une faiblesse bien connue de NTLM permet, en amorçant une simple négociation, d’obtenir qu’il révèle de lui-même son nom de domaine interne, sans la moindre authentification. Ici, initech.lhc. Deuxième étape, la vérification qui change tout : ce domaine, en service depuis 2018, n’avait jamais été enregistré publiquement.

L’attaquant l’achète, configure la résolution inverse, et attend. Ce qui arrive ensuite n’est pas une exploitation, c’est une conséquence mécanique. Les salariés en télétravail émettent des requêtes DNS pour des ressources internes, la configuration de proxy via WPAD, la découverte des contrôleurs de domaine. Hors du réseau de l’entreprise, ces requêtes ne trouvent plus le contrôleur de domaine : elles partent sur Internet, vers le serveur de l’attaquant, qui répond. Un outil comme Responder collecte les empreintes de mots de passe, qui sont ensuite cassées, et le VPN s’ouvre.

Le MFA n’a pas résisté non plus : la validation reposait sur une simple notification poussée sur mobile, et un utilisateur a approuvé la connexion par réflexe, en pensant valider autre chose.

Aucune vulnérabilité logicielle n’a été exploitée. L’attaquant a simplement acheté un nom que l’entreprise utilisait sans le posséder.

Pourquoi ce risque augmente : l’expansion des extensions

Avant 2013, il existait huit extensions de premier niveau. En 2016, plus de 1 200. En 2024, plus de 1 600 nouvelles candidatures ont été déposées. L’orateur relie sans détour cette inflation à son modèle économique : revenus récurrents des opérateurs de registre (91 millions de dollars en 2023), frais sur les transactions, et surtout des frais de candidature non remboursables de 227 000 dollars, qui ont alimenté un fonds distinct de 263 millions.

Les effets de bord sont connus : protection des marques devenue coûteuse, confusion des utilisateurs, extensions comme .zip qui facilitent l’hameçonnage. Mais le risque le plus grave est ailleurs. Chaque nouvelle extension transforme potentiellement un nom interne privé en domaine public valide. Or renommer un Active Directory est en pratique impossible : l’entreprise se retrouve donc à devoir acheter le domaine public, ou reconstruire son infrastructure.

L’ICANN a bien prévu une mitigation, l’interruption contrôlée, qui fait répondre les nouveaux domaines par l’adresse 127.0.53.53 pour que les administrateurs repèrent le conflit. L’orateur la juge insuffisante, et souligne que les opérateurs de registre, qui ont lourdement investi, sont peu incités à signaler ces collisions.

La méthode, en trois étapes

Le problème est documenté depuis les années 2010, mais son ampleur restait inconnue. D’où une méthodologie industrialisée :

• Récolter les noms internes qui fuient déjà sur Internet. Les sources sont plus nombreuses qu’on ne le croit : bannières de services SMTP, certificats auto-signés notamment sur RDP, listes de révocation de certificats, en-têtes d’e-mails (un exemple montré révélait ankara.local.ads chez un opérateur français), et fuites NTLM comme dans la démonstration.
• Croiser ces noms avec les extensions ambiguës. Des ccTLD de pays qui ressemblent à des suffixes techniques, .ad pour Andorre, .ms pour Montserrat, et des extensions génériques typiquement utilisées en interne, .company, .tech, .sarl.
• Vérifier la disponibilité. Les limitations des serveurs Whois interdisant le passage à l’échelle, une résolution DNS préalable élimine 90 % des domaines déjà pris, puis les API de registraires confirment le reste. Au passage, cette méthode a mis au jour d’autres failles, liées à des serveurs DNS mal configurés ou à de simples fautes de frappe.

Les cas réels, et ils font mal

La police de Memphis utilisait le domaine interne mrtcc.ad. Pour pouvoir l’enregistrer, les chercheurs ont dû déposer une marque en Andorre, pour 320 euros. En une semaine, plus d’un million de requêtes captées, dont des requêtes de stratégies de groupe et des authentifications SAML. L’interception d’un e-mail d’enrôlement leur a permis de créer un compte administrateur sur la plateforme Okta de la ville, et donc d’obtenir un accès complet à son Active Directory. Délai de récupération du domaine par la ville : 874 jours.

L’extension .ad à elle seule illustre l’écart entre l’usage et l’enregistrement : 25 000 certificats auto-signés observés pour seulement 1 200 domaines officiellement enregistrés. L’achat de noms génériques comme local.ad a touché plus de 1 200 entreprises d’un coup, et généré 9 millions de requêtes en une semaine.

Le reste de la liste se passe de commentaire :

• Police polonaise (kwp.ad) : mots de passe récupérés en clair depuis des clients de messagerie mobiles.
• Optic 2000 (optic2000.ad) : 300 000 requêtes interceptées, dont des accès aux serveurs Exchange.
• Belin (belin.ad) : 300 000 requêtes, et la capture d’identifiants de leur VPN.
• STAS, transport public de Saint-Étienne (stas.ad) : 100 000 requêtes, jusqu’à l’accès administrateur d’un vCenter.

Le signalement, ou l’art de punir le messager

C’est la partie la plus instructive pour toute organisation. Contacter individuellement chaque entité étant impossible, une notification globale a été adressée à l’ANSSI le 2 décembre 2025 pour les entreprises françaises concernées. Réponse de l’agence : elle n’intervient pas « en l’absence d’incident de cybersécurité ».

Quant aux entreprises prévenues, deux d’entre elles, Optic 2000 et Belin, ont préféré engager des procédures juridiques coûteuses, plainte auprès de l’OMPI pour l’une, courrier d’avocats pour l’autre, plutôt que d’accepter l’offre de transfert gratuit du domaine qui leur était faite. Microsoft, contacté de vive voix en conférence, a racheté les domaines problématiques via son programme de bug bounty, mais le transfert final n’a jamais été effectué. Et une liste d’organisations majeures, dont un aéroport européen et un opérateur national d’électricité, reste vulnérable, faute d’avoir répondu.

Les chiffres de l’étude, pour finir : 46 millions de certificats SSL et 9,5 millions de services NTLM analysés, 203 domaines enregistrés pour environ 8 000 dollars, et 11 milliards de requêtes DNS reçues sur l’infrastructure des chercheurs en deux ans.

Le même mécanisme chez vous : le cas « .box »

Le problème ne s’arrête pas aux entreprises, et une seconde étude présentée dans la foulée le montre bien. Les box et routeurs grand public injectent un suffixe DNS local : fritz.box chez AVM, sveron.box sur des équipements Zyxel en marque blanche. Toute requête non pleinement qualifiée est complétée avec ce suffixe, puis transmise aux résolveurs publics. Tant que l’extension n’existe pas, elle ne résout nulle part. Le jour où elle devient publiquement enregistrable, la fuite devient exploitable.

C’est ce qui s’est produit en février 2024 avec l’ouverture de l’extension .box. Un squatteur avait enregistré fritz.box avant l’ouverture publique, puis tenté de le revendre, un million de dollars d’abord, 250 000 ensuite, sans trouver preneur. Des utilisateurs ont commencé à observer des résolutions anormales, et le fabricant a obtenu le transfert forcé du domaine par la voie de l’OMPI.

Les chercheurs ont alors acquis sveron.box : 4 à 5 millions de requêtes DNS en une semaine. Deux détails valent d’être retenus. D’abord, après restitution du domaine, le nouvel ayant droit n’a pas reconfiguré les serveurs de noms, si bien que le trafic a continué de pointer vers les chercheurs. Ensuite, le fabricant avait initialement sous-estimé le risque parce qu’il interprétait les adresses IP des résolveurs publics comme celles des clients. Il a fallu la capture de mots de passe pour emporter la conviction.

La même étude rapporte un cas voisin, presque comique s’il n’était pas grave : un serveur de noms saisi avec une faute de frappe, domaincontrol.com au lieu de domaincontroller.com. Les chercheurs ont enregistré le domaine inexistant, pris le contrôle effectif de la délégation d’un domaine .gov, créé des enregistrements MX et envoyé des e-mails au nom de cette administration.

Ce qu’on en retient chez Humanix

• Utiliser des noms pleinement qualifiés ne suffit pas. C’est la conclusion explicite de l’orateur, et elle est contre-intuitive. Ce qui compte est que l’extension utilisée en interne soit réservée et jamais déléguée publiquement. Concrètement : un sous-domaine d’un domaine que vous possédez réellement, ou un espace de noms réservé comme .home.arpa côté équipements. Jamais une extension inventée qui paraît libre aujourd’hui.
• Faites l’inventaire de ce que votre surface externe raconte. Bannières SMTP, certificats auto-signés sur RDP, listes de révocation, en-têtes d’e-mails, négociation NTLM : votre nom de domaine interne est probablement déjà public. Cette vérification est rapide, elle ne nécessite aucun accès, et elle devrait figurer dans tout audit de surface d’attaque, le nôtre compris.
• Bloquez la fuite au résolveur. Tant que la migration n’est pas faite, refusez la résolution externe des suffixes internes hérités. C’est une mesure de quelques minutes qui coupe le canal, indépendamment de qui possède le domaine.
• La réponse juridique n’est pas une réponse technique. Pendant les mois que dure une procédure, le domaine continue de capter le trafic. Memphis a mis 874 jours. Deux entreprises françaises ont payé des avocats pour obtenir ce qu’on leur proposait gratuitement. Le réflexe défensif a coûté plus cher que le problème.
• « Pas d’incident » ne veut pas dire « pas de compromission ». La réponse reçue de l’agence nationale illustre un angle mort structurel : une interception silencieuse ne produit aucun incident à déclarer, donc rien ne se déclenche. C’est précisément pour ces risques sans alarme que la démonstration vaut mieux que la mise en demeure. Montrer les requêtes captées, les identifiants récupérés et le chemin qui mène à l’administrateur, c’est ce qui déclenche une décision : la preuve avant le verdict.

Note. Compte-rendu, à visée pédagogique, d’une conférence de BarbHack 2026 consacrée aux collisions de noms de domaine internes, complété par une seconde étude présentée sur le risque systémique lié à l’extension .box. Les organisations citées l’ont été publiquement sur scène ; les domaines concernés ont fait l’objet de tentatives de signalement documentées par les chercheurs. Septième volet de notre couverture de l’événement. Envie de savoir ce que votre surface externe révèle de votre domaine interne ? Contactez-nous.