DNSTunnelDetector : détection temps réel des tunnels DNS/C2

DNSTunnelDetector est un détecteur Python open source publié sur le portfolio github de Ayi Nedjimi. Il analyse passivement les flux DNS, qu'ils proviennent d'un capteur Zeek, d'un fichier pcap, d'un journal Suricata ou d'un export Cloudflare Resolver, afin d'identifier en temps réel les tunnels DNS et les beacons command and control qui réutilisent ce protocole. L'outil combine plusieurs heuristiques statistiques : entropie de Shannon sur les labels, longueur cumulée de subdomain, fréquence d'interrogation, ratio de requêtes TXT et NULL, dispersion temporelle. Il sait reconnaître les patrons de Iodine, dnscat2, DNSCat-Powershell, Cobalt Strike Malleable C2 DNS, NimDNScat et plusieurs implants APT documentés par MITRE. Les alertes produites sont normalisées en ECS et ingérables dans n'importe quel SIEM. L'objectif est de fournir aux analystes SOC un compagnon spécialisé pour une menace persistante et coûteuse à débusquer.

Pourquoi un détecteur dédié au tunneling DNS

Le DNS est le protocole le plus difficile à inspecter du SI moderne. Il est ouvert sur quasiment tous les périmètres, son débit est généralement non limité et son contenu reste opaque pour les pare-feu classiques. Les attaquants l'utilisent depuis vingt ans pour exfiltrer des données et maintenir un canal de commande furtif. Les outils Iodine et dnscat2, devenus standards offensifs, sont désormais accompagnés de modules natifs dans Cobalt Strike, dans Sliver et dans plusieurs implants d'APT documentés par les agences nationales.

Les solutions DNS Security commerciales fournissent une partie de la réponse mais elles s'appuient majoritairement sur des listes de domaines connus malveillants, ce qui les rend aveugles aux campagnes neuves. DNSTunnelDetector adopte au contraire une approche comportementale : il n'a pas besoin de connaître le domaine pour comprendre qu'un flux DNS est anormal. C'est ce qui le rend complémentaire des solutions de threat intelligence et précieux pour les équipes de threat hunting.

À quoi sert DNSTunnelDetector

L'outil répond à trois cas d'usage principaux. Premier cas, la détection en temps réel sur un capteur réseau ou sur un résolveur récursif. Le module streaming ingère les requêtes au fil de l'eau et publie une alerte dès qu'un client franchit les seuils combinés d'entropie, de longueur et de fréquence. Deuxième cas, l'analyse forensique sur pcap ou sur journal historique. L'outil produit un rapport synthétique listant les couples client-domaine suspects, classés par score de tunnel. Troisième cas, l'enrichissement d'un SIEM existant. Les alertes ECS s'ajoutent aux signaux du SIEM et permettent à l'analyste de prioriser les enquêtes.

Architecture interne et features de détection

Le moteur d'analyse repose sur cinq familles de features extraites pour chaque tuple client source, domaine parent. La première famille concerne l'entropie de Shannon calculée sur les labels du sous-domaine. Un tunnel DNS classique encode du base32 ou du base64, ce qui produit une entropie supérieure à 4,5 bits par caractère, là où un nom de domaine légitime tourne autour de 3 à 3,8 bits.

La deuxième famille étudie la longueur cumulée du subdomain. Les tunnels poussent typiquement entre 80 et 200 caractères par requête pour maximiser le débit. La distribution des longueurs sur un domaine légitime est nettement plus resserrée autour de 10 à 30 caractères.

La troisième famille mesure la fréquence d'interrogation. Un client web ouvre une trentaine de domaines distincts par minute en moyenne mais avec une dispersion temporelle élevée. Un tunnel DNS ouvre quelques dizaines de requêtes vers un domaine unique avec une régularité quasi métronomique, signature caractéristique d'un beacon.

La quatrième famille analyse la distribution des types de requêtes. Un trafic légitime majoritairement composé de A et AAAA avec quelques HTTPS pour les navigateurs Chromium récents. Un tunnel privilégie souvent TXT, NULL ou CNAME pour faire passer plus de données par réponse. L'outil suit également les types rares comme MX ou SOA appelés répétitivement.

La cinquième famille s'intéresse au beaconing temporel. L'algorithme calcule la transformée de Fourier discrète des intervalles entre requêtes pour détecter les périodicités cachées, signature des implants programmés pour appeler toutes les N secondes avec ou sans jitter.

