Décortiquer une balise C2 : base64 et XOR multi-octets
Le défi
Une machine compromise envoyait sans cesse de courts paquets base64 vers un serveur inconnu. Votre bac à sable a capturé une charge utile de balise ci-dessous. La rétro-ingénierie de l'implant montre qu'il encode une commande en base64 après l'avoir chiffrée par XOR avec une clé répétée. Récupérez la commande en clair et soumettez le flag (HDNA{...}).
Ce que tu vas apprendre
- Identifier le base64 comme couche de transport externe du trafic de balise
- Récupérer le texte en clair à partir d'un XOR à clé répétée connue
- Distinguer une clé XOR multi-octets d'une clé à un octet d'après la sortie produite
- Décortiquer des transformations empilées dans le bon ordre inverse
- Comprendre pourquoi une clé XOR codée en dur n'offre aucune réelle confidentialité au C2
Compétences testées
Prérequis
- Aisance avec le base64
- Comprendre que le XOR est sa propre opération inverse
- Connaissance de la notion de trafic de commande et contrôle
Comment ça marche
Une balise de commande et contrôle (C2) n'est qu'un petit message régulier qu'un implant envoie vers sa base. Les auteurs n'utilisent presque jamais de vraie cryptographie pour cela, le binaire devrait de toute façon embarquer la clé, donc ils se contentent d'un XOR à clé répétée et encodent le résultat en base64 pour qu'il survive sous forme de texte imprimable sur HTTP. Cela suffit à échapper à un simple passage de strings, mais ne résiste pas à un analyste qui dispose de l'échantillon.
Décortiquez les couches dans l'ordre inverse. Le paquet capturé est du base64 imprimable se terminant par = : décodez-le d'abord pour obtenir les octets bruts chiffrés par XOR. Appliquez ensuite un XOR sur ces octets avec la clé de l'implant. Le XOR est symétrique, donc la même opération avec la même clé annule le chiffrement, car A XOR B XOR B = A. Ici, la clé correspond aux six octets beacon, répétés tout au long du message. Reconnaître qu'elle fait plusieurs octets plutôt qu'un seul est le véritable saut de difficulté : un XOR à un octet laisserait une structure répétitive caractéristique que cette sortie n'a pas.
Dans l'atelier, ajoutez From Base64, puis XOR avec la clé beacon, et la commande se révèle en direct. Les autres opérations de la palette (hex, Vigenere, ROT, atbash, reverse, URL-decode) sont des leurres dont le format d'entrée ne correspond jamais aux données, à aucune étape.
Erreurs fréquentes
- Appliquer le XOR directement sur le texte base64. Le base64 est la couche externe : décodez-le avant d'appliquer le XOR.
- Supposer une clé d'un seul octet. Un XOR à un octet ne produira pas de texte lisible ici, la clé est le mot « beacon ».
- Forcer la clé par brute force. La rétro-ingénierie de l'implant vous a déjà donné la clé ; lisez d'abord l'énoncé.
- Ajouter des leurres. hex-decode ou Vigenere semblent plausibles, mais leurs entrées ne correspondent pas : vérifiez le format des données avant chaque opération.
Comment s'en protéger
Pour les défenseurs, la leçon est que le motif base64 plus XOR est un schéma d'obfuscation que vous devez pouvoir décortiquer d'un coup d'œil, aussi bien en traquant des balises qu'en relisant votre propre code à la recherche d'une confiance mal placée. Une clé XOR codée en dur dans un binaire est récupérable par quiconque dispose de l'échantillon : elle ne protège donc rien.
- Traquez les charges utiles base64 sortantes, courtes et régulières, et scannez-les automatiquement par XOR lors du tri.
- Extrayez les clés codées en dur des implants capturés et utilisez-les pour décoder le trafic C2 historique.
- Ne considérez jamais une clé XOR statique comme une garantie de confidentialité : utilisez un chiffrement authentifié avec une clé gérée quand cela compte réellement.
- Détectez le balisage par la régularité de la temporalité et de la destination, pas seulement par le contenu de la charge utile.