Énumération de sous-domaines pour les équipes sécurité : découverte de la surface d'attaque et reconnaissance DNS

Chaque domaine a son ombre. Le marketing lance un mini-site de campagne, l'ingénierie oublie de démonter une machine de préproduction, un prestataire raccorde un CNAME à un essai SaaS jamais renouvelé — et rien de tout cela n'apparaît dans l'inventaire d'actifs que quelqu'un maintient réellement. Les attaquants le savent. L'énumération de sous-domaines fait partie des toutes premières actions d'un script de reconnaissance lancé contre une cible, précisément parce que le domaine parent est généralement bien verrouillé alors que ses enfants oubliés ne le sont pas. Pour les défenseurs, la même technique est le moyen le plus rapide de répondre à une question dérangeante : qu'est-ce qui tourne réellement sous notre nom en ce moment ?

Pourquoi l'énumération compte des deux côtés

Pour un attaquant, une liste de sous-domaines est une carte de la surface d'attaque avant même qu'un seul paquet n'atteigne la « vraie » application. Une passe d'énumération large fait souvent remonter des panneaux d'administration, des outils internes exposés par accident, d'anciennes versions d'API qui acceptent encore du trafic, et des environnements de préproduction dotés d'une authentification plus faible que la production. Rien de tout cela n'exige d'exploiter une vulnérabilité — il suffit de savoir où regarder.

Pour un défenseur, exactement la même liste est une correction de l'inventaire d'actifs. Chez la plupart des organisations, la CMDB officielle sous-estime l'empreinte réelle, car les sous-domaines sont créés en dehors de la gestion des changements : le déploiement Vercel personnel d'un développeur pointé vers un sous-domaine de l'entreprise, l'hôte du pixel de tracking d'un outil marketing, un produit décommissionné qui résout encore. Le shadow IT ne s'annonce pas. L'énumération est le moyen de le trouver avant quelqu'un d'autre.

Techniques passives et actives

Toutes les méthodes de découverte ne présentent pas le même risque ni la même couverture, et un programme mature utilise les deux.

Les techniques passives interrogent des enregistrements publics sans jamais envoyer de trafic vers l'infrastructure cible :

• Journaux de transparence des certificats — tout certificat TLS publiquement approuvé est journalisé, et chacun liste l'ensemble des noms d'hôtes qu'il couvre. Chercher un domaine parent dans les journaux CT fait remonter tous les sous-domaines ayant un jour demandé un certificat, y compris ceux créés puis décommissionnés il y a plusieurs mois.
• DNS passif — données de résolution historiques collectées par des sondes et des résolveurs à travers Internet, montrant quels noms d'hôtes ont existé et vers quoi ils pointaient, même après que les enregistrements eux-mêmes ont été supprimés ou modifiés.
• Indexation par les moteurs de recherche et les archives — pages en cache, crawls archivés et résultats de recherche révèlent parfois des noms d'hôtes brièvement publics puis verrouillés.

Les méthodes passives peuvent être utilisées sans risque contre des domaines que vous ne possédez pas — elles ne touchent aucune infrastructure — mais elles sont par nature tournées vers le passé et peuvent manquer tout ce qui n'a jamais généré de certificat public ni été crawlé.

Les techniques actives interagissent directement avec le DNS ou le réseau de la cible :

• Brute force par dictionnaire — interroger un résolveur avec des milliers de noms d'hôtes probables (dev, staging, vpn, mail2, api-v1) et noter lesquels résolvent. La couverture dépend entièrement de la qualité du dictionnaire et de la justesse des conventions de nommage devinées.
• Zone walking — exploiter les zones signées DNSSEC qui utilisent des enregistrements NSEC (plutôt que NSEC3) pour énumérer tous les noms d'une zone en parcourant l'ordre canonique, ce qui revient à obtenir un transfert de zone complet sans qu'il soit explicitement autorisé.
• Tentatives de transfert de zone — il arrive encore qu'un serveur autoritaire mal configuré accepte une requête AXFR d'un client non autorisé, livrant la zone entière en une seule requête.

Les techniques actives trouvent des noms d'hôtes que les sources passives n'ont jamais vus, mais elles génèrent du trafic contre de l'infrastructure réelle et doivent être réservées aux domaines couverts par votre propre autorisation — cette reconnaissance est strictement identique qu'elle vienne de votre red team ou de celle de quelqu'un d'autre.

