KreiosC2 Botnet conceptuel et modulaire qui permet de basculer dynamiquement entre des canaux C&C de type Twitter, TinyURL et JPEG

Par Xavier Poli, secuobs.com
Le 24/11/2009

---

Résumé : KreiosC2 v3 est une preuve de concept modulaire permettant de basculer dynamiquement la gestion d'un Botnet entre différents types de canaux de commande et de contrôle. Ces canaux utilisent par ailleurs des vecteurs inhabituels comme des images JPEG valides ou les services Twitter et TinyURL. - Lire l'article



Initialement, KreiosC2 est une preuve de concept, développée en Ruby, qui permet d'utiliser Twitter en tant que canal de commande et de contrôle pour gérer un réseau de type Botnet ( lien ). Les commandes sont ici transmises via des messages postés sur un compte Twitter unique et protégé. Le client infecté va vérifier périodiquement ce compte afin de récupérer les commandes qu'il devra traiter. Ces commandes peuvent être représentées selon quatre formats différents.

Le format par défaut utilise les commandes brutes, l'identification se faisant par une chaîne spécifique placée en début de message (:cmd ping 88.191.75.173). Le second format privilégie lui des phrases, en anglais, qui correspondent chacune à une commande. Les correspondances sont gérées par des tables internes. Ces phrases sont suivies d'une somme de contrôle, soit les dix derniers octets du MD5 du message, afin de bien discerner les messages à traiter (do stuff on 88.191.75.173 #7266bb357d).

Ce format permet par ailleurs de modifier régulièrement les tables de concordance afin de minimiser les risques de détection par recherche de motifs. Alors que le format suivant privilégie l'encodage base64 pour l'obfuscation des commandes (xxcGluZyA4OC4xOTEuNzUuMTcz), le dernier format emprunte lui des caractéristiques propres à chacun des trois autres. A savoir, la syntaxe brute du premier, l'encodage base64 du second et les sommes de contrôle du troisième, il utilise néanmoins SHA1 cette fois-ci.

Un chiffrement AES (h+Mxms5NyvKajSH2EUyeyTmtECg1P) est également appliqué aux commandes avec ce format. Les dernières versions de KreiosC2 se basent par ailleurs sur l'utilisation de fichiers autonomes pour la gestion des formats et des canaux. Les ajouts et les mises à jour de ces éléments se font dès lors de façon dynamique puisqu'elles ne nécessitent pas que l'attaquant redémarre les applications principales ou qu'il intervienne manuellement au niveau du client infecté.

Chaque format est par exemple géré à travers deux fichiers, le premier servant à l'encodage des commandes coté serveur et le second à leur décodage coté client. Il en va de même pour la gestion des canaux. Outre ces fonctions de maintenance, KreiosC2 permet également d'effectuer, coté client, un ping sur l'adresse IP d'une machine distante, comme vu précédemment, mais également de télécharger des exécutables ou des scripts dont il facilitera ensuite l'exécution sur le client infecté.

A noter que, par défaut, les messages antérieurs ne sont pas traités afin de faciliter la mise en place du dispositif, un paramètre permet néanmoins de modifier ce comportement par la suite. Dans la dernière version de KreiosC2, des canaux additionnels sont de plus disponibles, TinyURL et JPEG. TinyURL autorise l'abus des raccourcissements personnalisés d'URL afin de passer les commandes au client, alors que le format JPEG offre lui le champ commentaire de ses entêtes pour l'injection de commandes au sein d'images valides.

La multiplication des canaux et le fait de pouvoir basculer dynamiquement entre eux permettent de réduire le temps d'exposition consécutif sur un même canal et donc les risques de détection. L'automatisation de la mise en ligne et de la gestion d'images multiples, voir multi-sites, sont par ailleurs de futures pistes de développement. A l'avenir, l'utilisation de Twitter pourrait aussi évoluer de façon à mettre en place des systèmes beaucoup plus complexes pour le passage des commandes vers le client infecté.

Ce dernier pourraient par exemple reconstituer les commandes en récupérant des caractères, à position fixe ou évolutive, dans des messages qui seraient postés sur un ensemble de comptes protégés. Des tables de concordance aideraient alors à définir la liste de ces comptes et leur ordre d'utilisation. Des ensembles différents de comptes pourraient même être définis pour chaque client infecté et par période. On pourrait de plus imaginer des permutations en fonction des messages pairs/impairs pour chaque compte.

Les séparations entre les commandes pourraient elles être gérées selon des intervalles de temps donnés ou de façon plus pratique par l'intermédiaire de motifs spécifiques postés sur les comptes de terminaison. La commande reconstituée pourrait de plus être chiffrée préalablement à sa dé-construction. Le nombre journalier de messages postés et la qualité de son API font de Twitter un idéal de furtivité pour ce genre d'opérations. La détection d'un tel système serait en effet assez complexe.

A noter finalement qu'un module additionnel est dès à présent disponible au téléchargement pour KreiosC2 et qu'il permet de dissocier les commandes et les arguments lors de l'utilisation du service Twitter en tant que canal de commande et de contrôle. L'activation de ce module implique donc que le client infecté doit récupérer, depuis le compte Twitter, deux messages distincts, postés consécutivement, avant de se charger de les ré-associer et d'effectuer les traitements demandés.

Démonstration de KreiosC2 en vidéo :



Le site officiel ( lien )
KreiosC2 PoC v3 ( lien )
Module Split Langage ( lien )

Source : DigiNinja ( lien )