Evooo1Bot cible routeurs et caméras pour en faire des proxies SOCKS5

Evooo1Bot : Mirai évolue et transforme vos équipements en infrastructure d'attaque

À la mi-août 2026, les chercheurs de Fortinet FortiGuard Labs publient l'analyse d'un botnet Linux jusque-là non documenté qu'ils baptisent Evooo1Bot, d'après la chaîne de caractères « evooo1 » retrouvée codée en dur dans chaque binaire du malware. Le botnet est actif depuis juillet 2026 et cible activement les équipements réseau exposés sur Internet à travers plusieurs régions du monde, avec une concentration particulière sur l'Europe, l'Asie-Pacifique et l'Amérique du Nord. Son mode opératoire est double : d'un côté, convertir les machines infectées en relais SOCKS5 permettant d'anonymiser le trafic malveillant, de l'autre, les enrôler dans une infrastructure de déni de service distribué (DDoS) capable de lancer seize méthodes d'attaque distinctes sur les protocoles DNS, TCP et UDP.

Le code d'Evooo1Bot est issu du code source de Mirai, publiquement disponible depuis sa fuite en 2016. Mirai reste à ce jour la base la plus populaire pour construire des botnets IoT, en raison de son efficacité éprouvée pour compromettre des appareils Linux embarqués. Mais Evooo1Bot va bien au-delà de ses ancêtres : aux côtés du moteur DDoS hérité de Mirai, le malware intègre des communications C2 chiffrées, un scanner SSH par force brute, un module SOCKS5, un sniffer de credentials, et un arsenal d'exploitation de vulnérabilités ciblant huit failles distinctes. Cette combinaison en fait une plateforme d'attaque multirôle, nettement plus polyvalente que les botnets Mirai classiques.

Les équipements ciblés sont des appareils edge exposés sur Internet : pare-feu d'entreprise, routeurs SOHO, caméras IP et RTU industriels. FortiGuard Labs identifie des tentatives d'exploitation dirigées contre des équipements de marques Alcatel, NETGEAR, Tenda, Mitsubishi Electric, Telesquare et D-Link. Les vecteurs d'accès initial sont doubles : exploitation de vulnérabilités connues (CVE) et tentatives de connexion SSH par force brute avec des listes de credentials par défaut. Les huit CVE exploitées couvrent un large spectre temporel, de 2021 à 2025, illustrant le fait que de nombreux équipements restent déployés sans jamais recevoir leurs mises à jour de sécurité : CVE-2021-36260 sur les caméras Hikvision, CVE-2022-26134 sur Atlassian Confluence, CVE-2022-29464 sur WSO2, CVE-2022-30525 sur les produits Zyxel, CVE-2023-1389 sur TP-Link, CVE-2024-4577 sur PHP, CVE-2024-10914 sur D-Link, et CVE-2025-1974 sur Kubernetes Ingress NGINX.

Le module SOCKS5 est l'une des fonctionnalités les plus préoccupantes d'Evooo1Bot, car il étend considérablement la valeur des appareils compromis au-delà des seules attaques DDoS. En mode direct, le bot ouvre un listener SOCKS5 sur le port TCP 1080, permettant à l'opérateur de router son propre trafic via l'appareil infecté. En mode inversé, le bot établit des connexions sortantes chiffrées vers un serveur relais contrôlé par l'attaquant, permettant au trafic de transiter via la victime sans exposer de port d'écoute vers Internet. Cette technique de proxy inverse est particulièrement difficile à bloquer avec des règles de pare-feu standard, car la connexion est initiée depuis l'intérieur du réseau. Un routeur ou une caméra IP compromise peut ainsi servir de point de rebond pour des campagnes de phishing, des accès frauduleux à des services cloud, ou pour masquer l'origine géographique réelle d'autres attaques.

Le sniffer de credentials intégré intercepte les en-têtes HTTP Basic Authorization et les cookies de session transitant par l'équipement infecté. Pour un routeur SOHO situé au cœur d'un réseau d'entreprise ou d'un établissement de santé, cette capacité peut permettre de collecter des identifiants utilisés pour accéder à des applications web internes, des VPN, ou des interfaces d'administration. Les RTU industriels ciblés sont particulièrement préoccupants dans un contexte OT/SCADA : ces équipements, souvent connectés à des systèmes de contrôle industriel, sont rarement mis à jour et présentent des surfaces d'attaque élargies par rapport aux équipements IT classiques.

Outre ses capacités offensives, Evooo1Bot dispose de fonctions de gestion complète de l'équipement infecté : installation de mécanismes de persistance, mise à jour du binaire malveillant, terminaison forcée du bot, upload et download de fichiers, et ouverture de shells interactifs. L'opérateur peut déclencher à distance les attaques DDoS sur une cible spécifiée, lancer le scanner SSH sur de nouvelles plages d'adresses IP, ou pivoter entre les modes de proxy. Cette richesse fonctionnelle en fait une plateforme d'attaque potentiellement commercialisable sur les marchés cybercriminels, où les accès à des réseaux de proxies compromis se vendent par abonnement.

