Qu'est-ce que le tunneling DNS ? Attaques, détection et prévention

Le système de noms de domaine (DNS) fait office d'annuaire fondamental d'Internet : il traduit les noms d'hôtes, compréhensibles par l'utilisateur, en adresses IP lisibles par les machines. Comme la quasi-totalité des applications réseau repose sur la résolution de noms, les entreprises autorisent systématiquement le trafic DNS sortant à travers leurs périmètres de sécurité, sans contrôle approfondi. Les pare-feu qui bloquent la navigation Web non autorisée, les transferts de fichiers et les connexions SSH laissent presque toujours le port 53 grand ouvert.

Les acteurs malveillants exploitent cette confiance par défaut. En acheminant des données non autorisées via des requêtes de recherche standard, un attaquant peut communiquer discrètement avec des hôtes internes et détourner de la propriété intellectuelle sans établir de connexion TCP directe. Il est essentiel de bien comprendre ces canaux cachés, ainsi que les vulnérabilités plus générales du DNS, pour mettre en place une défense d'entreprise résiliente.

Qu'est-ce que le tunneling DNS ?

Le « tunneling DNS » est une technique de cyberattaque qui consiste à intégrer des programmes non liés au DNS, des charges utiles de données ou des commandes à distance dans des requêtes et réponses DNS standard. Étant donné que les résolveurs récursifs acheminent systématiquement ces requêtes au-delà des périmètres réseau, les attaquants peuvent établir un canal de communication bidirectionnel stable qui contourne complètement les pare-feu de périmètre, les proxys réseau et les filtres de contenu.

De manière générale, cette faille de sécurité repose sur des requêtes émises par des clients et dirigées vers un domaine contrôlé par un attaquant. Lorsqu’un logiciel compromis doit transmettre des données, il les intègre dans l’étiquette de sous-domaine d’une requête. Les résolveurs récursifs transmettent la requête en amont jusqu’à ce qu’elle atteigne le serveur faisant autorité de l’attaquant, qui extrait la charge utile et renvoie des instructions intégrées dans des enregistrements de réponse DNS standard.

Comment fonctionne une attaque par tunneling DNS ?

La mise en place d'un tunnel DNS ne nécessite pas de compromettre les résolveurs récursifs de l'entreprise ni d'altérer les serveurs racines DNS principaux. Elle repose plutôt sur les mécanismes standard de routage DNS, selon le cycle de vie suivant :

1. Préparation de l'infrastructure : le pirate enregistre un nom de domaine public (tel que attacker-c2.net) et configure un serveur de noms faisant autorité, qu'il contrôle, afin de traiter toutes les requêtes concernant ce domaine et ses sous-domaines.

2. Diffusion de la charge utile : un terminal interne est compromis par hameçonnage, exploitation d’une faille logicielle ou altération de la chaîne d’approvisionnement. Le logiciel malveillant exécuté sur ce terminal contient une logique spécialement conçue pour encapsuler des données locales dans des étiquettes conformes au protocole DNS.

3. Encodage et segmentation des données : les normes du protocole DNS (RFC 1035) limitant la longueur des étiquettes de domaine à 63 caractères et celle des noms de domaine complets à 253 caractères, le logiciel malveillant fragmente les grands ensembles de données en petits blocs. Il encode chaque bloc à l’aide de formats tels que Base32 ou hexadécimal, puis ajoute le résultat sous forme de sous-domaine (par exemple, 4d616c6963696f7573.data.attacker-c2.net). Le format Base32 est souvent choisi car les requêtes DNS ne font pas la distinction entre majuscules et minuscules.

4. Résolution récursive : le terminal lance une requête DNS standard. Comme la machine est configurée pour utiliser le résolveur DNS interne de l’entreprise, la requête est d’abord transmise au serveur de l’entreprise. Ce dernier, constatant qu’il s’agit d’une requête courante, détermine qu’il ne dispose pas de l’enregistrement en cache et transfère la requête via la hiérarchie DNS mondiale.

5. Extraction de la charge utile : la requête parvient finalement au serveur de noms de référence de l'attaquant. Au lieu de fournir une adresse IP valide correspondant à l'hébergement du site web, le serveur de l'attaquant supprime le nom de domaine parent, extrait la chaîne de caractères codée correspondant au sous-domaine, puis reconstitue les données d'origine.

