DNS : une arme cachée dans vos TXT Records

Le DNS ? Pour beaucoup, c'est juste l'arrière-plan invisible qui traduit example.com en adresse IP. Rien de sexy. Les équipes sécurité l'ignorent souvent. Grave erreur.

Un proof-of-concept récent change la donne. Les TXT records du DNS se transforment en outil de livraison d'applications malveillantes. Oubliez les simples mots de passe volés. Ici, on parle de logiciels complets, avec leurs dépendances, servis via des requêtes DNS. Sans toucher aux fichiers classiques.

Pourquoi les TXT Records posent problème

Ces enregistrements TXT servent d'abord à valider les emails : SPF, DKIM, DMARC. Ce sont des champs texte basiques, sans vrai contrôle. Le protocole s'en fiche du contenu. Pratique, mais risqué.

Ce qui les rend vulnérables :

Partout : Tous les domains en ont. Tous les registrars les gèrent.

Capacité : Une zone DNS en stocke des milliers, jusqu'à 2 000 caractères pièce.

Cache global : Les résolveurs publics, ISP, entreprises et CDN les gardent en mémoire aux quatre coins du monde.

Invisible aux audits : Qui archive le contenu des TXT records historiques ? Personne.

Ouvert à tous : Une connexion internet suffit pour les lire. Pas d'auth, pas de traces.

Résultat : un système de distribution gratuit, rapide, indétectable, qui mime le trafic DNS légitime. Le rêve des attaquants.

De la simple charge à l'app complète

Ça commence petit. Des chercheurs cachent du shellcode en Base64 dans les TXT. Facile à déployer, dur à repérer. Personne ne scrute les réponses DNS anciennes.

Mais on peut aller plus loin. Un fichier ? Pourquoi pas. Plusieurs fichiers ? Idéal. Une app entière ? Parfait.

Le PoC qui buzz : un moteur DOOM complet, chargé via 1 966 TXT records. Tout s'assemble en RAM, sans écrire sur disque. Imaginez : un miner crypto, un shell distant ou pire, livré pareillement.

Le fonctionnement en clair

Rien de sorcier :

Encodage : Compressez le binaire. Passez en Base64.

Découpage : Coupez en tranches de 2 000 caractères. Chaque tranche = un TXT record.

Index : Un record liste le nombre et l'ordre des tranches.

Récup : Le malware interroge séquentiellement. Il reconstruit en mémoire.

Lancement : Exécute direct en RAM. Pour .NET, reflection suffit.

Ça passe pour du DNS banal. Des milliers de queries par jour ? Ajoutez-en 200 suspectes. Bonne chance pour trier.

Vos défenses actuelles ? Largement insuffisantes

La plupart surveillent :

• Fichiers : YARA, hashes, comportements. Mais sans disque, nada.
• Réseau : Queries DNS normales, souvent chiffrées (DoH/DoT). Payload en chunks innocents.
• Réputation : L'attaquant utilise votre domain, ou un clean.
• Logs : 24-48h max. Trop tard.

Conseils pour les clients NameOcean

Chez NameOcean, la sécurité des domains prime. Soyez transparents et proactifs :

1. Vérifiez vos TXT : Listez tout. Alertez sur les ajouts.

2. Surveillez le DNS : Analysez queries. Cherchez répétitions, volumes anormaux, Base64 suspects.

3. Filtrez : Activez DNS security en gateway ou endpoint. Détecte les patterns louches.

4. Sécurisez le registrar : MFA obligatoire. Accès limités. Logs des modifs.

5. DNSSEC : Bloque le spoofing, bonus utile.

6. CDN en vue : Logs et alertes sur CloudFlare ou équivalent.

DNS : infra vitale, pas sûre

Ce PoC le prouve : DNS privilégie la fiabilité, pas la sécu. Sa simplicité le rend exploitable. États-nations l'utilisent déjà. DOOM ? Juste un appel au réveil.

Et maintenant ?

DNS = surface d'attaque. Surveillez comme le web.

Zero-trust DNS. Même interne, traitez-le dur.

Outils dédiés : Firewalls DNS, détection anomalies, intel threats.

Formez : SOC et architects doivent intégrer ça.

NameOcean fournit contrôles robustes, logs complets, audits faciles. Vos domains méritent ça.

Les TXT records paraissent anodins. Ils cachent des failles majeures. Ouvrez les yeux.

Vu du DNS suspect chez vous ? Comment protégez-vous ? Dites-le en coms.