Le SOC enquête sur un poste interne (10.0.0.37) qui émet un volume anormal de requêtes DNS TXT vers un domaine externe inconnu, en contournant le résolveur interne. Ce domaine, maj-cdn-logiciel.example, se fait passer pour un « CDN de mises à jour » mais n'appartient pas à l'entreprise : il est contrôlé par l'attaquant.
Il s'agit d'un canal caché DNS (tunnel DNS). Ici, le poste compromis récupère une charge servie par l'attaquant : la donnée est renvoyée dans les valeurs des enregistrements TXT, découpée en plusieurs fragments numérotés (chunk-1-of-4, chunk-2-of-4, …) renvoyés dans le désordre, noyés au milieu d'enregistrements TXT parfaitement légitimes (SPF, DKIM, DMARC, vérifications de propriété).
Une sonde DNS passive, branchée sur le port miroir (SPAN) du commutateur cœur de réseau, a exporté toutes les requêtes TXT observées et la valeur retournée (dns-queries.log). Placée au cœur du réseau, elle voit l'ensemble du trafic DNS, y compris les requêtes internes et celles qui contournent le résolveur.
Extrait du journal (valeurs abrégées, pour le format) :
TXT chunk-2-of-4.maj-cdn-logiciel.example. "<fragment>" TXT selector1._domainkey.corp-nimbus.example. "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." TXT chunk-4-of-4.maj-cdn-logiciel.example. "<fragment>"
Votre mission
Isolez les fragments du domaine suspect, remettez-les dans l'ordre (1 à 4), concaténez leurs valeurs, puis appliquez le bon décodage pour reconstituer le flag.
Les enregistrements DNS TXT sont faits pour stocker du texte arbitraire (SPF, DKIM, vérifications de services). Cette souplesse en fait aussi un canal caché apprécié : un logiciel malveillant publie ou récupère des données via des requêtes DNS, un trafic souvent peu surveillé et rarement bloqué. Selon le sens, on parle d'exfiltration (données encodées dans les requêtes, du poste vers l'attaquant) ou de canal de commande / téléchargement (charge renvoyée dans les réponses, de l'attaquant vers le poste) — c'est ce dernier cas ici.
Pour se défendre :