SSHStalker Le retour de IRC dans l'âge des botnets Linux

La cybersécurité semble parfois être une boucle temporaire : des techniques et des protocoles qui semblaient relégués au passé réapparaissent avec de nouvelles victimes. C'est précisément le cas du nouveau botnet documenté que les chercheurs ont baptisé SSHStalker, une infrastructure malveillante pour Linux qui repose sur un classique de la communication Internet: IRC, le vétéran Internet Relay Chat.

Le CRI est né à la fin des années 80 et, dans les années 90, a été la principale forme de messagerie textuelle pour les groupes et les conversations privés. Aujourd'hui encore, les communautés techniques apprécient leur simplicité, leur interopérabilité et leur faible consommation de bande passante - caractéristiques qui, paradoxalement, le rendent attrayant également pour les opérateurs de malwarts qui recherchent la robustesse et le faible coût dans leurs canaux de contrôle. Pour comprendre le protocole sous sa forme originale, voir le document historique. RFC 1459 et un aperçu Wikipédia.

L'analyse de l'équipe de renseignement de Flare montre que SSHStalker n'est pas destiné à être innovant dans les techniques furtives; plutôt, il est engagé à l'évolutivité et la résistance. Au lieu de cadres C2 modernes, malware déploie plusieurs robots écrits en C, compte sur des serveurs et canaux IRC redondants et utilise des stratégies bruyantes telles que des scans SSH massifs et des tâches programmées à chaque minute pour maintenir la présence. Les détails du rapport sont disponibles dans l'analyse publiée par Flare Voilà..

La chaîne d'infection commence par un binaire écrit en Go qui passe à travers l'outil de découverte réseau nmap ; ce remplacement facilite la transmission de l'échantillon sans être remarqué initialement dans les environnements où nmap est habituel. Après avoir obtenu l'accès à la force brute par SSH, l'équipe d'attaque utilise les équipes engagées pour continuer à explorer et à compromettre d'autres serveurs, un comportement qui rappelle la dynamique d'un ver. Pour ceux qui veulent comparer, la page officielle nmap sert de référence pour l'utilité légitime : nmap.org.

Une fois à l'intérieur, SSHStalker télécharger des outils de compilation - en particulier GCC - pour compiler vos binaires directement dans l'hôte infecté. Cette technique assure la portabilité entre les architectures et peut aider à échapper à certaines défenses basées sur la signature. Les premiers binaires qu'il déploie sont les robots IRC C, avec des serveurs et canaux C2 chiffrés, puis force le téléchargement de paquets supplémentaires (appelés dans la recherche comme GS et bootbou) qui contiennent des variantes de bot pour l'orchestration et l'exécution des tâches.

Pour persister dans les systèmes compromis, le botnet utilise des tâches cron qui fonctionnent toutes les 60 secondes. Ce mécanisme agit comme un gardien : il vérifie que le processus principal est actif et réagit s'il est terminé. En parallèle, l'ensemble comprend des kits d'exploitation qui profitent des vulnérabilités du noyau Linux de la période 2009-2010 à l'échelle des privilèges lorsque l'intrusion initiale n'a accès qu'en tant qu'utilisateur peu fiable. La base de données NIST (NVD) est une bonne ressource pour consulter les détails sur les vulnérabilités historiques : nvd.nist.gov.

En termes de monétisation et de capacités opérationnelles, Flare a détecté des lièvres d'identités et des clés AWS, des scans web et la présence de kits de cryptométrie - y compris des outils connus pour leurs performances en Ethedium - ainsi que des modules pour les attaques DDoS. Cependant, les chercheurs soulignent que jusqu'à présent les robots sont connectés au C2 et entrent dans un état largement inactif, suggérant que les opérateurs pourraient tester l'infrastructure ou accumuler des accès avant de les mettre en utilisation malveillante.

Dans la télémétrie examinée par Flare, les scans sont principalement dirigés vers les fournisseurs de cloud, avec une concentration visible dans l'infrastructure Oracle Cloud. L'équipe n'a pas attribué de façon concluante le travail à un acteur particulier, bien qu'elle note des similarités techniques avec les écosystèmes précédents de botnet et certains indicateurs avec des liens géographiques possibles.

Face à de telles menaces, des recommandations pratiques visent à augmenter le coût de l'intrusion et à réduire la zone exploitable. Les mesures recommandées par les spécialistes comprennent la désactivation de l'authentification par mot de passe en SSH et l'utilisation de clés publiques, la suppression des compilateurs et des outils de développement d'images de production pour empêcher la compilation sur place, le filtrage du trafic pour bloquer les connexions C2 (y compris les modèles de type IRC) et la restriction de l'exécution à partir d'espaces comme / dev / shm. En outre, il convient d'établir des détections qui alertent les installations ou les exécutions de compilateurs sur des serveurs productifs et de cron des emplois avec des cadences très courtes créées sur des itinéraires inhabituels.

Des guides de durcissement SSH pratiques et officiels sont disponibles dans les références techniques et les manuels OpenSSH : Manuel OpenSSH et l'enseignement d'articles de fournisseurs d'infrastructure qui détaillent comment configurer l'authentification des clés et d'autres mesures, par exemple dans DigitalOcean: Comment configurer les clés SSH. En ce qui concerne les politiques de filtrage des réseaux et des sorties, les recommandations de contrôle de la sécurité se retrouvent souvent dans des organisations comme le Center for Internet Security (CIS) et dans la documentation des fournisseurs de cloud.

SSHStalker est un rappel qui ne gagne pas toujours celui qui innove plus technologiquement, mais qui optimise une recette éprouvée : des outils simples, le codage de lumière, la redondance et l'automatisation de masse. Pour les responsables de la sécurité et l'équipement, la leçon est double : d'une part, s'occuper de l'hygiène de base des images d'accès et de production ; d'autre part, mettre en œuvre des détections qui pointent sur des modèles précédemment considérés comme « bruyants » - cron chaque minute, compilateurs apparaissant sur des serveurs, connexions sortantes aux ports et aux modèles IRC - parce que ce bruit peut aujourd'hui être le signal d'un botnet qui construit votre armée.

Si vous souhaitez approfondir les résultats techniques et les échantillons analysés, le rapport Flare fournit une ventilation détaillée des indicateurs de détection et de réponse: Vieille école CRI, nouvelles victimes - Flare.