Tu m'as eu sur ton bonjour — Apparition du botnet NoaBot basé sur Mirai

Le botnet

NoaBot possède la plupart des capacités du botnet Mirai d'origine (comme un module scanner et un module attaquant, cachant son nom de processus, etc.), mais nous pouvons également voir de nombreuses différences avec le code source d'origine de Mirai. Tout d'abord, le propagateur du logiciel malveillant est basé sur SSH, et non sur Telnet comme Mirai.

Le scanner SSH semble être fait sur mesure, et assez particulier. En effet, une fois la connexion établie, le botnet envoie simplement la chaîne « hi » (« salut » en anglais), et met fin à la connexion (figure 2). La fin rapide a du sens dans le contexte d'un scanner, car il n'a pas besoin de garder la connexion établie, il a juste besoin de vérifier qu'elle existe. Pourquoi prend-il toutefois la peine d'envoyer « hi » ? C'est un mystère.

Une autre originalité du malware est qu'il contient des paroles de chanson. Des précédents échantillons du botnet comportaient des paroles de la chanson « Who's Ready for Tomorrow » de Rat Boy et IBDY (figure 3). Nous n'avons trouvé aucune utilité à ces paroles. Les échantillons ultérieurs ne les avaient pas.

D'autres changements par rapport à Mirai sont que le botnet utilise un dictionnaire d'informations d'identification différent pour son scanner SSH, et inclut de nombreuses capacités post-intrusion, telles que l'installation d'une nouvelle clé autorisée SSH comme porte dérobée pour télécharger et exécuter des binaires supplémentaires ou se propager vers de nouvelles victimes (figure 4).

Le logiciel malveillant est également compilé statiquement et dépouillé de tout symbole. Cela, en plus d'être une compilation non standard, a généré beaucoup plus de frustrations lors de la rétro-ingénierie du logiciel malveillant.

De plus, dans les échantillons plus récents du botnet, la chaîne était dissimulée au lieu d'être enregistrée en texte brut. Cela a rendu plus difficile l'extraction des détails du binaire ou la navigation dans les parties du démontage, mais l'encodage lui-même était peu sophistiqué et simple à analyser. 

Nous avons également vu l'ajout d'arguments de ligne de commande au fil du temps. Le plus intéressant est l'indicateur « noa », qui a permis au botnet d'installer une méthode de persistance sous la forme d'une entrée crontab à exécuter après un redémarrage.

Par coïncidence, il semble que cet indicateur ait été fortement utilisé dans la nature, car certaines des détections antivirus pour les échantillons de botnet avaient le préfixe « Noa- ».

Les opérations post-intrusion, que vous pouvez voir à la figure 4, constituent une autre évolution. Celles-ci n'étaient pas présentes dans les échantillons précédents que nous avons étudiés.

Le mineur (et pourquoi nous n'avons pas pu trouver son adresse de portefeuille)

Le mineur lui-même est beaucoup moins compliqué. C'est le mineur XMRig standard, bien qu'il ait également été auto-compilé, et les acteurs malveillants ont ajouté du code avant l'exécution du mineur pour extraire la configuration de minage au lieu de la fournir via la ligne de commande ou de l'enregistrer dans le binaire en texte brut (figure 6).

Nous pouvons voir qu'il y a d'autres appels de fonction avant l'appel de fonction pour construire la configuration XMRig. Si cela échoue, le mineur met fin à l'opération, mais sinon, il passe à la logique de mineur XMRig standard. (Vous pouvez comparer la décompilation ci-dessus au code source XMRig réel.) Pourquoi, en tant que chercheurs, nous soucions-nous de la configuration XMRig ? Généralement, elle contient des détails sur le pool de minage auquel il se connecte, ainsi que l'adresse du portefeuille pour recevoir les paiements de minage. En obtenant l'adresse du portefeuille et en suivant les paiements qui lui sont versés (qui sont généralement suivis par des pools publics), nous pouvons estimer à quel point cette campagne de minage de cryptomonnaie est rentable.

Cette fois, cependant, les attaquants avaient une longueur d'avance sur nous. Alors, allons un peu plus loin dans la construction de la configuration. Dans le code open source XMRig, les mineurs peuvent accepter des configurations de deux manières : soit par le biais de la ligne de commande, soit par des variables d'environnement. Dans notre cas, les acteurs malveillants ont choisi de ne pas modifier le code d'origine XMRig, et ont ajouté des éléments avant la fonction principale. Pour contourner le besoin d'arguments de ligne de commande (qui peuvent constituer un indicateur de compromission et des défenseurs d'alerte), les acteurs malveillants ont demandé au mineur de remplacer sa propre ligne de commande (en termes techniques, de remplacer argv) par des arguments plus « significatifs » avant de transmettre le contrôle au code XMRig. Le botnet exécute le mineur avec (tout au plus) un argument qui lui dit d'imprimer ses journaux.

Avant de remplacer sa ligne de commande, cependant, le mineur doit construire sa configuration. Tout d'abord, il copie les arguments de base qui sont stockés en texte brut (l'indicateur RIG-ID), qui identifie le mineur avec trois lettres aléatoires, les indicateurs de threads et un espace réservé pour l'adresse IP du pool (figure 7).

Curieusement, étant donné que les configurations sont chargées par le biais des registres xmm, IDA manque en fait les deux premiers arguments chargés, qui sont le nom binaire et l'espace réservé IP du pool.

Mirai est trop vieux

Les incidents les plus récents que nous avons vus avaient également des échantillons de P2PInfect, un ver auto-répliquant P2P écrit en Rust. Alors que P2PInfect est apparu pour la première fois en juillet 2023, nous voyons l'activité de NoaBot depuis janvier 2023, ce qui signifie qu'il est un peu antérieur à P2PInfect. Pourquoi passer de Mirai à autre chose ? Pour passer à quelque chose qui pourrait même être personnalisé ? Nous n'avons pas de réponse claire, mais plusieurs hypothèses.

Tout d'abord, il est plus difficile d'effectuer une rétro-ingénierie sur du code personnalisé que sur du code réutilisé, parce qu'il est modifié. Deuxièmement, les acteurs malveillants semblent assez technophiles, il se pourrait donc qu'ils s'essaient au développement de logiciels malveillants par simple curiosité ou par ennui (ou les deux). Enfin, étant donné que P2PInfect cible les serveurs Redis, il pourrait s'agir simplement de différents outils à des fins différentes.

Comment savons-nous qu'il s'agit des mêmes acteurs malveillants, et pas seulement d'une sorte de collaboration ? Nous n'en sommes pas encore absolument certains, mais nous avons une très bonne piste. Tout réside dans le professionnalisme technique du logiciel malveillant, associé au niveau de maturité d'un adolescent en termes de blagues qu'il comporte, notamment l'insertion de blagues dans le nom du mineur, l'intégration de paroles de chansons pop de jeu vidéo dans les binaires du logiciel malveillant, et l'envoi de « hi » tout en recherchant les ports ouverts. 

P2PInfect perpétue cette tradition. Il ressemble à un outil sophistiqué, mais il utilise un socket Unix et l'appelle « NunzombiE » (figure 8). Et alors que NunzombiE est dissimulé et décodé pendant l'exécution, le ver dispose aussi de chaînes intégrées pour « fast_vuln_file » et « slow_vuln_file », qui sont des chaînes parfaitement légitimes dans un exécutable. Il n'y a rien d'alarmant ici.