Détection du tunneling DNS : repérer les canaux C2 cachés dans le trafic DNS
Le tunneling DNS encapsule du C2 et de l’exfiltration dans des requêtes DNS anodines. Signaux, règles SIEM et enrichissement pour le détecter.
Le tunneling DNS reste l’un des canaux de commande et contrôle (C2) les plus discrets, car il détourne un protocole que presque aucune organisation ne bloque en sortie. Pour les équipes SOC, le détecter demande moins de nouveaux outils que de nouvelles questions posées aux logs DNS déjà collectés.
Pourquoi le DNS échappe aux contrôles classiques
Le port 53 est traité comme un service d’infrastructure, pas comme un canal applicatif à inspecter. La plupart des pare-feux et proxies laissent passer le DNS sans filtrage de contenu, parce que bloquer la résolution de noms casse immédiatement la navigation et les services internes.
Un tunnel DNS exploite exactement cette confiance : les données utiles — commandes C2, fragments de fichiers exfiltrés — sont encodées en base32/base64 dans le sous-domaine d’une requête (az4f9k2...malicious-domain.tld), ou dans le contenu d’une réponse via des enregistrements TXT, CNAME ou NULL. Le serveur autoritaire du domaine, contrôlé par l’attaquant, décode la requête et répond avec les instructions suivantes. Vu depuis le pare-feu, ce n’est qu’une résolution DNS de plus.
Les signaux qui trahissent un tunnel
Aucun indicateur isolé n’est suffisant, mais leur combinaison forme un profil de détection exploitable :
- Entropie des sous-domaines — les libellés encodés (base32/base64/hex) ont une distribution de caractères très différente d’un nom de domaine lisible ; une entropie de Shannon élevée sur le label le plus à gauche est un signal fort.
- Taux de NXDOMAIN anormal — certains outils de tunneling génèrent des sous-domaines uniques à chaque requête ; un domaine qui déclenche un volume inhabituel de réponses NXDOMAIN mérite un examen.
- Longueur et volume des requêtes — des sous-domaines proches de la limite de 63 caractères par label, et un nombre de requêtes par heure très supérieur à la moyenne pour un domaine donné, trahissent un transport de données plutôt qu’une résolution ponctuelle.
- Types d’enregistrements rares — un usage disproportionné de TXT, NULL ou CNAME par rapport à A/AAAA sur un même domaine, alors que ces types sont rarement dominants dans un trafic légitime.
- Régularité temporelle — un rythme de requêtes trop régulier (beaconing) évoque un agent automatisé plutôt qu’un utilisateur humain.
Le DNS passif comme preuve forensique
Une fois qu’un domaine suspect est identifié, l’historique DNS apporte le contexte que les logs temps réel ne donnent pas : depuis quand le domaine résout, vers quelles infrastructures, et si ces résolutions coïncident avec d’autres campagnes déjà documentées. Un domaine créé récemment, avec un historique de résolution instable vers des IP hébergées dans des ASN à forte rotation, renforce fortement la suspicion de tunneling. Le DNS history d’isMalicious permet de rejouer cet historique et de confirmer, ou d’infirmer, qu’un domaine a un usage cohérent avec un canal C2 plutôt qu’avec un service légitime.
Règles SIEM et corrélation avec une infrastructure connue
Une fois les signaux d’entropie, de volume et de type d’enregistrement instrumentés dans le SIEM, l’étape suivante consiste à corréler le domaine suspect avec une base de réputation. Un domaine qui déclenche déjà plusieurs signaux comportementaux, et qui est associé à une infrastructure connue comme malveillante, doit remonter en priorité au-dessus de la file d’alertes.
Quelques modèles de règles utiles :
- Seuil d’entropie + volume — alerte lorsqu’un domaine dépasse un seuil d’entropie moyenne sur ses labels ET génère plus de N requêtes/heure par hôte.
- Ratio NXDOMAIN — alerte lorsque le ratio de réponses NXDOMAIN pour un domaine dépasse un seuil sur une fenêtre glissante, un motif typique des outils générant un sous-domaine unique par paquet.
- Corrélation de réputation — enrichir chaque domaine candidat via l’analyse de domaine avant de créer un incident, pour distinguer un faux positif (CDN, télémétrie légitime) d’une infrastructure déjà signalée.
- Agrégation par hôte source — regrouper les alertes DNS par poste de travail ou serveur émetteur : un tunnel actif produit généralement un volume soutenu depuis un seul hôte compromis, pas une distribution homogène sur le parc.
Ces règles s’intègrent naturellement dans une solution SIEM qui centralise déjà les logs DNS, DHCP et proxy — le tunneling DNS se détecte rarement depuis une source unique, mais depuis la corrélation entre plusieurs journaux.
Enrichir et bloquer automatiquement les résolveurs suspects
La dernière étape consiste à fermer la boucle : dès qu’un domaine est confirmé comme vecteur de tunneling, il doit être poussé en blocage sans attendre une revue manuelle complète. En interrogeant l’API isMalicious depuis le pipeline de détection, une équipe SOC peut enrichir automatiquement chaque domaine candidat — réputation, historique DNS, âge d’enregistrement, association à des campagnes connues — et déclencher un blocage sur le resolver DNS ou le pare-feu dès que le score dépasse un seuil défini.
Cette automatisation réduit le temps entre la première requête suspecte et le blocage effectif, sans imposer une revue manuelle sur chaque alerte de faible confiance.
Pour les équipes SOC : la checklist opérationnelle
- Activer la journalisation complète des requêtes DNS (labels complets, type d’enregistrement, code de réponse) sur les resolvers internes.
- Déployer les règles de détection d’entropie et de ratio NXDOMAIN décrites ci-dessus dans votre solution SOC.
- Enrichir chaque domaine candidat via réputation et historique DNS avant escalade en incident.
- Automatiser le blocage des domaines confirmés via l’API, avec un log d’audit pour toute action automatisée.
- Revoir trimestriellement les seuils : les outils de tunneling évoluent, et un seuil figé perd en précision avec le temps.
Le tunneling DNS n’est pas une menace nouvelle, mais il reste efficace précisément parce que peu d’organisations instrumentent leurs logs DNS au niveau de détail nécessaire. Les équipes qui ferment cet angle mort gagnent une visibilité durable sur l’un des canaux d’exfiltration les plus discrets du paysage actuel.
Frequently asked questions
- Qu’est-ce que le tunneling DNS ?
- Le tunneling DNS consiste à encapsuler des données arbitraires — commandes C2, fichiers exfiltrés — dans des requêtes et réponses DNS (souvent des enregistrements TXT ou CNAME). Comme le DNS est presque toujours autorisé en sortie, ce canal contourne les pare-feux et proxies configurés pour filtrer HTTP(S) ou d’autres protocoles.
- Pourquoi le tunneling DNS échappe-t-il aux pare-feux classiques ?
- Les pare-feux traitent le port 53 comme un service d’infrastructure de confiance et l’autorisent par défaut, sans inspection de contenu approfondie. Un tunnel DNS bien conçu ressemble, requête par requête, à du trafic de résolution légitime, ce qui le rend invisible aux règles basées sur le port ou le protocole.
- Quel est le signal le plus fiable pour détecter un tunnel DNS ?
- Aucun signal seul ne suffit : c’est la combinaison qui compte. L’entropie élevée des sous-domaines, un volume anormal de requêtes vers un même domaine, un taux de NXDOMAIN élevé et des enregistrements TXT/NULL/CNAME inhabituels forment ensemble un profil de détection robuste, surtout corrélé à la réputation du domaine résolveur.
- Le DNS passif suffit-il à confirmer un tunneling DNS ?
- Le DNS passif est une preuve forensique essentielle — il montre l’historique de résolution, l’âge du domaine et la stabilité de l’infrastructure — mais il doit être croisé avec les logs DNS en temps réel de l’organisation pour confirmer un comportement de tunneling actif plutôt qu’un simple hébergement suspect.
Related articles
Jun 4, 2026SOC Alert Fatigue: How Threat Intelligence Reduces False Positives Without Hiding Real AttacksAlert fatigue is not a staffing problem alone. SOC teams need better evidence, source quality, confidence bands, and enrichment workflows that turn noisy alerts into defensible decisions.
May 24, 2026API CVE, dashboards et SIEM : automatiser la vulnérabilité sans perdre le contexteLes données CVE deviennent plus puissantes lorsqu’elles alimentent API, dashboards, SIEM, alerting et workflows de remédiation avec un contexte complet.
May 1, 2026SIEM and SOAR Threat Intelligence Enrichment: Workflows, Field Mapping, and the Metrics That Keep Teams SaneA SOAR playbook without enrichment is a ticket printer. A SIEM with unbounded threat feeds is a bill. Here is a practical way to design enrichment for Splunk, Sentinel, or Elastic-style stacks—what to store, when to run playbooks, and what to report upward.
Protect Your Infrastructure
Check any IP or domain against our threat intelligence database with indexed records.
Try the IP / Domain Checker