Cas d'usage concrets

Un opérateur d'infrastructure critique a déployé DNSTunnelDetector en aval de ses résolveurs internes pour compléter sa solution DNS security commerciale. En trois semaines, l'outil a identifié un poste sur lequel un assistant développeur installait sans le savoir un add-on VSCode malveillant qui exfiltrait du contenu via un sous-domaine généré aléatoirement. Aucune signature n'existait alors.

Une équipe red team interne a validé la couverture du SOC en exécutant un payload dnscat2 sur un poste isolé. DNSTunnelDetector a remonté l'alerte en moins de quarante secondes, là où la solution commerciale a mis plus de quatre heures avant de classer le domaine comme suspect après corrélation externe.

Un CERT régional intègre l'outil dans sa boîte à outils d'intervention. Lors de l'arrivée chez un adhérent compromis, l'analyste lance DNSTunnelDetector sur les pcap de bordure et obtient en quelques minutes une liste priorisée de domaines à investiguer plus profondément.

Un éditeur SaaS utilise l'outil pour surveiller les comportements DNS de ses propres serveurs cloud. La détection a notamment révélé qu'une bibliothèque tierce embarquée par négligence dans un conteneur effectuait des requêtes DNS répétitives vers un domaine de télémétrie non documenté. L'éditeur a pu retirer la dépendance et préserver la confiance de ses clients.

Enfin, un chasseur de menaces freelance utilise DNSTunnelDetector comme bibliothèque Python pour ses propres notebooks Jupyter d'investigation. Le module se branche naturellement sur un dataframe Pandas, ce qui facilite l'exploration interactive lors d'un incident.

Installation rapide

L'outil tourne sur Python 3.11 et plus. L'installation est volontairement minimale pour permettre un déploiement rapide même sur un poste forensique transitoire.

git clone https://exemple.local/dnstunneldetector.git
cd dnstunneldetector
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
# Analyse offline sur pcap
python3 -m dtd.cli analyze --pcap capture.pcap --out alerts.ndjson
# Streaming live sur Zeek
python3 -m dtd.cli stream --zeek-log /opt/zeek/logs/current/dns.log --siem wazuh

Pour un déploiement permanent, un container Docker prêt à l'emploi est fourni avec un volume de configuration. L'outil consomme typiquement moins de 200 Mo de RAM pour un débit de 10 000 requêtes DNS par seconde.

Intégration avec les SIEM et les capteurs réseau

DNSTunnelDetector se branche en aval d'un capteur Zeek, d'un Suricata avec sortie EVE JSON ou d'un export Cloudflare 1.1.1.1 for Teams. Côté sortie, les alertes sont publiables vers un endpoint Wazuh active response, vers une API Elastic Bulk, vers Splunk HEC et vers Microsoft Sentinel Log Analytics. Un fichier d'exemple Logstash et un modèle de table Sentinel sont inclus dans le dépôt.

L'outil produit également un score de risque continu par client interne. Ce score est exposé via une API REST locale et peut alimenter un dashboard Grafana ou un module de réaction automatique sur le pare-feu. Plusieurs intégrations communautaires existent déjà pour pfSense, OPNsense et Fortinet FortiGate.

Comparaison avec les autres outils du marché

Trois familles d'outils traitent la détection de tunneling DNS. Première famille, les solutions commerciales type Cisco Umbrella, Infoblox BloxOne Threat Defense et Akamai DNS Security. Elles s'appuient principalement sur la threat intelligence externe et apportent de la valeur sur les campagnes connues. Deuxième famille, les analyseurs académiques type DNSExfil, dnstweak et helminth analyzer. Ils sont précis mais difficilement déployables en production. Troisième famille, les modules intégrés à Zeek ou à Suricata, efficaces mais limités à un nombre restreint d'heuristiques.

DNSTunnelDetector se positionne entre l'académique et l'industriel : rigoureux dans ses calculs, robuste dans son intégration, exigeant peu de tuning initial. Il n'a pas vocation à remplacer une suite DNS security d'entreprise, mais il offre un filet de sécurité que beaucoup d'organisations négligent encore.

Tuning, allowlist et observabilité

La phase la plus importante après installation est la calibration. L'outil propose un mode learn qui observe le trafic pendant 24 à 72 heures et construit automatiquement une baseline par client. Cette baseline alimente une allowlist dynamique distinguant les domaines à forte cardinalité légitimes des candidats potentiels au tunneling. Les analystes peuvent ensuite affiner les seuils par groupe d'actifs : stations de travail, serveurs, IoT, OT, postes invités. Cette granularité évite la tentation de baisser globalement la sensibilité, ce qui ouvrirait une porte aux attaquants malins.

