Faux outils de sécurité sur GitHub : 2 000 machines Windows compromises
Une campagne active depuis deux ans, qui visait à l'origine les propriétaires de portefeuilles de cryptomonnaies, s'intéresse désormais à ceux qui analysent les malwares. Selon les recherches publiées par Doctor Web (Dr.Web) le 5 novembre, plus de 2 000 systèmes Windows ont été compromis via des dépôts GitHub malveillants qui se présentent comme des outils de sécurité. Les leurres ne sont pas grossiers : ils comprennent un analyseur, nettoyeur et formateur pour la sortie du scanner réseau Fscan, des dépôts pour l'automatisation de scans et les tests de sécurité, ainsi que des utilitaires de traitement de journaux.
Un leurre destiné à ceux qui devraient savoir
Le changement de cible est le point notable. Selon Dr.Web, les premiers dépôts infectés sont apparus il y a environ deux ans et tournaient autour de jeux blockchain, de bots et d'outils de triche, avec du code malveillant caché dans des fichiers de projet Visual Studio. La vague actuelle conserve la même mécanique de livraison mais change l'emballage pour quelque chose qu'un analyste clonerait plausiblement pendant une journée de travail. Les dépôts incluent même des instructions pour installer Visual Studio et cloner le projet, ce qui abaisse la barrière pour les utilisateurs moins expérimentés. La chronique de BleepingComputer note que l'opération dure depuis environ deux ans.Où se cache le code
La logique malveillante ne se trouve pas dans la partie du dépôt qu'un relecteur lirait normalement. Dans les fichiers .csproj, elle réside dans une routine PreBuildEvent qui s'exécute avant la compilation du projet. Dans les fichiers .suo, que la plupart considèrent comme un état d'éditeur jetable, elle arrive sous forme de commande PowerShell. Dans les sources Go et Python, un échantillon s'appelle FscanOutput_v2.2.py, le code est repoussé derrière de longues séries d'espaces, une vieille astuce qui selon Dr.Web fonctionne toujours. Cette première étape, détectée comme PowerShell.Packed.270, est écrite dans des chemins tels que C:\Users\Public\Pictures\t.ps1 et déchiffre un lien de téléchargement vers une archive nommée Quixo.7z, qui se décompresse dans C:\ProgramData\Windows.Microsoft.Photos.Microsoft.exe est une application Electron
L'archive livre Microsoft.exe, détecté comme Trojan.Loader.3261 et construit sur Electron. Il est modulaire, versionné (1.4.5 au moment du rapport) et se comporte comme un produit maintenu : il télécharge un second paquet chiffré, Nexara.7z, envoie des informations système à un bot Telegram, établit sa persistance, tente d'élever ses privilèges et désactive Windows Defender, l'UAC, les notifications, la restauration du système et le service de clichés instantanés, tout en ajoutant des exclusions Defender. Il injecte ensuite les étapes suivantes dans des processus légitimes, dont RegAsm.exe, dwwin.exe et dwm.exe.Cette analyse montre clairement que cette attaque représente une menace sérieuse même pour des utilisateurs avertis, y compris des professionnels de la sécurité de l'information. - Dr.Web
Deux modes d'évasion et une solution de repli
Le loader embarque plusieurs moyens d'échapper à l'inspection. Dr.Web décrit un chemin principal Mode3 et un repli Mode2 :- Usurpation de explorer.exe comme processus parent du loader.
- Désactivation de Smart App Control en modifiant la valeur de registre VerifiedAndReputablePolicyState.
- Rechargement de ntdll.dll depuis le disque pour supprimer les hooks des produits de sécurité, et appels système directs via Halo's Gate.
- Patch en mémoire de EtwEventWrite et AmsiScanBuffer pour aveugler le traçage d'événements et l'analyse de scripts pour ce processus.
- Repli sur des exclusions Defender pour regasm.exe et dwm.exe, puis déchiffrement et injection de modules via PowerShell si le chemin principal échoue.
Ce que collectent les charges utiles
Les étapes finales sont une porte dérobée, un détourneur de presse-papiers et un voleur d'informations. Deux copies de BackDoor.AsyncRAT.115 sont injectées sur des ports différents, ce qui selon Dr.Web permet à deux opérateurs de contrôler la même machine simultanément. Trojan.InjectNET.14 dépose Trojan.Clipper.688 dans regasm.exe pour remplacer les adresses de portefeuilles crypto dans le presse-papiers, et renvoie des captures d'écran et des détails sur la machine via Telegram. JS.Stealer.191 vérifie la présence de bacs à sable et de machines virtuelles avant de collecter les données de navigateurs, les profils XML FileZilla, MobaXterm.ini, le wcx_ftp.ini de Total Commander, les paramètres VPN, les fichiers de messagerie, les comptes de jeux et les jetons Discord. Les données sont compressées et envoyées via le même bot Telegram.Retirer le filet de sécurité
Le loader tente aussi de désinstaller ESET, McAfee et Malwarebytes, et inscrit des domaines d'éditeurs d'antivirus dans le fichier hosts pour couper ces produits de leurs serveurs de mise à jour. Il supprime tout le contenu de system32\drivers\etc sauf une courte liste blanche, ce que Dr.Web explique par la volonté d'empêcher l'utilisateur de créer et d'utiliser des sauvegardes. Du code inutilisé dans l'échantillon indique un autre composant, un projet Electron inachevé nommé WUDFHost.exe, qui pourrait créer un service pour la persistance et retélécharger Microsoft.exe s'il est supprimé.Pourquoi le copier-coller d'outils est un problème de chaîne d'approvisionnement
Rien de tout cela n'exige une faille zero-day ni un exploit astucieux. Il faut une personne avec une échéance, un moteur de recherche et un dépôt qui ressemble assez à ce dont elle a besoin. Les outils de sécurité y sont particulièrement exposés parce que beaucoup sont petits, écrits par un seul auteur et distribués sous forme de code source que l'on est censé exécuter. Un analyseur de sortie de scanner est exactement ce qu'un analyste télécharge, survole et exécute. La même logique vaut pour tout binaire obtenu par un lien : la provenance compte davantage que l'apparence d'utilité du fichier. Notre guide pour vérifier les téléchargements via Tor détaille les habitudes de sommes de contrôle et de signatures qui rendent ce type de substitution plus difficile.Habitudes pratiques
Quelques vérifications auraient arrêté cette chaîne à plusieurs endroits :- Lire les hooks de compilation. Un PreBuildEvent, un script postinstall ou une étape de Makefile qui appelle PowerShell est du code, pas de la configuration.
- Compiler les outils depuis un commit figé et comparer ce commit à celui que l'on a relu.
- Exécuter les outils inconnus dans une machine virtuelle jetable, sans partage de presse-papiers ni montage de l'hôte.
- Traiter les fichiers .suo, .user et autres états d'éditeur comme du contenu exécutable, car dans cette campagne ils l'étaient.
- Se méfier des dépôts qui fournissent des instructions d'installation destinées aux débutants ; c'est une stratégie de diffusion, pas une politesse.










