Accueil Automatisation SSHStalker, un botnet « à l’ancienne » dopé à l’automatisation

SSHStalker, un botnet « à l’ancienne » dopé à l’automatisation

SSHStalker botnet Linux flare

Découvert par l’équipe de recherche de Flare, SSHStalker illustre une tendance préoccupante : l’alliance de techniques de commande et de contrôle héritées des années 2000 avec des mécanismes d’automatisation capables de compromettre massivement des serveurs Linux. Derrière une architecture volontairement frugale, un pipeline d’infection redoutablement efficace et une résilience conçue pour durer.

Une architecture C2 « old school » pour une efficacité maximale

À rebours des campagnes ultra-furtives et sophistiquées qui dominent aujourd’hui l’actualité, SSHStalker s’appuie sur un socle éprouvé : l’Internet Relay Chat (IRC) pour piloter ses bots. Une approche robuste, peu coûteuse et historiquement associée aux botnets des années 2009–2010.

L’analyse de Flare met en lumière l’usage de variantes classiques de malwares développées en C et Perl, ainsi que des familles comme Tsunami ou Keiten, afin d’assurer une redondance des canaux de communication. Cette hybridation entre codes anciens et logiques modernes permet au botnet de conserver une infrastructure simple tout en limitant les coûts opérationnels.

Mais la nostalgie s’arrête à la couche C2. L’exécution, elle, relève d’une industrialisation assumée.

Un pipeline d’infection automatisé et une persistance agressive

SSHStalker enchaîne les étapes avec une logique quasi industrielle. Un scanner SSH développé en Golang identifie les cibles, puis le kit procède à l’installation rapide d’outils de compilation, notamment GCC, afin de générer et d’exécuter des binaires directement sur les hôtes compromis.

Cette capacité à compiler sur la machine infectée renforce la flexibilité de l’attaque et complique la détection basée sur des signatures statiques. Le botnet intègre également un mécanisme de surveillance via des tâches cron exécutées chaque minute. Si un processus malveillant est stoppé, il redémarre en moins de soixante secondes. La résilience est intégrée au cœur du dispositif.

Pour masquer son activité sur les canaux IRC, SSHStalker exploite le framework EnergyMech afin de générer un bruit conversationnel simulant une activité humaine. Ce camouflage comportemental ajoute une couche d’opacité à un système déjà conçu pour durer.

7 000 cibles repérées et l’angle mort des infrastructures legacy

En janvier 2026, les chercheurs de Flare ont identifié près de 7 000 résultats issus d’un scanner SSH, principalement associés à des fournisseurs de cloud tels qu’Oracle Cloud Infrastructure. Le botnet dispose de 81 artefacts d’exploitation couvrant 16 CVE distinctes visant majoritairement les noyaux Linux 2.6.x datant de 2009–2010.

Ces vulnérabilités sont obsolètes pour les environnements récents. Pourtant, elles concerneraient encore entre 1 % et 3 % des serveurs Linux exposés sur Internet. La proportion grimpe à 5 % voire 10 % dans les environnements legacy, les appareils industriels ou les serveurs VPS laissés à l’abandon. SSHStalker cible ainsi une surface d’attaque souvent négligée : l’infrastructure « oubliée ».

Observé dans une phase de persistance dormante, le botnet n’en demeure pas moins doté d’un arsenal complet. Il est capable de miner des cryptomonnaies, vraisemblablement Ethereum Classic, de collecter des identifiants AWS via un scanner HTTP/HTTPS ciblant plus de 33 000 chemins de fichiers, ainsi que de mener des attaques DDoS et d’assurer une propagation autonome de type ver.

Sur le plan structurel, SSHStalker présente des similitudes avec des botnets historiques tels qu’Outlaw ou Maxlas, sans qu’aucun indicateur technique direct ne permette une attribution formelle. La présence d’argot, de pseudonymes et de commentaires en roumain dans le code suggère toutefois un opérateur dérivé ou un copycat issu de cet écosystème.

Flare recommande une vigilance accrue sur l’usage inhabituel de compilateurs comme GCC ou make sur les serveurs de production, le blocage des connexions IRC sortantes non justifiées et la désactivation de l’authentification SSH par mot de passe au profit de l’authentification par clé.