Transformer une liste de noms d'hôtes en image du risque

Une liste brute de sous-domaines n'est pas, en soi, actionnable. Deux cents noms d'hôtes ne vous disent rien sur les dix qui méritent votre attention cet après-midi. La liste ne devient une image du risque qu'une fois chaque entrée enrichie :

• Score de réputation — l'IP résolue ou le nom d'hôte lui-même est-il déjà associé à une activité malveillante, à des blocklists ou à une infrastructure connue comme malveillante ? Une passe d'énumération de sous-domaines passée par la découverte de sous-domaines et les vérifications de réputation transforme une liste plate en liste hiérarchisée.
• Historique DNS — la résolution de ce nom d'hôte a-t-elle changé de mains ? Un enregistrement qui pointait vers votre propre load balancer et pointe désormais vers une plage d'IP tierce est le signal le plus fort d'une entrée orpheline ou détournée, et les recherches d'historique DNS existent précisément pour y répondre.
• Contexte ASN d'hébergement — le sous-domaine résout-il toujours à l'intérieur des comptes cloud et des ASN connus de votre organisation, ou a-t-il dérivé vers une infrastructure que personne dans l'équipe n'a provisionnée ? Le recoupement avec les données d'ASN et de propriété réseau sépare « oublié mais à nous » de « à quelqu'un d'autre désormais ».

Combinés, ces trois signaux transforment un déversement indifférencié de noms d'hôtes en une liste courte et priorisée : la poignée de sous-domaines réellement dangereux face à la majorité qui n'est que dormante.

Constats fréquents : actifs oubliés et DNS orphelins

Les mêmes schémas ressortent de presque tous les exercices d'énumération :

• Environnements de dev et de préproduction oubliés — souvent avec des logiciels obsolètes, une authentification plus faible ou des pages d'erreur verbeuses qui divulguent des détails d'architecture interne.
• Mini-sites marketing orphelins — des domaines de campagne qui ont survécu à la campagne et restent non patchés et non surveillés.
• Enregistrements CNAME orphelins — un sous-domaine pointe encore vers une ressource cloud (bucket de stockage, application PaaS, endpoint CDN) qui a été déprovisionnée. Celui qui réclame ensuite ce nom de ressource côté fournisseur hérite de votre sous-domaine, et avec lui de la capacité à servir du contenu ou à collecter des sessions sous un nom d'hôte auquel vos utilisateurs font déjà confiance.
• Résidus de SaaS tiers — un CNAME pointé vers un compte fournisseur en essai ou résilié, laissé à résoudre vers le vide jusqu'à ce qu'un attaquant enregistre l'emplacement équivalent.

Aucun de ces cas ne nécessite un zero-day. Ils nécessitent que quelqu'un s'en aperçoive, ce à quoi sert exactement une passe récurrente d'énumération et d'enrichissement.

Trier à l'échelle

Une recherche sur un seul nom d'hôte est simple. Deux cents noms d'hôtes découverts en une passe d'énumération constituent un problème de triage, et les vérifier un par un à la main ne tient pas au-delà de la première douzaine. Injecter la liste complète découverte dans la vérification en masse permet à une équipe de scorer, étiqueter et classer tout un inventaire de sous-domaines en une seule opération, afin que le temps de l'analyste aille à la poignée d'entrées réellement risquées plutôt qu'à répéter manuellement deux cents fois la même recherche.

Rendre la découverte continue

Une énumération de sous-domaines effectuée une seule fois, lors d'un audit annuel, n'est qu'un instantané d'une empreinte qui ne cesse de bouger en dessous. De nouveaux noms d'hôtes apparaissent dès qu'une équipe provisionne de l'infrastructure en dehors de la gestion des changements, et des enregistrements orphelins apparaissent dès que quelque chose est démonté sans nettoyage DNS correspondant. Traitez la découverte comme un processus permanent plutôt que comme un projet : planifiez une énumération récurrente, faites passer les résultats par l'enrichissement de réputation et d'historique DNS, et vérifiez en masse toute nouveauté avant qu'elle ne devienne le point d'appui de quelqu'un d'autre. Pour les équipes qui intègrent cela à leur outillage existant ou à un pipeline SOC, l'ensemble du workflow d'énumération, d'historique DNS, d'ASN et de vérification en masse est disponible via l'API isMalicious, afin que la surveillance continue de la surface d'attaque tourne sans supervision entre les moments où un humain doit réellement regarder.