Analyse DNS dans un PCAP : guide pour les défenseurs
Lire le DNS dans une capture réseau : requêtes et réponses, codes de retour, domaines rares ou aléatoires et signes de tunnel DNS, avec leurs limites.
En bref. Le DNS est le meilleur point de départ dans presque toute capture : il est léger, en grande partie non chiffré, et il dit ce que chaque hôte cherchait à joindre. Commencez par identifier les résolveurs, puis lisez les noms demandés, leurs codes de retour et leurs réponses, et reliez les réponses aux conversations qui suivent. Surveillez les noms demandés une seule fois, les rafales de NXDOMAIN pour des noms d'apparence aléatoire, et les nombreux sous-domaines longs et uniques sous un même domaine. Ces motifs orientent vers des algorithmes de génération de domaines et du tunnel DNS, mais les CDN, les produits de sécurité et les navigateurs produisent des faux positifs : traitez-les comme des pistes à confirmer.
Le DNS dans une capture : les bases
Un échange DNS, c'est normalement une requête et une réponse sur le port UDP 53, associées par un identifiant de transaction sur 16 bits. Les grosses réponses et les transferts de zone passent par TCP. La RFC 1035 définit le format des messages et les limites à retenir : un label (le texte entre deux points) fait au plus 63 octets, et un nom complet au plus 255.
Les champs que vous lirez le plus :
| Champ | Ce qu'il vous apprend |
|---|---|
| Nom demandé (QNAME) | Ce que le client voulait joindre |
| Type de requête | A / AAAA (adresses), CNAME (alias), MX, TXT, NS, PTR, SRV... |
| Code de retour (RCODE) | NOERROR, NXDOMAIN (le nom n'existe pas), SERVFAIL, REFUSED |
| Réponses | Adresses, alias ou texte renvoyés, chacun avec un TTL |
| Client et serveur | Quel hôte a demandé, et quel résolveur a répondu |
Comme les résolveurs mettent les réponses en cache pendant le TTL, une capture montre la première résolution d'un nom, pas chaque visite. Un hôte qui réutilise une adresse en cache produit des connexions sans requête correspondante dans la capture.
Un ordre de lecture qui fonctionne
1. Identifier les résolveurs
Listez les serveurs qui répondent sur le port 53. Dans un réseau géré, les clients doivent utiliser les résolveurs internes. Un poste qui envoie ses requêtes directement à un résolveur externe contourne la journalisation et le filtrage. Cherchez aussi le DNS sur TLS sur le port 853 (RFC 7858), et rappelez-vous que le DNS sur HTTPS (RFC 8484) ressemble à du HTTPS ordinaire ; le SNI TLS de fournisseurs DoH connus est souvent le seul indice visible.
2. Lire les noms, regroupés par domaine enregistrable
Regroupez les requêtes par domaine enregistrable (mega.co.nz plutôt que gfs270n.userstorage.mega.co.nz) et comptez-les. L'essentiel de la liste correspondra au système d'exploitation, au navigateur et aux services métier. Ce qui reste, c'est souvent là que se trouve l'histoire : services de partage de fichiers, sosies récemment enregistrés de vos propres domaines, fournisseurs de DNS dynamique.
3. Vérifier les codes de retour
Quelques réponses NXDOMAIN sont normales (fautes de frappe, suffixes de recherche obsolètes). Une grappe de réponses de ce type provenant d'un seul hôte, pour des noms qui semblent générés par une machine, ne l'est pas.
4. Relier les réponses aux conversations
Pour chaque nom intéressant, prenez les adresses renvoyées et cherchez les conversations vers elles juste après la résolution. Un nom résolu puis contacté est une preuve plus solide qu'une simple résolution. L'inverse compte aussi : des connexions vers des adresses publiques sans résolution préalable peuvent utiliser une IP codée en dur.
Repérer les domaines inhabituels
Les noms rarement vus
La fréquence est un filtre étonnamment efficace. Un domaine enregistrable qui n'apparaît qu'une fois dans une capture, et qui n'est pas un service d'arrière-plan courant, mérite d'être lu. PCAP Parser les signale comme Rarely-seen domain, en excluant les suffixes locaux comme .local ou .corp et une courte liste de services courants. Dans une capture courte, en revanche, tout est rare : ce signalement est plus utile sur des enregistrements longs.
Les noms longs et d'apparence aléatoire
Les noms choisis par des humains sont faits de mots ; ceux générés par des machines, non. Une façon simple de le mesurer est l'entropie de Shannon : le nombre moyen de bits nécessaires par caractère. Les labels proches de l'anglais obtiennent un score plus bas que ceux composés de lettres et de chiffres uniformément mélangés. PCAP Parser signale un nom comme Random-looking / long quand un label d'au moins 12 caractères a une entropie d'au moins 3,4 bits par caractère, ou quand le nom complet dépasse 60 caractères.
La capture d'exemple fictive de l'outil montre ce motif. Le poste demande deux noms qui échouent :
q3v9x7kz2m8w4t1r0p6y.info A NXDOMAIN
k7f2p9x4w1q8z3m6hd0s.top A NXDOMAIN
Les deux sont signalés comme aléatoires et rarement vus. Aucun n'a été résolu, donc aucune connexion n'a suivi, mais l'hôte qui les a émis devient une priorité.
Les algorithmes de génération de domaines
Certaines familles de logiciels malveillants calculent une liste de domaines candidats à partir d'une graine, souvent la date, et les essaient jusqu'à ce que l'un d'eux se résolve. MITRE ATT&CK décrit cela sous Dynamic Resolution: Domain Generation Algorithms (T1568.002). Dans le trafic, cela ressemble à l'exemple ci-dessus, à plus grande échelle : de nombreux noms aléatoires, surtout en NXDOMAIN, depuis un seul hôte, souvent à intervalles réguliers.
Indicateurs de tunnel DNS, vue d'ensemble
Le tunnel DNS détourne le protocole pour transporter des données : le client encode des données dans les labels de requêtes vers un domaine dont le serveur faisant autorité est contrôlé par l'autre partie, et le serveur répond avec des données encodées. MITRE ATT&CK classe le DNS parmi les canaux de commande et contrôle de la couche application sous T1071.004.
Du point de vue du défenseur, les indicateurs dans une capture sont :
- De nombreux sous-domaines uniques sous un même domaine enregistrable, chacun demandé une seule fois.
- Des labels et des noms longs, proches des limites de 63 et 255 octets, avec une forte entropie ou des alphabets de type hexadécimal ou base32.
- Des types d'enregistrement inhabituels en volume, comme des réponses
TXT,NULLouCNAMEportant de longues valeurs. - Volume et régularité : un flux constant de requêtes vers un domaine depuis un hôte, y compris quand l'utilisateur est inactif.
- Des tailles de requêtes et de réponses bien au-dessus de ce qu'envoie le reste du réseau.
Aucun de ces indicateurs n'est une preuve à lui seul. Le signal le plus fort, c'est plusieurs d'entre eux ensemble, pour un domaine, depuis un hôte.
Les faux positifs courants
- Les CDN et services cloud utilisent des noms d'hôtes longs et hachés pour la répartition de charge.
- Les services de sécurité et de réputation interrogent souvent, par conception, des empreintes ou des données encodées sous forme de noms DNS.
- Les navigateurs : Chromium sonde au démarrage des noms aléatoires à un seul label pour détecter le détournement DNS ; ils renvoient
NXDOMAINet ressemblent à du trafic DGA. - La découverte de services et les protocoles de noms locaux comme mDNS et LLMNR produisent des requêtes en diffusion ou multicast pour des noms locaux.
- La télémétrie des systèmes d'exploitation et des agents peut être fréquente et régulière.
Avant de conclure, vérifiez quel processus sur l'hôte a généré le trafic, à l'aide des journaux de l'hôte ou de l'EDR.
Limites des preuves DNS dans une capture
- Point de capture. Une capture prise en amont du résolveur récursif montre le résolveur qui interroge, pas le client.
- DNS chiffré. DoH et DoT cachent les noms ; seuls l'adresse du résolveur et les métadonnées TLS restent visibles.
- Cache. Des visites répétées pendant un TTL ne produisent aucune nouvelle requête.
- Snaplen et pertes. Des paquets tronqués ou perdus font disparaître des réponses. Vérifiez le snaplen de la capture et les éventuels avertissements.
Le faire dans le navigateur
La vue DNS de PCAP Parser liste chaque requête avec son type, son code de retour, ses réponses et son résolveur, signale les noms aléatoires et rarement vus, et verse chaque nom et chaque adresse dans la liste d'IOC, exportable en CSV ou JSON. Filtrez sur un domaine enregistrable pour voir tous ses sous-domaines d'un coup. La visite guidée explique les autres vues, et les empreintes JA3 et JA4 couvrent ce qu'il faut lire dans les sessions TLS qui suivent une résolution.
FAQ
Comment voir les requêtes DNS dans un fichier pcap ?
Ouvrez la capture dans un outil qui décode le DNS : Wireshark avec le filtre d'affichage dns, tshark avec -Y dns, ou une visionneuse dans le navigateur comme PCAP Parser, qui liste chaque requête avec son type, son code de retour et ses réponses dans une vue DNS.
Que signifient de nombreux NXDOMAIN ?
Beaucoup de noms inexistants peuvent venir de fautes de frappe, de logiciels mal configurés ou de suffixes de recherche obsolètes, mais une rafale de noms d'apparence aléatoire qui échouent tous est aussi un signe classique d'algorithme de génération de domaines qui essaie des candidats. Vérifiez quel processus et quel hôte les ont émis avant de conclure.
Peut-on détecter un tunnel DNS à partir d'une seule capture ?
On peut repérer des indicateurs : beaucoup de sous-domaines uniques, longs et d'apparence aléatoire sous un même domaine, des types d'enregistrement inhabituels comme TXT en volume, et une régularité dans le temps. Aucun ne prouve un tunnel à lui seul, et des services légitimes en produisent certains : confirmez avec des traces sur l'hôte.