Le 26 février 2025, l'équipe de réponse d'urgence (ERT) de Nokia Deepfield a observé une vague d'attaques DDoS hyper-volumétriques apparue « du jour au lendemain ». En remontant la piste, un botnet nommé Eleven11bot est apparu – une variante de Mirai qui infecte spécifiquement les caméras de surveillance, les DVR et les NVR à base de HiSilicon. Le 27 février, il a culminé à environ 6,5 Tbps, dépassant le record de 5,6 Tbps établi en janvier. Cet article décortique l'incident et la « guerre des périphériques de bord » qui le sous-tend.

1. Le fantôme de Mirai n'est pas parti

Eleven11bot n'est pas une nouvelle famille – c'est une variante de Mirai. Depuis l'open-sourcing de Mirai en 2016, son code a été réutilisé et fait évoluer par d'innombrables opérateurs. Cette fois, il a ciblé les appareils HiSilicon exécutant le logiciel de gestion vidéo TVT-NVMS9000, prenant le contrôle via des identifiants par défaut et des failles de firmware non corrigées. Il utilise un algorithme de scan raffiné pour trouver le Telnet (port 23) et le SSH (port 22) exposés, puis force avec des dictionnaires d'identifiants adaptés à des fournisseurs spécifiques (ex. VStarcam).

2. 6,5 Tbps et un « Rashomon numérique »

Le plus fascinant est le désaccord marqué sur la taille du botnet :

  • Nokia a estimé ~30 000 appareils infectés (États-Unis 24,4 %, Taïwan 17,7 %, Royaume-Uni 6,5 %).
  • Shadowserver a donné un chiffre supérieur à 86 000.
  • GreyNoise / Censys ont soutenu que les vraiment infectés sont probablement moins de 5 000 (61 % retracés vers l'Iran).

La racine du désaccord : une signature réseau mal interprétée. Le marqueur head[…]1111 vu dans le trafic a d'abord été traité comme un indicateur d'infection, puis attribué au comportement de protocole normal du SDK HiSilicon – un composant légitime de l'administration à distance dans le matériel IoT à marque blanche. Un rappel pour chaque chercheur : sur le champ de bataille IoT, « voir un appareil » n'est pas « l'appareil est infecté » ; mal interpréter les indicateurs fausse directement l'évaluation des risques.

3. Pourquoi l'IoT reste un vivier d'armement

Eleven11bot n'est pas isolé. En 2025, des CVE liées ont continué d'apparaître et d'être ignorées :

  • CVE-2024-32899 : RCE non authentifiée dans TVT NVMS – corriger immédiatement.
  • CVE-2024-6047 / CVE-2024-11120 : injection de commande dans des appareils IoT GeoVision abandonnés (EOL), toujours non corrigés des mois après la divulgation.
  • CVE-2025-1316 : zero-day d'injection de commande dans les caméras Edimax IC-7100, exploité dans la nature par des variantes de Mirai.

La logique sous-jacente est constante : prolifération massive des appareils (caméras, routeurs, téléviseurs intelligents, même les réfrigérateurs), identifiants par défaut et mauvaise hygiène des correctifs, et déploiements non surveillés. Ces appareils « s'enrôlent silencieusement » et convergent en énormes flottes d'attaque.

4. Le vrai risque : intensité et dommages collatéraux

L'intensité d'Eleven11bot allait de 100 000 à 500 millions de paquets par seconde (pps), ciblant les fournisseurs de télécoms, l'hébergement de jeux et la finance. Certaines attaques ont causé une dégradation de service durant des jours. Crucial : le trafic venait de milles d'ASN distincts – des nœuds véritablement mondiaux –, ce qui signifie que toute organisation dépendant de ces chemins peut devenir un dommage collatéral.

5. Défense : une responsabilité partagée

Pour les propriétaires d'appareils :

  • Désactiver l'administration à distance, changer les identifiants par défaut, mettre à jour le firmware des appareils HiSilicon.
  • Corriger les failles critiques comme TVT-NVMS9000 (CVE-2024-32899).
  • Activer la limitation de débit pour les protocoles comme DNS (UDP/53) et NTP (UDP/123).

Pour les réseaux et les défenseurs :

  • Utiliser des flux de renseignement sur les menaces comme GreyNoise (qui a identifié 1 042 IP malveillantes) et Shadowserver pour bloquer les IP malveillantes connues au niveau réseau.
  • Utiliser un SIEM pour signaler les tentatives de force brute sur Telnet/SSH et le trafic sortant anormal des appareils IoT.
  • Adopter le zero-trust – isoler caméras et enregistreurs du réseau métier.

Conclusion

La leçon d'Eleven11bot : la sécurité IoT n'est pas l'affaire d'une seule entreprise – c'est une responsabilité partagée des fabricants, des régulateurs, des praticiens de la sécurité et des consommateurs. Tant que d'énormes quantités d'appareils restent sur l'Internet public avec des identifiants par défaut et un firmware obsolète, ils continueront d'être armés. Pour les défenseurs, la vraie barrière contre cette guerre des périphériques de bord est une architecture qui identifie et détourne le trafic anormal de milliers d'ASN à la périphérie, en quelques secondes.