Plantage accidentel d'un botnet
Synthèse
Les chercheurs d'Akamai ont poursuivi leurs recherches sur KmsdBot, un botnet de cryptomining, et ont vu les auteurs le faire planter accidentellement.
Dans notre environnement contrôlé, nous avons pu envoyer des commandes au bot pour tester sa fonctionnalité et ses signatures d'attaque.
Dans le cadre de cette analyse, une erreur de syntaxe a provoqué l'arrêt de l'envoi de commandes par le bot, éliminant le botnet par la même occasion.
Comme ce botnet particulier ne cherche pas à persister sur un système, il ne peut poursuivre sa mission que s'il réinfecte le système.
Introduction
Plus tôt ce mois-ci, l'équipe de recherche sur la sécurité d'Akamai a publié un billet de blog sur KmsdBot, un botnet de cryptomining qui a infecté ses victimes via une connexion SSH qui utilise des identifiants faibles. Nous avons rapidement analysé et signalé ce botnet après qu'il a infecté l'un de nos pots de miel.
Cependant, après cette publication, nous avons continué à surveiller le botnet, et nous avons quelques mises à jour à partager dans cet article de blog, notamment le fait que nous l'avons neutralisé. Dans ce billet de blog, nous décrivons les étapes que nous avons suivies pour inspecter KmsdBot, ce qui nous a permis d'exécuter nos commandes et a finalement conduit à sa neutralisation.
Commande et contrôle du C2
L'élément le plus meurtrier de toute entité malveillante est la capacité à commander et contrôler (C2). Puisque KmsdBot avait une fonctionnalité C2, nous voulions tester divers scénarios liés à cette fonctionnalité. Une partie de ces tests consistait à modifier un échantillon récent de KmsdBot pour qu'il communique avec une adresse IP dans l'espace d'adressage RFC 1918.
Cela nous a permis de disposer d'un environnement de jeu contrôlé et, par conséquent, nous avons pu envoyer au bot nos propres commandes pour tester sa fonctionnalité et ses signatures d'attaque. Il est intéressant de noter qu'après une seule commande mal formatée, le bot a cessé d'envoyer des commandes. Naturellement, nous avons commencé une enquête. Ce n'est pas tous les jours que l'on tombe sur un botnet que les acteurs de la menace ont eux-mêmes détruit.
Comment nous l'avons trouvé
Fig. 1 : Désassemblage de la fonction sys.main.connect()
Vous pouvez voir que la tranche de chaîne est stockée à l'emplacement mémoire 0x00632f19. Nous pouvons sauter à cette adresse dans le binaire et modifier son contenu pour qu'il pointe vers une adresse réseau dans l'espace RFC 1918, à savoir quelque part dans 192.168.0.0/24, que nous contrôlons.
De cette façon, nous pouvons agir comme le C2 et envoyer des exemples de commandes d'attaque pour diriger le trafic d'attaque vers une cible où nous pouvons enregistrer le trafic réseau.
Fig. 2 : Écriture de l'adresse en hexadécimal .861.291 à l'envers à cause du boutisme
Ainsi, notre nouveau C2 est 192.168.0.31 sur le port 57388 (Figure 2). Nous savons que le C2 communique en texte clair, donc l'envoi des commandes du programme malveillant peut être fait en utilisant Netcat. Nous configurons ensuite deux machines virtuelles : l'une sur laquelle nous ferons entrer en action le programme malveillant et l'autre que nous utiliserons comme C2.
Pendant les tests, nous avons remarqué que le botnet a cessé d'envoyer des commandes d'attaque après avoir observé l'arrivée d'une seule commande incorrecte. La commande :
!bigdata www.bitcoin.com443 / 30 3 3 100
Un observateur attentif remarquera l'absence d'espace entre le site Web cible et le port. Le bot n'a pas de contrôle d'erreur intégré dans son code pour vérifier que les commandes sont correctement formatées.
C'est pourquoi une commande mal formatée fera planter le code binaire Go avec une trace de pile indiquant une erreur « index out of range ». Ceci est dû au fait que le nombre d'arguments fournis est incorrect. Nous avons testé cette théorie avec notre configuration C2 et bot (Figure 3).
Fig. 3 : Émulation du C2 et reproduction de la commande incorrecte envoyée
Fig. 4 : Le bot a planté en raison du mauvais nombre d'arguments fournis
Cette commande incorrecte a probablement fait planter l'intégralité du code du botnet qui s'exécutait sur les machines infectées et communiquait avec le C2, ce qui a tué le botnet, en somme. Comme le bot n'a aucune fonctionnalité de persistance sur une machine infectée, la seule façon de perdurer est de réinfecter et de reconstruire le botnet à partir de zéro.
Conclusion
Il est rare de rencontrer ce genre de situations en sécurité. Dans notre quotidien, marqué par les attaques Zero Day et l'épuisement professionnel, voir une menace qui peut être atténuée par l'équivalent en codage d'une coquille est une belle histoire. Ce botnet s'en est pris à de très grandes marques de luxe et à des sociétés de jeux vidéo, et pourtant, avec une simple commande incorrecte, il ne peut plus sévir. Il s'agit d'un exemple frappant de la nature capricieuse de la technologie et de la façon dont même l'exploiteur peut être exploité par celle-ci.
L'objectif de l'équipe de recherche sur la sécurité d'Akamai est de suivre, détecter, documenter et publier de nouvelles découvertes afin de protéger la sécurité et la stabilité d'Akamai, de ses clients et d'Internet dans son ensemble. Nous continuerons à surveiller ces attaques et à mettre à jour ce blog en conséquence. Pour obtenir des mises à jour en temps réel des recherches sur la sécurité, suivez-nous sur Twitter.
