Décoder l'étiquette de la balise : démasquer un nom d'hôte d'exfiltration DNS

Certains logiciels malveillants exfiltrent des données volées via DNS car les requêtes DNS sortent presque toujours de n'importe quel réseau. Pour faire transiter des données arbitraires par DNS, un implant les découpe souvent dans les étiquettes de sous-domaine d'une requête. Ces étiquettes auraient l'air étranges en octets bruts, alors le logiciel malveillant les encode d'abord en base64. Le résultat est une étiquette valide pour le DNS qui se fond dans le flux constant de résolutions de noms qu'effectue un hôte.

Le base64 dans une étiquette est facile à repérer une fois qu'on connaît son allure. Un mot de domaine normal est en minuscules et prononçable ; une étiquette en base64 mélange majuscules, minuscules et chiffres, et se termine souvent par un ou deux signes = de remplissage. L'étiquette capturée ici a exactement cette forme, ce qui indique qu'elle est encodée plutôt qu'un nom réel.

Le point essentiel est que cet encodage n'assure aucune confidentialité. Le base64 n'a pas de clé, donc un défenseur peut l'inverser en un seul clic et lire la chaîne d'origine. Les attaquants ne l'utilisent que pour faire ressembler le trafic à du trafic ordinaire, pas pour garder le contenu secret. Cette asymétrie joue en faveur de l'analyste : une fois l'encodage reconnu, le décoder révèle immédiatement la vraie destination avec laquelle l'implant communique. Les boutons ROT13, hex, URL et inverse attendent des formats d'entrée différents et sont des leurres ici.

• Traiter l'étiquette comme un nom d'hôte réel. La casse mixte et le remplissage = signifient qu'elle est encodée, pas un nom littéral. Décodez-la avant de tirer des conclusions.
• Supposer que l'encodage cache la destination. Le base64 n'a pas de clé, il suffit d'un clic pour revenir au texte clair. Il ne fait que déguiser le trafic, il ne le protège pas.
• Choisir le mauvais décodeur. Le hex n'utiliserait que 0-9a-f et le ROT13 conserverait la même longueur et la même forme. La casse mixte et le remplissage orientent vers le base64.
• Soumettre l'étiquette encodée. La réponse est le nom d'hôte décodé, pas la chaîne base64.

Du point de vue défensif, l'objectif est de repérer les données encodées qui sortent via DNS et de garder à l'esprit que l'encodage lui-même n'apporte rien à l'attaquant une fois observé. Traitez les étiquettes DNS anormalement longues ou à forte entropie comme un signal, et décodez tout base64 rencontré durant l'analyse pour confirmer ce qui est transféré.

• Surveillez les étiquettes de sous-domaine DNS anormalement longues, à forte entropie ou se répétant rapidement, qui évoquent un tunneling.
• Faites transiter le DNS par des résolveurs contrôlés qui journalisent les requêtes afin que ce type d'étiquette soit capturé pour analyse.
• Décodez tout niveau de base64, hex ou URL observé dans le trafic capturé pendant l'analyse : l'encodage est réversible et révèle le contenu réel.
• Bloquez ou générez une alerte sur le trafic vers des domaines nouvellement observés ou suspects une fois une telle destination décodée.