Tunneling et exfiltration par DNS

La tunnelisation DNS encode des données arbitraires dans les requêtes et les réponses DNS, transformant le système de noms en canal de communication clandestin. Comme presque tous les réseaux autorisent le DNS à sortir du périmètre, il constitue une voie privilégiée pour l'exfiltration de données et le commandement et contrôle (C2).

Si votre pare-feu bloque tout, mais que le résolveur continue de répondre, les attaquants peuvent acheminer un canal bidirectionnel complet via le DNS.

L'attaquant contrôle le serveur de noms faisant autorité pour un domaine, par exemple tunnel.evil.com. L'implant encode les données sortantes dans le sous-domaine (étiquette de gauche) des requêtes :

• Les données sortent sous la forme <base32-chunk>.tunnel.evil.com.
• Le serveur faisant autorité renvoie des instructions dans des enregistrements TXT, CNAME ou NULL.

Chaque paire requête/réponse transporte un petit fragment de charge utile.

Les étiquettes DNS sont insensibles à la casse et leur longueur est limitée ; les données binaires sont donc généralement encodées en Base32 (Base64 mélange les majuscules et les minuscules et utilise des caractères incompatibles). Contraintes à respecter :

• Chaque étiquette peut contenir jusqu'à 63 caractères.
• Le nom complet peut contenir jusqu'à 255 caractères.
• Chaque requête ne transporte donc au maximum que quelques centaines d'octets.

Ce faible débit explique pourquoi l'exfiltration via DNS est lente et génère beaucoup de requêtes, ce qui la rend également détectable.

Différents types d'enregistrements permettent de maximiser la capacité en aval :

• TXT — grandes charges utiles en texte libre, principal support des réponses C2.
• NULL — octets bruts, utilisés par d'anciens outils comme iodine.
• CNAME / MX — capacité moyenne, se fondant dans le trafic légitime.
• A / AAAA — faible capacité, mais très courants et discrets.

Voici des utilitaires de tunnelisation connus que vous devez savoir reconnaître lors des détections :

• iodine — tunnel IP sur DNS utilisant des enregistrements NULL/TXT.
• dnscat2 — canal C2 chiffré via DNS.
• DNSExfiltrator — exfiltration de fichiers par étapes.
• Balise DNS de Cobalt Strike — courante dans les opérations des équipes rouges et les intrusions réelles.

Ces outils présentent des motifs de requêtes et des signatures d'entropie reconnaissables.

Les attaquants règlent le tunnel : un profil lent et discret envoie peu de requêtes par minute afin d'échapper aux seuils de volume ; il convient à l'exfiltration furtive de petits secrets comme des identifiants ou des clés.

Un profil à haut débit maximise le nombre de requêtes pour un C2 interactif ou un transfert massif, en sacrifiant la discrétion au profit de la vitesse. La logique de détection doit repérer ces deux extrêmes.

Les sous-domaines encodés ressemblent à des chaînes aléatoires et ont donc une entropie élevée par rapport aux noms de domaine naturels. Le calcul de l'entropie de Shannon pour chaque étiquette constitue une heuristique efficace.

Les noms légitimes tendent à être prononçables et à faible entropie ; xj4k9d2mq7zp1.tunnel.evil.com se démarque. Signalez les domaines dont l'entropie du sous-domaine dépasse un seuil ajusté.

Autres indicateurs comportementaux :

• Nombre de requêtes élevé vers un domaine unique depuis un même hôte.
• Noms de requête longs, proches de la limite de 255 octets.
• Utilisation disproportionnée des enregistrements TXT ou NULL.
• Nombreux sous-domaines uniques sous un même domaine parent (forte cardinalité).
• Requêtes vers un domaine récent ou à faible réputation.

Les terminaux ne doivent jamais communiquer directement avec le DNS sur Internet. Faites passer tous les clients par des résolveurs internes et bloquez le port 53 en sortie pour UDP/TCP au niveau du pare-feu.

Le DNS est ainsi acheminé par un point de contrôle centralisé où vous pouvez le journaliser, l'inspecter et appliquer des renseignements sur les menaces. Cela met également en échec les implants qui codent en dur des résolveurs externes comme 8.8.8.8.

Combinez les contrôles pour bloquer la tunnelisation :

• Centralisez la résolution et bloquez directement le port 53 externe.
• Déployez un pare-feu DNS / RPZ alimenté par des flux de réputation.
• Déclenchez des alertes sur l'entropie, la longueur des requêtes, le taux de NXDOMAIN et la cardinalité par domaine.
• Limitez le débit et plafonnez la taille des requêtes lorsque cela est possible.
• Surveillez le DNS via HTTPS vers des terminaux inconnus, car il dissimule la tunnelisation dans HTTPS.

Le DNS via HTTPS encapsule les requêtes dans TLS sur le port 443 ; la surveillance traditionnelle du port 53 ne voit donc rien. Un implant qui utilise le DNS via HTTPS vers un terminal malveillant peut faire transiter des données sans être détecté par la journalisation DNS passive.

Pour limiter ce risque, imposez l'utilisation d'un résolveur DNS via HTTPS approuvé, bloquez les adresses IP et les noms d'hôte publics connus de DNS via HTTPS sur les appareils gérés, et inspectez le SNI TLS ainsi que la réputation de la destination.

Testez vos réflexes de détection.

La tunnelisation DNS exploite les sous-domaines des requêtes et les enregistrements de réponse (TXT, NULL, CNAME) pour créer un canal clandestin d'exfiltration et de C2. Le débit est faible, ce qui la rend lente mais furtive. Des outils comme iodine et dnscat2 laissent des motifs reconnaissables.

Détectez-la grâce à l'analyse de l'entropie, de la longueur et du volume des requêtes ainsi que de la cardinalité ; empêchez-la au moyen de résolveurs centralisés, du filtrage sortant, de pare-feu DNS/RPZ et du contrôle du DNS via HTTPS. Prochaine étape : comment DNSSEC et le filtrage défendent l'ensemble du système de noms.