Paalkia CTF

Hexagone CTF / Forensics / Panthère Silencieuse 1/4

Easy T1048.001 Opération Panthère Silencieuse

Panthère Silencieuse 1/4

Exfiltration DNS

01Énoncé

Le trafic réseau de FIN-WKS-07 a été capturé pendant l'incident. Des données sensibles ont quitté le poste. Retrouve ce qui a fuité. Format du flag : RWX{...}

02Contexte

Dans le scénario « Opération Panthère Silencieuse », un acteur de type APT cible le service comptabilité d'une PME française. Le poste FIN-WKS-07 (utilisateur j.martin) est compromis.

Ce premier challenge porte sur une capture réseau : il faut repérer une exfiltration de données noyée dans du trafic légitime.

TTP de référence : exfiltration de données via le protocole DNS, à la manière du groupe OilRig (APT34).

03Artefact

  • PANTHERE-EVD-01.zip contenant FIN-WKS-07_capture.pcap
  • Environ 35 Mo, à peu près 3120 paquets
  • Du trafic DNS légitime vers environ 290 domaines connus (gstatic, googleapis, spotify, github) sert de bruit

04Résolution

Étape 1 : reconnaissance de l'existant

Dans Wireshark : Statistics > Protocol Hierarchy.

Wireshark Protocol Hierarchy Statistics

Le trafic est dominé par TCP (83,5 %, 2605 paquets), mais on relève 453 paquets DNS (14,5 %) émis par un seul poste, 10.10.10.50.

Ce volume de résolutions ne prouve rien en soi, mais justifie une inspection du contenu DNS.

En appliquant le filtre dns, les premières requêtes visent des domaines légitimes (telemetry.googleapis.com, api.yahoo.com, static.slack.com, assets.github.com, www.msn.net).

Requêtes DNS filtrées dans Wireshark

On note au passage que toutes les réponses pointent vers la même IP 10.10.10.100. Si l'exfiltration existe, elle se cache donc derrière une requête qui ne ressemble pas à celles-ci.

Étape 2 : isoler la requête anormale

Filtre Wireshark
dns.flags.response == 0 && len(dns.qry.name) > 40
  • dns.flags.response == 0 : ne garde que les requêtes (le flag « response » vaut 0 pour une question, 1 pour une réponse).
  • len(dns.qry.name) > 40 : ne garde que les requêtes dont le nom de domaine dépasse 40 caractères.
Requêtes DNS de plus de 40 caractères

Les noms de domaine légitimes sont courts (une vingtaine de caractères). En filtrant les requêtes dont le nom dépasse 40 caractères, tout le bruit disparaît et il ne reste qu'un seul domaine parent : exfil.panthere.lab.

Les sous-domaines sont longs, d'apparence aléatoire, et commencent par un numéro croissant (0000, 0001, 0002...). Ce motif est caractéristique d'un tunnel DNS : des données encodées sont transportées dans les noms de domaine eux-mêmes.

Détail d’une requête DNS dans Wireshark

Détail d'une requête

0000.KNQXK5TFM5QXEZDFEBQWGY3FOMQFMUCOEAWSAQ2P.exfil.panthere.lab

Elle se décompose en trois parties :

  1. un numéro de séquence (0000) ;
  2. un bloc de données (KNQX...) ;
  3. le domaine contrôlé par l'attaquant (exfil.panthere.lab).

Étape 3 : récupérer tous les fragments

Filtre Wireshark
dns.flags.response == 0 && dns.qry.name contains "exfil.panthere.lab"

dns.qry.name contains "exfil.panthere.lab" : ne garde que les requêtes dont le nom contient le domaine de l'attaquant, quelle que soit leur longueur.

Les six fragments 0000 à 0005

Le filtre par longueur avait écarté le dernier fragment, plus court car il contient la fin des données. En filtrant directement sur le domaine de l'attaquant, on récupère les 6 fragments (0000 à 0005).

Étape 4 : identifier l'encodage et décoder

Opération Magic de CyberChef

Pour identifier l'encodage, on soumet un bloc à l'opération Magic de CyberChef, qui teste automatiquement les décodages possibles et les classe selon la lisibilité du résultat. Le bloc est compatible avec plusieurs encodages (base32, base64, base85), mais seul From Base32 produit un texte lisible : « Sauvegarde acces VPN - CO ».

D'autres outils font la même identification automatique, comme Ciphey ou le Cipher Identifier de dCode.

Base32 ou base64 ?

  • Le base64 utilise les majuscules, les minuscules, les chiffres, + et /.
  • Le base32 se limite aux majuscules et aux chiffres de 2 à 7.

Pour un tunnel DNS, le base32 s'impose : les noms de domaine ne distinguent pas la casse et interdisent + et /, le base64 serait donc altéré en transit.

Décodage From Base32 dans CyberChef

Le contenu exfiltré est un fichier de sauvegarde d'accès VPN (hôte vpn.panthere-corp.local, compte svc_backup), avec le flag en dernière ligne.

05Flag

RWX{dns_tunnel_b4se32_l3ak}

06Pistes de détection

  • Un poste qui interroge des centaines de fois le même domaine parent en peu de temps.
  • Des noms de domaine anormalement longs, d'apparence aléatoire, ou numérotés.
  • Un domaine jamais vu dans l'entreprise, contacté par un seul poste.
  • MITRE ATT&CK : T1048.001.

07Note du concepteur

Objectif pédagogique

Apprendre à repérer une exfiltration DNS noyée dans du trafic légitime. Le challenge fait travailler le premier réflexe d'un analyste réseau : partir d'une vue d'ensemble (Protocol Hierarchy), isoler ce qui sort de la norme avec des filtres simples (longueur des noms, domaine parent), puis comprendre le format des données pour les réassembler dans l'ordre. Il montre aussi pourquoi un tunnel DNS utilise le base32 plutôt que le base64.

Anti-triche

Le flag n'apparaît jamais en clair dans le pcap : un simple grep ne donne rien. Il faut réassembler les fragments dans l'ordre et décoder le base32.