Le lien entre Evooo1Bot et les attaques DDoS ayant perturbé Threema les 13 et 14 août 2026 n'est pas formellement établi par FortiGuard Labs, mais les chronologies sont cohérentes. La messagerie sécurisée suisse avait connu jusqu'à quatre heures d'indisponibilité complète le soir du 13 août, suivies d'interruptions intermittentes le 14 août, avant le rétablissement complet du service à 12h23. Threema avait alors précisé que l'attaque ciblait simultanément son infrastructure et celle de son partenaire d'hébergement Nine, avec des changements constants de pattern rendant la défense particulièrement complexe. La société a depuis déployé un mécanisme supplémentaire de filtrage DDoS en amont de son infrastructure principale, positionnant les protections plus loin dans la chaîne réseau.

L'ampleur géographique du botnet reste difficile à quantifier précisément, les données de télémétrie de FortiGuard Labs n'ayant pas été intégralement rendues publiques. Toutefois, le fait que les cibles incluent des RTU Mitsubishi Electric — couramment déployés dans des infrastructures industrielles et de distribution d'énergie — soulève des inquiétudes particulières pour les opérateurs de systèmes critiques. La présence de CVE-2025-1974 (Kubernetes Ingress NGINX) dans l'arsenal du botnet élargit également son périmètre potentiel aux infrastructures cloud-native, ce qui est inhabituel pour un botnet d'origine Mirai traditionnellement centré sur les équipements IoT embarqués.

La persistance du problème Mirai : pourquoi les botnets IoT ne disparaissent pas

Dix ans après la fuite du code source de Mirai en septembre 2016, ses descendants continuent de proliférer parce que les conditions structurelles qui les ont rendus possibles n'ont pas fondamentalement changé. Des millions d'équipements edge — routeurs, caméras, capteurs IoT — sont déployés avec des credentials par défaut ou sans possibilité pratique de mise à jour firmware. Leurs fabricants ne proposent pas toujours de mécanismes de patch automatique, et leurs utilisateurs, souvent non-techniciens dans les environnements SOHO, n'ont ni la connaissance ni le temps d'appliquer manuellement des correctifs de sécurité. La surface d'attaque pour un botnet comme Evooo1Bot est donc structurellement massive et auto-renouvelée par chaque nouvel équipement connecté sans durcissement préalable.

L'ajout du module SOCKS5 marque une évolution importante par rapport aux botnets Mirai de première génération, exclusivement orientés DDoS. Cette fonctionnalité de proxy transforme un équipement compromis en un actif durable pour les attaquants, bien au-delà d'une simple participation à des attaques volumétriques. Les réseaux de proxies résidentiels et commerciaux illégaux alimentés par des botnets IoT sont devenus un marché criminel à part entière, vendant des accès à des proxies compromis pour quelques dollars par heure sur des forums spécialisés. Evooo1Bot s'inscrit dans cette logique d'économie criminelle diversifiée, où chaque équipement compromis représente un actif valorisable selon plusieurs usages : DDoS, proxying, credential harvesting.

Pour les équipes de sécurité des entreprises, la gestion des équipements edge représente un angle mort fréquent. Contrairement aux serveurs et postes de travail, les routeurs et caméras IP échappent souvent aux inventaires d'actifs formels, aux politiques de patch management et aux outils de détection EDR. Des initiatives comme les nouvelles exigences de cybersécurité pour les équipements connectés introduites par la directive NIS2 et le règlement européen sur la cyber-résilience (CRA) visent à forcer les fabricants à intégrer la sécurité dès la conception. Mais ces réglementations produisent leurs effets sur les nouveaux équipements, laissant le parc installé existant largement exposé pour encore plusieurs années.

La présence de CVE-2025-1974 (Kubernetes Ingress NGINX) dans l'arsenal d'Evooo1Bot mérite une attention particulière des équipes DevOps et cloud. Cette vulnérabilité, qui affecte les configurations Kubernetes exposant leur contrôleur Ingress NGINX sur Internet, élargit le périmètre potentiel du botnet au-delà des équipements réseau traditionnels, vers les infrastructures cloud-native modernes. Les clusters Kubernetes non correctement segmentés ou dont le contrôleur Ingress est accessible depuis l'extérieur pourraient se retrouver compromis aux côtés de caméras IP et routeurs SOHO, dans un même réseau de proxies illicite.

Ce qu'il faut retenir

• Evooo1Bot exploite 8 CVE connues (de 2021 à 2025) pour compromettre routeurs, pare-feu, caméras IP et RTU industriels et les convertir en proxies SOCKS5 et bots DDoS.
• Le module SOCKS5 en mode inversé est particulièrement difficile à bloquer et permet de masquer l'origine des attaques en routant le trafic via des équipements légitimes compromis.
• Actions prioritaires : patcher les équipements exposant les 8 CVE concernées, désactiver SSH depuis Internet sur tous les équipements edge, segmenter les réseaux OT/IoT, et surveiller les logs SSH pour détecter des tentatives de force brute.