Introduction
La collecte de renseignements sur le système de noms de domaine (DNS) est une première étape cruciale dans la phase de reconnaissance en cybersécurité. Le DNS agit comme l'annuaire d'Internet, traduisant les noms de domaine lisibles par l'homme en adresses IP. En interrogeant les enregistrements DNS, les professionnels de la sécurité peuvent découvrir une mine d'informations sur l'infrastructure d'une cible, notamment les serveurs de messagerie, les sous-domaines et les configurations de sécurité.
Le DNS est particulièrement précieux pour la reconnaissance car il révèle les relations entre les infrastructures plutôt qu'un simple point de terminaison. Un seul domaine peut vous orienter vers des serveurs Web, des fournisseurs de messagerie, des jetons de validation, des alias et parfois des environnements entiers oubliés. C'est pourquoi le renseignement DNS élargit souvent considérablement la portée d'une évaluation.
Dans ce laboratoire, vous apprendrez à utiliser deux outils en ligne de commande puissants, host et dig, pour effectuer une reconnaissance DNS. Nous utiliserons un domaine délibérément vulnérable, zonetransfer.me, conçu spécifiquement par des chercheurs en sécurité pour pratiquer les requêtes DNS et les transferts de zone en toute sécurité. Vous apprendrez à extraire des enregistrements IP de base, des détails sur les serveurs de messagerie, des enregistrements texte, et même à tenter un transfert de zone complet pour cartographier l'empreinte DNS totale de la cible.
Interroger les enregistrements IP de base (A/AAAA)
Dans cette étape, vous apprendrez à récupérer les enregistrements DNS les plus fondamentaux : les enregistrements A et AAAA. Un enregistrement A fait correspondre un nom de domaine à une adresse IPv4, tandis qu'un enregistrement AAAA le fait correspondre à une adresse IPv6. Trouver ces adresses IP est essentiel car cela vous indique exactement où est hébergé le serveur Web principal de la cible.
Ceci est un rappel que les domaines et les hôtes ne sont pas le même concept. Un nom de domaine est une étiquette dans le DNS. Une adresse IP est l'endroit où le trafic est finalement acheminé. La reconnaissance commence souvent par la traduction entre ces deux vues.
Nous commencerons par utiliser la commande host, qui est un utilitaire simple pour effectuer des recherches DNS. Assurez-vous d'être dans votre répertoire de travail par défaut ~/project.
Exécutez la commande suivante pour effectuer une recherche de base sur notre domaine cible :
host zonetransfer.me
Vous devriez voir un résultat similaire à celui-ci, affichant l'adresse IPv4 et les serveurs de messagerie associés au domaine :
zonetransfer.me has address 5.196.105.14
zonetransfer.me mail is handled by 10 alt2.aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx2.googlemail.com.
zonetransfer.me mail is handled by 10 alt1.aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx3.googlemail.com.
zonetransfer.me mail is handled by 0 aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx4.googlemail.com.
zonetransfer.me mail is handled by 20 aspmx5.googlemail.com.
Bien que host soit idéal pour des vérifications rapides, la commande dig (Domain Information Groper) fournit une sortie beaucoup plus détaillée et flexible. Utilisons dig pour demander spécifiquement l'enregistrement A. Nous utiliserons l'indicateur +short pour garder la sortie propre, en affichant uniquement l'adresse IP.
Pour enregistrer nos données de reconnaissance pour une analyse ultérieure, nous redirigerons la sortie de notre commande dig vers un fichier texte nommé a_records.txt. Exécutez la commande suivante :
dig A zonetransfer.me +short > ~/project/a_records.txt
Vous pouvez visualiser le contenu du fichier que vous venez de créer en utilisant la commande cat :
cat ~/project/a_records.txt
La sortie affichera l'adresse IPv4 du domaine cible. Sauvegarder vos découvertes est une habitude cruciale dans la collecte de renseignements, car cela vous permet de construire un profil complet de votre cible au fil du temps.
5.196.105.14
Interroger les enregistrements de messagerie et de texte (MX, TXT)
Dans cette étape, nous approfondirons l'infrastructure de la cible en interrogeant les enregistrements Mail Exchange (MX) et Text (TXT).
Les enregistrements MX spécifient les serveurs de messagerie responsables de l'acceptation des messages électroniques pour le compte d'un domaine. L'identification de ces serveurs peut révéler quels fournisseurs de messagerie tiers la cible utilise (comme Google Workspace ou Microsoft 365) ou s'ils hébergent leur propre infrastructure de messagerie.
Les enregistrements TXT sont tout aussi précieux car ils décrivent souvent des relations de confiance, telles que les systèmes autorisés à envoyer des e-mails ou les services externes qui ont été vérifiés pour le domaine.
Interrogeons les enregistrements MX pour notre domaine cible en utilisant dig :
dig MX zonetransfer.me +short
Vous verrez une liste de serveurs de messagerie ainsi que leurs numéros de priorité (les nombres les plus bas signifient une priorité plus élevée) :
20 aspmx5.googlemail.com.
10 alt1.aspmx.l.google.com.
10 alt2.aspmx.l.google.com.
20 aspmx2.googlemail.com.
20 aspmx3.googlemail.com.
0 aspmx.l.google.com.
20 aspmx4.googlemail.com.
Ensuite, nous examinerons les enregistrements TXT. Les administrateurs utilisent les enregistrements TXT pour ajouter du texte arbitraire au DNS d'un domaine. En cybersécurité, les enregistrements TXT sont très précieux car ils contiennent souvent des règles Sender Policy Framework (SPF), des configurations DomainKeys Identified Mail (DKIM) et divers jetons de vérification de site. Ceux-ci peuvent révéler les plages IP internes autorisées à envoyer des e-mails ou les services tiers intégrés au domaine.
Interrogeons les enregistrements TXT et enregistrons la sortie dans un fichier nommé txt_records.txt dans votre répertoire de travail :
dig TXT zonetransfer.me +short > ~/project/txt_records.txt
Visualisez le contenu du fichier pour voir quelles informations les administrateurs ont laissées dans les enregistrements TXT :
cat ~/project/txt_records.txt
Vous remarquerez peut-être des entrées commençant par v=spf1, qui définissent les politiques d'envoi d'e-mails, ou diverses chaînes de vérification. Ces informations aident à cartographier les relations de confiance que le domaine cible entretient avec d'autres services.
"google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"
Découvrir les sous-domaines (CNAME)
Dans cette étape, vous découvrirez les enregistrements Canonical Name (CNAME). Un enregistrement CNAME est utilisé pour faire correspondre un nom d'alias à un nom de domaine réel ou canonique. Par exemple, www.example.com pourrait être un CNAME pointant vers example.com.
La découverte de sous-domaines est une partie essentielle de l'extension de votre surface d'attaque. Souvent, les organisations sécurisent leur site Web principal mais oublient de mettre à jour ou de sécuriser les anciens sous-domaines oubliés (comme dev.target.com ou testing.target.com).
Interrogeons un sous-domaine spécifique dont l'existence est connue sur notre cible d'entraînement pour voir comment se comportent les enregistrements CNAME. Nous interrogerons testing.zonetransfer.me et enregistrerons les résultats.
Exécutez la commande suivante pour interroger l'enregistrement CNAME et l'enregistrer dans cname_records.txt :
dig CNAME testing.zonetransfer.me +short > ~/project/cname_records.txt
Maintenant, inspectez le fichier que vous venez de créer :
cat ~/project/cname_records.txt
Vous devriez voir un résultat comme www.zonetransfer.me.. Cela nous indique que testing.zonetransfer.me est en fait juste un alias pointant vers un autre domaine entièrement. Trouver ces relations peut conduire un chercheur en sécurité à découvrir des fournisseurs d'hébergement tiers ou des infrastructures cachées appartenant à la cible.
Tenter un transfert de zone DNS
Dans cette dernière étape, vous tenterez un transfert de zone DNS. Un transfert de zone (utilisant spécifiquement le type de requête AXFR) est un mécanisme utilisé par les serveurs DNS pour répliquer les bases de données DNS sur plusieurs serveurs.
Les transferts de zone sont un exemple classique d'une fonctionnalité administrative légitime devenant un problème de sécurité lorsque le contrôle d'accès est faible. Le mécanisme lui-même est normal. La mauvaise configuration consiste à permettre à des étrangers arbitraires de demander l'intégralité des données.
Si un serveur DNS est mal configuré, il peut permettre à n'importe quel utilisateur anonyme de demander une copie complète du fichier de zone. Il s'agit d'une vulnérabilité de sécurité massive car elle fournit instantanément à l'attaquant une carte complète de chaque sous-domaine, adresse IP et enregistrement associé au domaine, évitant ainsi d'avoir à deviner ou à forcer les sous-domaines.
Pour tenter un transfert de zone, nous devons d'abord connaître les serveurs de noms (NS) faisant autorité pour le domaine. Interrogeons les enregistrements NS :
dig NS zonetransfer.me +short
Vous devriez voir une sortie listant les serveurs de noms, tels que :
nsztm1.digi.ninja.
nsztm2.digi.ninja.
Maintenant que nous avons le serveur de noms (nsztm1.digi.ninja), nous pouvons lui demander directement un transfert de zone complet en utilisant le type d'enregistrement axfr. La syntaxe de dig nous oblige à spécifier le domaine cible et le serveur de noms spécifique que nous interrogeons (en utilisant le symbole @).
Exécutez la commande suivante pour tenter le transfert de zone et enregistrer l'énorme quantité de sortie dans zone_transfer.txt :
dig axfr zonetransfer.me @nsztm1.digi.ninja > ~/project/zone_transfer.txt
Une fois la commande terminée, visualisez les premières lignes du fichier en utilisant la commande head :
head -n 20 ~/project/zone_transfer.txt
Vous verrez un vidage complet des enregistrements DNS du domaine, y compris les sous-domaines cachés, les adresses IP internes et diverses notes textuelles laissées par les administrateurs. Dans un scénario réel, trouver un transfert de zone ouvert est une découverte critique qui accélère considérablement la phase de reconnaissance.
Résumé
Félicitations ! Vous avez terminé avec succès le laboratoire de collecte de renseignements DNS.
Dans ce laboratoire, vous avez appris à exploiter les commandes host et dig pour effectuer une reconnaissance passive sur un domaine cible. Vous avez exploré comment extraire des adresses IPv4 de base (enregistrements A), identifier l'infrastructure de messagerie (enregistrements MX) et découvrir les politiques de sécurité et les intégrations tierces (enregistrements TXT). Vous avez également appris à tracer les alias de domaine (enregistrements CNAME) pour découvrir des sous-domaines cachés. Enfin, vous avez exécuté avec succès un transfert de zone DNS (AXFR) contre un serveur de noms mal configuré, démontrant comment une seule vulnérabilité peut exposer toute la topologie réseau externe d'une organisation.
Ces compétences constituent la base de la cartographie réseau externe et sont essentielles pour tout professionnel de la cybersécurité effectuant des tests d'intrusion ou des évaluations de vulnérabilité.
