Le référencement et la menace d'empoisonnement C2 dans Blockchain qui visent les gestionnaires avec MSI Faux

Un plan sophistiqué découvert par l'équipe d'enquête sur la menace d'Atos en mars 2026 montre comment des acteurs malveillants se livrent à l'offensive contre les comptes à haut risque grâce à une combinaison de techniques classiques et de ressources modernes de résilience : Empoisonnement au référencement, une architecture de distribution en deux phases dans GitHub et une résolution de commande et de contrôle (C2) ancrée dans la chaîne de blocs publique. L'objectif n'est pas l'utilisateur moyen : ils cherchent délibérément des administrateurs, des ingénieurs DevOps et des analystes de sécurité par l'intermédiaire d'installateurs MSI qui posent pour des utilitaires administratifs légitimes.

La campagne exploite la confiance implicite dans les résultats de recherche. Grâce à l'empoisonnement par le SEO, les attaquants font des dépôts de façade en GitHub - propre, avec un README professionnel et bien indexé - apparaissent dans les premiers endroits pour des recherches d'outils spécialisés. Ces dépôts agissent comme des fenêtres et redirige discrètement l'utilisateur vers un deuxième dépôt caché qui héberge l'installateur réel. Séparer la visibilité publique de la livraison de la charge utile permet de tourner l'infrastructure de distribution sans perdre de positionnement dans les moteurs de recherche Cela rend difficile l'adoption de mesures d'atténuation fondées uniquement sur la fermeture de comptes ou l'aliénation de dépôts.

Techniquement, les installateurs identifiés sont MSI qui lance un script de lot désuet, télécharge l'exécution Node.js depuis leur canal officiel et déploie une chaîne de charge JavaScript multicanaux cryptée avec AES-256-CBC. La persistance est réalisée au moyen des touches Exécuter du registre avec des noms aléatoires, et le processus malveillant fonctionne dans les processus légitimes (par exemple conhost.exe avec des paramètres qui tentent de le cacher). Le comportement final est celui d'un RAT en mémoire capable de se réécrire et d'exécuter dynamiquement le code distant., qui complique la détection par des signatures statiques.

Le composant qui donne une vraie valeur stratégique à cette opération est la résolution C2 par des contrats intelligents dans Etheum: le malware consulte publiquement plusieurs paramètres RPC d'Etheum pour lire la valeur stockée dans un contrat et donc obtenir l'URL du serveur de commande. En mettant à jour ces données uniques dans la chaîne, l'adversaire redirige toutes les infections sans toucher les binaires déployés. Cela transforme la chaîne de verrouillage en une goutte morte publique, hautement disponible et résistante aux blocs par domaine ou IP. Pour comprendre le mécanisme technique sous-jacent, la documentation sur les nœuds et les clients d'Etheum peut être consultée à éthéréum.org.

Les implications opérationnelles sont graves : en ciblant les outils qui n'utilisent que des utilisateurs ayant des permissions élevées, chaque infection a une forte probabilité de devenir des « clés du roi » au sein d'une organisation. En outre, la campagne privilégie la patience et la furtivité - exploitation post-manuelle, reconnaissance silencieuse et mouvements latéraux mesurés - ce qui augmente le risque d'accès prolongé et d'exfiltration dirigée.

La détection de cette menace nécessite un examen au-delà des indicateurs statiques. La télémétrie utile inclut l'émergence du nœud. exe processus qui exécutent des commandes système, conhost. exe publié avec des arguments inhabituels tels que "--sans tête", des écrits réguliers dans des fichiers de trace locaux (par exemple svchost.log in% APPDATA%), et le trafic sortant vers les services RPC publics Ethedium. L'examen des antécédents d'évacuation et des enregistrements DNS / HTTP vers les passerelles publiques RPC est essentiel pour découvrir les infections passées.

En ce qui concerne l'atténuation pratique, il convient d'appliquer des contrôles d'évacuation pour bloquer ou inspecter l'accès aux passerelles publiques de CPR utilisées pour consulter Etherium, de mettre en œuvre des politiques habilitantes pour les téléchargements de logiciels dans les stations administratives et de centraliser les sources de logiciels dans les catalogues internes ou les portails fournisseurs vérifiés. Le téléchargement dynamique de Node.js depuis son site officiel par l'installateur malveillant souligne la nécessité de restreindre les systèmes qui peuvent librement accéder à Internet pour récupérer des runtimes externes; par exemple, le site officiel de Node.js est nodejs.org mais son utilisation doit faire l'objet d'un contrôle et d'une surveillance dans le périmètre de l'entreprise.

Il est également recommandé de renforcer l'accès administratif avec segmentation du réseau, privilèges minimums, authentification multifactorielle solide et rotation fréquente des identifiants. Depuis la détection, les règles de l'EDR devraient chercher des modèles tels que les exécutions répétées et périodiques (toutes les ~ 5 minutes) à des paramètres inhabituels, anomalies parent-enfant où le noeud. exe invoque des shells, et la présence de clés Exécuter avec des noms générés au hasard. Ne pas déléguer la vérification des outils critiques à un simple résultat de recherche : encourager l'utilisation de dépôts internes signés et vérifiés.

En réponse et en coordination, les équipes défensives devraient combiner les actions techniques avec les fournisseurs et les plates-formes (par exemple, demander la suppression de dépôts malveillants à GitHub) et travailler avec les CSIRT et les autorités pour poursuivre l'infrastructure dans la mesure du possible. Toutefois, il faut reconnaître que le caractère décentralisé du vecteur C2 limite l'efficacité des contre-mesures traditionnelles et exige des mesures défensives en couches.

Sur l'attribution, il y a des rapports de chevauchement technique entre ce module "EtherHering" et les travaux antérieurs liés par différentes équipes aux acteurs étatiques. Toutefois, la réutilisation du code et des techniques entre les groupes est courante; les preuves techniques ne devraient pas à elles seules aboutir à des conclusions d'attribution hâtive sans un large ensemble de corroborations;.

Enfin, la communauté défensive devrait considérer ce cas comme un rappel que la chaîne d'approvisionnement humaine commence dans les moteurs de recherche et se termine dans la machine avec des privilèges. Adopter des contrôles télémétriques, limiter l'évacuation aux infrastructures décentralisées non supervisées et former le personnel administratif pour vérifier la source du logiciel sont des actions urgentes. Pour mieux comprendre les mesures de sécurité dans la chaîne d'approvisionnement des logiciels et collaborer à l'atténuation, le guide de GitHub sur la sécurité de la chaîne d'approvisionnement est un bon point de départ : Guide de sécurité de la chaîne d'approvisionnement GitHub. Dans les environnements où il y a des doutes sur les communications historiques, une analyse médico-légale du registre et une collaboration avec des équipes telles que le CSIRT et des fournisseurs de services de sécurité gérés seront essentielles pour contenir et éliminer cette menace.