Tunneling DNS.

Le tunneling DNS exploite le fait que le trafic DNS (UDP/TCP port 53) est presque toujours autorise et rarement inspecte en profondeur. Le malware encode les octets de sa charge dans des labels de sous-domaine (par exemple des morceaux base32 sous attacker.example.com) et le serveur autoritaire de l'attaquant repond avec des enregistrements TXT, CNAME, NULL ou A portant la reponse ou les commandes. Comme la resolution est recursive, les donnees sortent meme lorsque l'hote ne peut joindre qu'un resolveur interne et ne touche jamais directement l'IP de l'attaquant. Des outils comme dnscat2, Iodine et le C2 DNS de Cobalt Strike mettent en oeuvre ce schema ; le debit est faible mais furtif.

Des campagnes reelles s'appuient dessus. La porte derobee SUNBURST de 2020 dans SolarWinds Orion utilisait un algorithme de generation de domaines pour construire des sous-domaines de avsvmcloud.com, puis encodait le domaine Active Directory interne de la victime et la liste des produits de securite installes dans ces requetes DNS, en tant que canal C2 bidirectionnel. Les operations liees a l'Iran OilRig/APT34 et DNSpionage se sont elles aussi appuyees sur le tunneling DNS pour le pilotage et l'exfiltration.

La detection repose sur des signaux que les attaquants peinent a masquer : taux de requetes par hote eleve, labels anormalement longs, forte entropie des sous-domaines (chaines base32/base64/hex), types d'enregistrement atypiques comme TXT ou NULL, et domaines jamais vus auparavant. Les defenses incluent le passage force de tous les clients par des resolveurs controles, le blocage du port 53 sortant direct au pare-feu de sortie, le sinkholing DNS, des limites de debit de requetes et l'analytique d'anomalies en EDR/NDR.

flowchart LR
  M[Infected host] -->|"data.b32label.attacker.com"| R[Internal resolver]
  R -->|recursive lookup| AUTH[Attacker authoritative NS]
  AUTH -->|"TXT/CNAME reply = command"| R
  R --> M
  AUTH -.reassembles.-> D[(Stolen data and C2)]