6. Transmission de commandes via les réponses : pour renvoyer des commandes vers le réseau de l’entreprise, le serveur de référence génère un enregistrement de réponse. Les attaquants utilisent souvent des enregistrements TXT, car ceux-ci peuvent contenir jusqu’à 255 caractères par chaîne, ou encore des enregistrements CNAME et NULL. Lorsque le résolveur de l’entreprise renvoie la réponse à l’hôte infecté, le logiciel malveillant client extrait la charge utile et exécute les instructions de l’opérateur.

Tout au long de cet échange, le terminal infecté n'établit jamais de connexion réseau directe avec l'infrastructure de l'attaquant. Chaque octet transite sans encombre par les serveurs DNS légitimes de l'entreprise.

À quoi sert le tunneling DNS pour les pirates ?

Alors que les administrateurs réseau ont parfois recours à des outils de tunneling à des fins de diagnostic, les cybercriminels exploitent cette technique à plusieurs étapes cruciales de la chaîne d'attaque cybernétique.

Exfiltration de données

L'exfiltration de données constitue l'objectif le plus courant du tunneling DNS. Lorsque des attaquants compromettent des systèmes contenant des données de paiement, des identifiants ou du code source propriétaire, l'accès Web sortant est souvent soumis à un filtrage ou à une inspection rigoureux par des proxys de prévention des pertes de données (DLP).

En fragmentant les données sensibles en éléments sérialisés et en les transmettant via des requêtes vers des sous-domaines, les logiciels malveillants peuvent acheminer progressivement des gigaoctets d'informations sans jamais ouvrir de session HTTP ou FTP.

Commande et contrôle (C2)

Une fois qu'un logiciel malveillant a pris pied dans le système, il a besoin d'un canal fiable pour recevoir les instructions de ses opérateurs. Les attaquants déploient souvent des utilitaires de tunneling tels que « iodine » ou « dnscat2 » comme canaux de secours lorsque les connexions HTTPS principales sont interrompues. Les équipes de sécurité doivent être en mesure de reconnaître les signatures de ces outils lors de la gestion des incidents.

Grâce à des tunnels DNS bidirectionnels, les opérateurs peuvent émettre des commandes administratives, télécharger des modules malveillants secondaires et coordonner des mouvements latéraux au cœur même de réseaux segmentés.

Contourner les contrôles réseau et les portails captifs

Dans les environnements restreints tels que les réseaux Wi-Fi d'hôtels, les points d'accès dans les aéroports ou les VLAN d'entreprise isolés réservés aux invités, les commutateurs réseau bloquent généralement tout le trafic Web sortant jusqu'à ce qu'un utilisateur ait terminé son authentification sur un portail captif.

Toutefois, pour que la page d'accueil puisse être résolue, le réseau doit autoriser les requêtes DNS sur le port 53. Les attaquants et les utilisateurs non autorisés exploitent les tunnels DNS pour acheminer du trafic Internet sans restriction via ces résolveurs ouverts, contournant ainsi les barrières de facturation captives et les contrôles d'isolation du réseau.

Exemples concrets d'attaques par tunneling DNS

Le tunneling DNS est loin d'être un concept purement théorique. Des groupes malveillants sophistiqués et des acteurs étatiques ont, à maintes reprises, intégré les communications DNS dans des campagnes cybernétiques de grande envergure.