L'outil expose des métriques Prometheus pour suivre le volume de requêtes analysées, le nombre d'alertes, la distribution des scores et la latence du moteur. Un dashboard Grafana de référence est fourni dans le dépôt. Il permet aux équipes infrastructure de monitorer la santé du détecteur en même temps que la posture DNS de l'organisation.

Limites et roadmap

Les limites principales sont liées à la nature même de la détection comportementale. Les tunnels lents conçus pour rester sous le radar peuvent partiellement échapper aux seuils par défaut. L'outil compense par un mode supervised qui permet à l'analyste de remonter manuellement la sensibilité pour un client spécifique. Les domaines CDN à forte cardinalité comme certains services Microsoft 365 produisent par construction des sous-domaines longs et entropiques. Une allowlist embarquée mitige le problème mais demande de la maintenance.

Un autre angle mort concerne les tunnels qui utilisent des résolveurs publics chiffrés DoH externes type Cloudflare 1.1.1.1 ou Google 8.8.8.8 sans passer par le résolveur interne. Dans ce cas, la visibilité passe par les métadonnées TLS et par la détection des connexions sortantes vers ces résolveurs depuis des clients qui devraient utiliser le résolveur interne. L'outil produit alors une alerte de policy violation plutôt qu'une détection de tunnel mais le résultat opérationnel est équivalent : l'analyste est informé d'un canal sortant non maîtrisé.

La roadmap est articulée autour de quatre axes. Premier axe, ajout d'un modèle gradient boosting entraîné sur les features statistiques pour calibrer un score global plus précis. Deuxième axe, support natif des journaux DNS over HTTPS produits par les résolveurs récursifs DoH locaux. Troisième axe, détection des canaux DoT chiffrés via analyse des métadonnées TLS. Quatrième axe, publication d'un dataset annoté multi-millions de requêtes pour la communauté académique. Un module additionnel d'enrichissement passive DNS via SecurityTrails ou DomainTools est également étudié pour ajouter une couche de contexte sur l'âge et la réputation des domaines suspects identifiés.

FAQ

DNSTunnelDetector fonctionne-t-il sur du DNS chiffré DoH ou DoT ?

Pas directement, puisque le contenu DNS est chiffré. En revanche, si la couche TLS aboutit chez un résolveur interne contrôlé par l'organisation, les journaux post-déchiffrement sont consommables par l'outil. Pour le DoH externe, seule l'analyse des métadonnées de flux TLS reste possible, ce qui constitue un axe de roadmap.

L'outil produit-il beaucoup de faux positifs sur les domaines CDN ?

Sans tuning initial, oui. Une allowlist communautaire couvrant les principaux CDN, Microsoft 365, Apple Push et les services Cloudflare est fournie dès la première version. L'analyste peut compléter cette allowlist en quelques minutes pour son environnement. L'objectif est de viser moins d'une alerte par jour et par 100 postes après calibration.

Faut-il déployer un agent sur les postes pour détecter un tunnel ?

Non. L'outil est entièrement passif. Il consomme les flux DNS existants depuis le résolveur, depuis un capteur réseau ou depuis un export cloud. Aucun agent n'est requis sur les endpoints, ce qui simplifie le déploiement et préserve la confidentialité.

Comment l'outil distingue-t-il dnscat2 d'un beacon Cobalt Strike DNS ?

Par la signature combinée des features. dnscat2 utilise massivement les requêtes TXT et un padding spécifique en début de label. Cobalt Strike avec un profil Malleable C2 DNS varie le nom d'hôte selon un schéma documenté et applique un jitter caractéristique. L'outil n'a pas besoin de nommer l'attaquant : il signale un tunnel DNS et laisse l'analyste qualifier la famille.

Pour aller plus loin

Le code et la documentation de DNSTunnelDetector sont accessibles via le portfolio /github du compte Ayi Nedjimi. Pour contextualiser la menace, consultez l'analyse attaques DNS, tunneling, hijacking et empoisonnement, l'étude exfiltration furtive via DNS et DoH, l'article détection des frameworks C2 Mythic, Havoc et Sliver et le guide déploiement Wazuh SIEM/XDR open source pour la corrélation côté SOC.

Conclusion

Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.