Attaques du botnet GoBruteforcer

Une nouvelle vague d'attaques GoBruteforcer cible activement les bases de données associées aux projets de cryptomonnaies et de blockchain. Les attaquants intègrent des serveurs vulnérables à un botnet distribué capable de mener des attaques par force brute à grande échelle contre des services courants tels que FTP, MySQL, PostgreSQL et phpMyAdmin sur les systèmes Linux.

Cette campagne n'est pas menée sans discernement. Les éléments disponibles montrent qu'elle cible clairement les infrastructures liées aux écosystèmes blockchain, ce qui reflète à la fois une motivation financière et la prolifération d'environnements de développement mal sécurisés dans ce secteur.

Pourquoi cette campagne prend de l’ampleur

Deux tendances convergentes alimentent la recrudescence actuelle. Premièrement, les administrateurs réutilisent de plus en plus les guides de déploiement et les exemples de serveurs générés par l'IA, dont beaucoup reproduisent les mêmes identifiants et noms d'utilisateur par défaut faibles que l'on retrouve dans les tutoriels et la documentation en ligne. Deuxièmement, les anciennes infrastructures web, notamment les installations XAMPP, continuent d'être déployées avec des services FTP exposés et des interfaces d'administration insuffisamment sécurisées.

Ensemble, ces conditions offrent aux attaquants une surface d'attaque prévisible et fertile.

Des origines de 2023 à une variante plus dangereuse en 2025

GoBruteforcer, également connu sous le nom de GoBrut, a été initialement documenté en mars 2023. Les premières recherches décrivaient une famille de logiciels malveillants basée sur le langage Go et conçue pour les systèmes de type Unix sur les architectures x86, x64 et ARM. Ce logiciel déployait un bot IRC pour le contrôle et la commande, installait un shell web pour un accès distant persistant et récupérait un module de force brute pour rechercher d'autres hôtes vulnérables.

En septembre 2025, les chercheurs ont découvert que certaines parties du botnet fonctionnaient en tandem avec une autre souche de logiciel malveillant, SystemBC, ce qui indique une infrastructure partagée ou un contrôle coordonné.

Le milieu de l'année 2025 a marqué un bond technique significatif. Les analystes ont identifié une variante plus avancée dotée d'un bot IRC fortement obscurci et réécrit en Golang, de mécanismes de persistance améliorés, de capacités de masquage des processus et de listes d'identifiants gérées dynamiquement et pouvant être mises à jour à la demande.

Stratégie d’identification façonnée par l’IA et les habitudes des développeurs

Le composant de force brute du logiciel malveillant repose sur des combinaisons soigneusement sélectionnées d'identifiants et de mots de passe courants, tels que « myuser:Abcd@123 » ou « appeaser:admin123456 ». Ces identifiants ne sont pas choisis au hasard. Nombre d'entre eux proviennent de tutoriels de bases de données, de documentations d'hébergement et d'exemples de fournisseurs — des ressources largement intégrées aux vastes corpus d'entraînement des modèles de langage. Par conséquent, les outils d'IA reproduisent fréquemment les mêmes valeurs par défaut dans les extraits de configuration générés, uniformisant ainsi involontairement les identifiants faibles d'un déploiement à l'autre.

D'autres noms d'utilisateur inclus dans la rotation font référence aux flux de travail liés aux cryptomonnaies (tels que « cryptouser », « appcrypto », « crypto_app » et « crypto ») ou ciblent spécifiquement les environnements phpMyAdmin, notamment « root », « wordpress » et « wpuser ».

Les attaquants conservent un pool de mots de passe relativement restreint et stable pour chaque campagne, actualisant les listes de mots de passe spécifiques à chaque tâche à partir de cette base tout en faisant tourner les noms d'utilisateur et en ajoutant des mots de passe ciblés plusieurs fois par semaine. Les attaques FTP sont traitées différemment : le programme d'attaque par force brute contient un ensemble d'identifiants codés en dur qui correspond étroitement aux configurations d'hébergement web et aux comptes de service par défaut.

La chaîne d’infection et les capacités des botnets

Les intrusions observées débutent généralement par une faille de sécurité dans un service FTP accessible depuis Internet sur un serveur XAMPP. Une fois l'accès obtenu, les attaquants téléchargent un shell web PHP. Ce shell est ensuite utilisé pour récupérer et exécuter un bot IRC mis à jour via un script shell adapté à l'architecture du système hôte.

Après compromission, un système infecté peut être réutilisé de plusieurs manières :

• Il exécute des modules de force brute pour tenter de se connecter aux services FTP, MySQL, PostgreSQL et phpMyAdmin sur Internet.
• Il héberge et distribue des charges utiles malveillantes aux machines nouvellement compromises.
• Il fournit des points de terminaison de commande et de contrôle de type IRC ou fonctionne comme serveur C2 de secours pour améliorer la résilience des botnets.

Preuves directes d’opérations axées sur la blockchain

Des investigations complémentaires ont révélé qu'au moins un serveur compromis exécutait un module spécialisé conçu pour parcourir une liste d'adresses de la blockchain TRON. Utilisant le service public tronscanapi.com, le logiciel malveillant interrogeait les soldes des comptes afin d'identifier les portefeuilles contenant des fonds non nuls. Cette capacité suggère fortement une reconnaissance délibérée ciblant les projets blockchain et l'infrastructure liée aux cryptomonnaies, plutôt qu'une simple analyse opportuniste.

Une leçon persistante pour les défenseurs

GoBruteforcer illustre une faille de sécurité plus vaste et persistante : la dangereuse convergence de services exposés, d’identifiants faibles ou réutilisés et d’outils d’attaque de plus en plus automatisés. Bien que le botnet en lui-même ne soit pas techniquement révolutionnaire, ses opérateurs tirent un profit considérable du grand nombre de serveurs mal configurés encore accessibles sur Internet.

Pour les équipes de défense, cette campagne réaffirme un message familier mais crucial : éliminer les identifiants par défaut, restreindre les interfaces d’administration, mettre hors service les anciennes architectures et considérer les exemples de déploiement générés par l’IA comme des points de départ non fiables plutôt que comme des configurations prêtes pour la production.