1. SUNBURST (Attaque contre la chaîne d'approvisionnement de SolarWinds)

L'une des attaques les plus graves jamais enregistrées dans l'histoire de la cybersécurité, visant la chaîne d'approvisionnement, reposait en grande partie sur une signalisation via le DNS. Dans le cas de la porte dérobée SUNBURST, diffusée par le biais de mises à jour malveillantes du logiciel SolarWinds Orion, le logiciel malveillant communiquait avec les auteurs de la menace à l'aide de sous-domaines dynamiques hébergés sur avsvmcloud.com.

La porte dérobée collectait des informations de base sur l'hôte, encodait les données sous forme de chaînes alphanumériques et les ajoutait en tête des requêtes de recherche en tant que sous-domaines. Lorsque les serveurs de noms faisant autorité, contrôlés par les attaquants, recevaient ces requêtes, ils répondaient par des enregistrements CNAME pointant vers des serveurs de commande secondaires ou des plages d'adresses IP spécifiques, qui ordonnaient à la porte dérobée de se mettre en veille, de s'arrêter ou d'activer des canaux HTTP secondaires. L'ensemble des techniques opérationnelles utilisées est documenté dans l'avis AA20-352A de la CISA.

2. Portes dérobées DNS d'OilRig (APT34)

Le groupe malveillant iranien soutenu par l'État, connu sous le nom d'OilRig (APT34), a systématiquement exploité le tunneling DNS à des fins d'émission de commandes et d'exfiltration de données. Dans le cadre de multiples campagnes ciblant des entités des secteurs de l'énergie, de la finance et du gouvernement, OilRig a déployé des familles de logiciels malveillants sur mesure telles que ALMA Communicator, DNSpionage et Saitama.

Ces implants surveillent les machines des victimes, extraient des fichiers sensibles et organisent les données sous forme de requêtes DNS à haut débit dirigées vers des serveurs de noms contrôlés par les attaquants. Si les protocoles de communication standard échouent ou si les pare-feu coupent les canaux Web, le logiciel malveillant recourt automatiquement au tunneling DNS pour préserver sa persistance et le contrôle administratif.

Comment détecter le tunneling DNS

Étant donné que les réseaux légitimes traitent quotidiennement des millions de transactions DNS, l'identification des tunnels malveillants nécessite d'analyser à la fois les caractéristiques de chaque requête et les tendances générales du trafic. Les stratégies de détection relèvent généralement de deux domaines principaux : l'analyse de la charge utile et l'analyse du trafic.

Analyse de la charge utile

L'analyse de la charge utile consiste à examiner les chaînes de caractères, les structures et les enregistrements de ressources spécifiques contenus dans chaque requête et réponse DNS.

• Longueur et structure des sous-domaines : les sous-domaines standard sont généralement courts et faciles à lire, comme par exemple mail.entreprise.com ou api.interne.local. Le « tunneling » des requêtes optimise le transfert de données en regroupant de longues chaînes codées au sein de sous-domaines, ce qui les rapproche souvent de la limite de 63 caractères imposée aux étiquettes.
• Entropie de l'information : les chaînes de caractères chiffrées ou codées présentent une entropie statistique (caractère aléatoire) élevée par rapport aux mots du langage naturel. Les plateformes d'analyse de sécurité évaluent la répartition des caractères ; les chaînes présentant des variations anormales de caractères, des motifs alphanumériques répétitifs ou des structures vocaliques manquantes indiquent clairement un codage des données.
• Types d'enregistrements inhabituels : le trafic professionnel classique utilise principalement des enregistrements A, AAAA, MX et, occasionnellement, des enregistrements CNAME. Un afflux soudain de requêtes portant sur des enregistrements TXT (qui contiennent des chaînes de caractères volumineuses), des enregistrements NULL (qui contiennent des blocs binaires arbitraires) ou des enregistrements SRV provenant de points d'extrémité qui n'hébergent pas de services réseau est le signe d'une utilisation abusive du protocole.
• Jeux de caractères non standard : les requêtes contenant des caractères de remplissage Base32, des séquences hexadécimales ou des distributions de symboles inhabituelles doivent faire l'objet d'une attention particulière et d'une analyse immédiate. quarantine

Analyse du trafic

L'analyse du trafic examine les tendances globales des requêtes au fil du temps, permettant ainsi de détecter des comportements opérationnels anormaux, même lorsque les requêtes individuelles semblent inoffensives.

• Volume anormal de requêtes vers un domaine spécifique : l'utilisation légitime du DNS tire parti de la mise en cache. Une fois qu'un hôte a résolu example.com, le résolveur récursif met en cache l'enregistrement pendant toute la durée de sa durée de vie (TTL), ce qui évite les requêtes externes identiques. Les tunnels DNS génèrent un flux continu de requêtes, car chaque élément de données exfiltré nécessite un sous-domaine unique et entièrement nouveau qui ne peut pas être fourni à partir du cache.
• Taux élevé de noms de domaine complets (FQDN) : le fait d'observer, en l'espace d'une heure, des milliers de sous-domaines uniques se résolvant sous un seul domaine de niveau supérieur constitue un indicateur fiable de l'existence d'un tunnel actif.
• Domaines nouvellement enregistrés (NRD) : les acteurs malveillants alternent régulièrement entre des domaines éphémères afin de contourner les listes de blocage basées sur la réputation statique. Les requêtes dirigées vers des domaines créés au cours des dernières 24 à 72 heures doivent donner lieu à une inspection renforcée.
• Connexions sortantes directes vers le port 53 : dans une architecture d'entreprise sécurisée, les postes de travail standard des utilisateurs ne doivent communiquer qu'avec des résolveurs internes désignés. Tout poste de travail qui tente d'envoyer des requêtes DNS directement à des résolveurs publics externes (tels que 8.8.8.8 ou 1.1.1.1) cherche souvent à contourner la surveillance interne.

Outils et technologies utiles

Pour détecter le tunneling DNS à grande échelle, il faut disposer d'outils de défense spécialement conçus à cet effet :

• Plateformes DNS protectrices (PDNS) : les services PDNS dans le cloud et hybrides se situent entre les résolveurs internes et l'Internet au sens large ; ils exploitent des informations sur les menaces en temps réel et des modèles comportementaux pour intercepter les requêtes malveillantes avant que la résolution ne soit effective.
• Détection et réponse réseau (NDR) : les outils NDR modernes inspectent de manière passive les segments de réseau, identifiant les sous-domaines à forte entropie et les tunnels de protocole à l'aide de modèles d'apprentissage automatique, sans introduire de latence.
• Gestion des informations et des événements de sécurité (SIEM) : en transmettant les journaux de débogage des résolveurs DNS internes à un système SIEM, les équipes d'ingénierie peuvent configurer des règles de corrélation qui signalent les terminaux générant un nombre anormalement élevé de requêtes de domaines uniques.
• Surveillance unifiée de la sécurité DNS : une défense efficace ne se limite pas à l'inspection du trafic sortant ; elle nécessite également de surveiller les zones faisant autorité afin de s'assurer que les acteurs malveillants n'ont pas manipulé les enregistrements de l'entreprise. Des solutions complètes de surveillance de la sécurité DNS aident les entreprises à détecter les modifications apportées aux enregistrements, les changements non autorisés au niveau de l'infrastructure et les lacunes en matière de conformité sur l'ensemble de leurs domaines publics.

La solution complète de surveillance de la sécurité DNS de PowerDMARC aide les entreprises à détecter les modifications d'enregistrements, les changements non autorisés apportés à l'infrastructure et les lacunes en matière de conformité sur l'ensemble de leurs domaines publics. Cette surveillance proactive garantit que vos zones DNS de référence restent protégées contre toute manipulation, tout en offrant la visibilité approfondie nécessaire pour repérer les abus de protocole dissimulés.

Comment empêcher le tunneling DNS

La détection des tunnels est essentielle, mais des contrôles proactifs au niveau de l'architecture réseau permettent de bloquer de nombreuses tentatives de création de tunnels avant même que les données ne quittent l'environnement. Les équipes de sécurité doivent mettre en œuvre les mesures de renforcement suivantes :

• Restriction du routage DNS sortant : configurez les pare-feu périmétriques de manière à bloquer tout trafic UDP et TCP sortant sur le port 53 provenant de terminaux standard. Seuls les résolveurs DNS internes désignés et renforcés doivent être autorisés à établir des connexions sortantes vers Internet.
• Limiter les protocoles DoH et DoT non approuvés : les acteurs malveillants ont de plus en plus recours au DNS sur HTTPS (DoH) ou au DNS sur TLS (DoT) pour dissimuler leurs requêtes au sein du trafic Web chiffré. Bloquez les connexions sortantes vers les adresses IP publiques connues de résolveurs DoH/DoT et appliquez des politiques de proxy d'entreprise imposant l'inspection des certificats en interne.
• Déployer le filtrage DNS et les flux de renseignements sur les menaces : intégrer des flux dynamiques de renseignements sur les menaces dans les résolveurs d'entreprise. Des listes noires très fiables rejettent immédiatement les requêtes ciblant des domaines associés à des campagnes de logiciels malveillants récemment identifiées, à des fournisseurs de DNS dynamiques ou à des infrastructures C2 actives.
• Mettre en place le « sinkholing » DNS : lorsque les résolveurs récursifs détectent des requêtes concernant des domaines malveillants connus, le « sinkholing » redirige la requête vers une adresse IP factice interne et non routable. Cela neutralise l'attaque et alerte immédiatement le personnel de sécurité quant à la présence d'un hôte interne infecté.
• Appliquer le principe du « moindre privilège » sur les terminaux : les scripts et utilitaires de tunneling malveillants nécessitent des privilèges d’exécution locaux pour manipuler les sockets réseau ou exécuter des services en arrière-plan. Limiter les droits d’administration, mettre en place une liste blanche d’applications et déployer des agents modernes de détection et de réponse sur les terminaux (EDR) empêche d’emblée l’exécution de code malveillant.
• Mettez en œuvre une hygiène DNS complète : veillez à ce que tous les logiciels DNS soient mis à jour pour corriger les vulnérabilités connues et vérifiez régulièrement les configurations conformément aux meilleures pratiques établies en matière de sécurité DNS.

Le tunneling DNS par rapport aux autres attaques DNS

Le système de noms de domaine (DNS) présentant des vulnérabilités à plusieurs niveaux architecturaux, les équipes de sécurité confondent souvent le « tunneling » avec d'autres formes de manipulation du DNS. Le tableau suivant met en évidence les différences opérationnelles :

Pour en savoir plus sur les menaces pesant sur l'infrastructure de résolution des noms, consultez notre guide consacré aux différents types d'attaques DNS.

Foire aux questions

Le tunneling DNS est-il illégal ?

Oui, l'utilisation du tunneling DNS pour exfiltrer des données sans autorisation, déployer des logiciels malveillants ou établir un accès clandestin à un réseau d'entreprise sans autorisation explicite est illégale et enfreint les lois relatives à la cybercriminalité en vigueur dans le monde entier, telles que la loi américaine sur la fraude et les abus informatiques (Computer Fraud and Abuse Act, CFAA).

Un pare-feu classique peut-il bloquer le tunneling DNS ?

Les pare-feu classiques bloquent rarement le tunneling DNS de manière autonome. En effet, comme ils se contentent de vérifier les règles relatives à la source, à la destination et au port (autorisant le trafic UDP/TCP sur le port 53), ils traitent les requêtes de tunneling comme de simples recherches de noms. Pour bloquer le tunneling, il faut recourir à des pare-feu de nouvelle génération (NGFW), à l'inspection approfondie des paquets (DPI) ou à des services DNS protecteurs dédiés qui évaluent l'entropie de la charge utile, la fréquence des requêtes et la réputation du domaine.

Le protocole DNS sur HTTPS (DoH) rend-il le tunneling plus difficile à détecter ?

Oui. Le protocole DNS sur HTTPS (DoH) chiffre les requêtes et les réponses au sein de sessions TLS standard sur le port 443, rendant ainsi le trafic DNS impossible à distinguer d’une navigation Web HTTPS chiffrée classique. Lorsqu’un logiciel malveillant utilise le protocole DoH pour accéder à des résolveurs publics externes, les outils traditionnels de surveillance du réseau ne peuvent pas inspecter les sous-domaines ni le contenu de la charge utile sans recourir à des proxys de déchiffrement TLS actifs. Il est donc essentiel de bloquer les connexions DoH sortantes directes vers des résolveurs publics non autorisés.

Quelle est la différence entre le tunneling DNS et l'exfiltration DNS ?

L'exfiltration DNS est un objectif spécifique, tandis que le tunneling DNS est un mécanisme de transport plus général. L'exfiltration DNS désigne strictement la transmission vers l'extérieur et le vol de données sensibles par le biais de requêtes DNS. En revanche, le tunneling DNS peut également être bidirectionnel : il permet d'établir des shells interactifs de commande et de contrôle, de transmettre des commandes entrantes provenant des opérateurs et d'acheminer le trafic IP général à travers des réseaux soumis à des restrictions.

Conclusion et prochaines étapes

Le DNS reste un protocole essentiel dont les entreprises modernes ne peuvent pas se passer. Malheureusement, sa portée universelle et le traitement peu restrictif dont il fait l'objet au niveau des pare-feu garantissent que les attaquants continueront à l'utiliser comme porte dérobée pour s'emparer de propriété intellectuelle sensible et conserver un accès permanent. Pour lutter contre le tunneling DNS, il faut disposer d'une visibilité continue sur le réseau, d'un filtrage robuste des sorties sur le port 53 et d'une inspection automatisée capable de détecter en temps réel tout comportement anormal au niveau des requêtes.

Pour protéger le réseau de votre organisation, il faut tout d’abord connaître l’état actuel de votre surface d’attaque externe. Outre la surveillance des modèles de requêtes sortantes, les entreprises doivent s’assurer que leur infrastructure de domaines accessibles au public et leurs protocoles d’authentification des e-mails sont entièrement protégés contre l’usurpation d’identité, la modification non autorisée des enregistrements et les erreurs de configuration. Utilisez l’analyseur de domaine gratuit de PowerDMARC pour évaluer immédiatement l’état de santé de votre domaine, vérifier la conformité aux normes «SPF » et DMARC, et détecter les failles de sécurité avant que les attaquants ne puissent en tirer parti.