Les appareils Linux sont attaqués par un ver inédit

Au cours de l’année écoulée, des logiciels malveillants auto-réplicatifs jusqu’alors inconnus ont compromis les appareils Linux du monde entier et installé des logiciels malveillants de cryptominage qui prennent des mesures inhabituelles pour dissimuler leur fonctionnement interne, ont indiqué les chercheurs.

Le ver est une version personnalisée de Mirai, le malware botnet qui infecte les serveurs, routeurs, caméras Web et autres appareils dits Internet des objets basés sur Linux. Mirai a été révélé en 2016 lorsqu’il a été utilisé pour lancer des attaques par déni de service distribué qui ont paralysé des parties clés d’Internet cette année-là. Les créateurs ont rapidement publié le code source sous-jacent, une décision qui a permis à un large éventail de groupes criminels du monde entier d’intégrer Mirai dans leurs propres campagnes d’attaque. Une fois qu’il s’est emparé d’un appareil Linux, Mirai l’utilise comme plate-forme pour infecter d’autres appareils vulnérables, une conception qui en fait un ver, ce qui signifie qu’il s’auto-réplique.

Un malware à la douzaine avec une touche d’originalité

Traditionnellement, Mirai et ses nombreuses variantes se propagent lorsqu’un appareil infecté analyse Internet à la recherche d’autres appareils acceptant les connexions Telnet. Les appareils infectés tentent ensuite de déchiffrer le mot de passe telnet en devinant les paires d’informations d’identification par défaut et couramment utilisées. En cas de succès, les appareils nouvellement infectés ciblent des appareils supplémentaires en utilisant la même technique. Mirai a principalement été utilisé pour mener des DDoS. Compte tenu de la grande quantité de bande passante disponible pour de nombreux appareils de ce type, les flots de trafic indésirable sont souvent énormes, conférant au botnet dans son ensemble un pouvoir considérable.

Mercredi, des chercheurs de la société de sécurité et de fiabilité des réseaux Akamai ont révélé qu’un réseau jusqu’alors inconnu basé sur Mirai, qu’ils ont surnommé NoaBot, ciblait les appareils Linux depuis au moins janvier dernier. Au lieu de cibler les mots de passe Telnet faibles, NoaBot cible les mots de passe faibles connectant les connexions SSH. Autre particularité : plutôt que d’effectuer des DDoS, le nouveau botnet installe un logiciel d’extraction de cryptomonnaie, qui permet aux attaquants de générer des pièces numériques en utilisant les ressources informatiques, l’électricité et la bande passante des victimes. Le cryptominer est une version modifiée de XMRig, un autre logiciel malveillant open source. Plus récemment, NoaBot a également été utilisé pour fournir P2PInfect, un ver distinct révélé par des chercheurs de Palo Alto Networks en juillet dernier.

Akamai surveille NoaBot depuis 12 mois dans un pot de miel qui imite de vrais appareils Linux pour suivre diverses attaques circulant dans la nature. À ce jour, les attaques proviennent de 849 adresses IP distinctes, dont presque toutes hébergent probablement un appareil déjà infecté. Le graphique suivant retrace le nombre d’attaques lancées vers le pot de miel au cours de l’année écoulée.

« En apparence, NoaBot n’est pas une campagne très sophistiquée : c’est ‘juste’ une variante de Mirai et un cryptomineur XMRig, et il y en a à la pelle aujourd’hui », a écrit Stiv Kupchik, chercheur principal en sécurité chez Akamai, dans un rapport mercredi. « Cependant, les obscurcissements ajoutés au malware et les ajouts au code source d’origine dressent un tableau très différent des capacités des acteurs de la menace. »

La fonctionnalité la plus avancée est la manière dont NoaBot installe la variante XMRig. Généralement, lorsque les mineurs de crypto sont installés, les fonds des portefeuilles sont distribués et sont spécifiés dans les paramètres de configuration fournis dans une ligne de commande émise sur l’appareil infecté. Cette approche représente depuis longtemps un risque pour les acteurs de la menace, car elle permet aux chercheurs de savoir où les portefeuilles sont hébergés et combien d’argent y a été versé.

NoaBot utilise une nouvelle technique pour empêcher une telle détection. Au lieu de fournir les paramètres de configuration via une ligne de commande, le botnet stocke les paramètres sous forme cryptée ou masquée et ne les déchiffre qu’une fois XMRig chargé en mémoire. Le botnet remplace ensuite la variable interne qui contiendrait normalement les paramètres de configuration de la ligne de commande et passe le contrôle au code source de XMRig.

Kupchik a proposé une description plus technique et détaillée :

Dans le code open source XMRig, les mineurs peuvent accepter les configurations de deux manières : soit via la ligne de commande, soit via des variables d’environnement. Dans notre cas, les auteurs de la menace ont choisi de ne pas modifier le code original de XMRig et ont plutôt ajouté des parties avant la fonction principale. Pour contourner le besoin d’arguments de ligne de commande (qui peuvent être un indicateur de compromission d’IOC et d’alerter les défenseurs), les acteurs de la menace ont demandé au mineur de remplacer sa propre ligne de commande (en termes techniques, en remplacement de argv) par des arguments plus « significatifs » avant de passer le contrôle. au code XMRig. Le botnet exécute le mineur avec (au plus) un argument qui lui demande d’imprimer ses journaux. Cependant, avant de remplacer sa ligne de commande, le mineur doit construire sa configuration. Tout d’abord, il copie les arguments de base stockés en texte brut : l’indicateur rig-id, qui identifie le mineur avec trois lettres aléatoires, les indicateurs de thread et un espace réservé pour l’adresse IP du pool (Figure 7).

Curieusement, comme les configurations sont chargées via les 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.

Ensuite, le mineur décrypte le nom de domaine du pool. Le nom de domaine est stocké, crypté, dans quelques blocs de données qui sont déchiffrés via des opérations XOR. Bien que XMRig puisse fonctionner avec un nom de domaine, les attaquants ont décidé de franchir une étape supplémentaire et ont implémenté leur propre DNS.
fonction de résolution. Ils communiquent directement avec le serveur DNS de Google (8.8.8.8) et analysent sa réponse pour résoudre le nom de domaine en adresse IP.

La dernière partie de la configuration est également cryptée de la même manière et constitue le mot de passe permettant au mineur de se connecter au pool. Dans l’ensemble, la configuration totale du mineur ressemble à ceci :

-o --rig-id --threads –pass espana*tea

Vous remarquez qu’il manque quelque chose ? Oui, pas d’adresse de portefeuille.

Nous pensons que les acteurs de la menace ont choisi de gérer leur propre pool privé plutôt qu’un pool public, éliminant ainsi le besoin de spécifier un portefeuille (leur pool, leurs règles !). Cependant, dans nos échantillons, nous avons observé que les domaines des mineurs ne se résolvaient pas avec le DNS de Google, nous ne pouvons donc pas vraiment prouver notre théorie ou collecter plus de données à partir du pool, puisque les domaines dont nous disposons ne peuvent plus être résolus. Nous n’avons vu aucun incident récent qui ait fait tomber le mineur, il se pourrait donc aussi que les acteurs de la menace aient décidé de partir vers des pâturages plus verts.