Les boîtiers Android TV et les décodeurs doivent être contrôlés après que Unit 42 a identifié Kimwolf v7, une variante de botnet Android/IoT qui vise principalement ces appareils. La première vérification est ciblée : déterminer si ADB est activé, puis si le port 5555 reste accessible sans authentification depuis le réseau local.
Commencez par inventorier les appareils
Listez tous les boîtiers Android TV et décodeurs connectés au réseau, y compris ceux qui sont rarement utilisés. Pour chacun, notez l’emplacement, le propriétaire et la fonction. Cet inventaire servira à relier un résultat de test à un appareil précis et à distinguer un équipement multimédia connu d’un système Android inattendu.
Sur chaque appareil, vérifiez d’abord dans les réglages disponibles si ADB est activé. Lorsque l’adresse réseau du boîtier est connue, testez ensuite l’accessibilité du port 5555 depuis un appareil autorisé du même réseau local. Consignez séparément les deux résultats : ADB activé ou désactivé, port 5555 accessible ou non.
Cette séquence est importante. Un port 5555 accessible indique une configuration à risque, mais ne prouve pas que le boîtier est infecté. Selon Unit 42, Kimwolf se propage en utilisant des services de proxy résidentiel pour atteindre des instances ADB Android non authentifiées sur les réseaux locaux. Certains boîtiers exposent ADB sur le port 5555, ce qui permet une installation sans authentification une fois le tunnel proxy établi.
Désactivez ADB, puis vérifiez le résultat
Si ADB n’est pas nécessaire au fonctionnement habituel du boîtier, désactivez-le dans les réglages disponibles. Si l’appareil sert au développement ou à une autre tâche qui exige ADB, limitez son accès au plus petit réseau de confiance et imposez une authentification lorsque le boîtier le permet.
Après la modification, reprenez exactement le même contrôle depuis le réseau local : vérifiez l’état d’ADB, puis l’accessibilité du port 5555. Le résultat attendu pour un appareil qui ne doit pas exposer ADB est un service désactivé et un port qui n’est plus accessible. Si ADB reste actif ou si le port répond encore, ne considérez pas l’intervention comme terminée et corrigez la configuration disponible sur l’appareil.
Le fait qu’un boîtier soit derrière une connexion domestique ou professionnelle ne justifie pas de laisser un service ADB sans authentification accessible. Conservez l’état avant et après la modification, ainsi que l’heure du second contrôle : ces éléments permettent de vérifier que la correction concerne bien le boîtier inventorié.
Un port exposé n’est pas un diagnostic d’infection
Kimwolf v7 ne se résume pas à un symptôme visible sur l’écran du boîtier. Unit 42 indique que le binaire contient cinq points d’accès RPC publics Ethereum codés en dur pour résoudre les domaines ENS utilisés afin d’obtenir les adresses de commande et de contrôle. Lorsque la résolution ENS échoue, il bascule vers un service caché Tor v3 codé en dur.
Tout le trafic de commande et de contrôle passe par un proxy local à l’adresse 127.0.0[.]1:23075, que la destination utilise l’Internet classique ou Tor. Ces éléments peuvent orienter une enquête, mais ils ne permettent pas de considérer comme malveillantes toutes les connexions Tor ou toutes les recherches liées à Ethereum.
Recherchez plutôt une combinaison de signaux : un service ADB exposé, une application ou un binaire inattendu, ainsi qu’une activité réseau impossible à expliquer par l’usage prévu de l’appareil. Aucun de ces éléments ne suffit seul. Le rôle du boîtier et la chronologie des événements doivent aussi être examinés avant de conclure.
Actualisez les indicateurs réseau
La variante ajoute une attaque DDoS par inondation HTTP/2 qui construit des empreintes complètes de navigateur. Son trafic peut ainsi être plus difficile à distinguer de requêtes de navigation légitimes. Unit 42 décrit également une table de dispatch prenant en charge 15 méthodes DDoS sur les couches 3 à 7 du modèle OSI, même si les cas 8, 11 et 13 n’apparaissent pas dans l’instruction switch.
Pour un foyer, un boîtier infecté peut dégrader la fiabilité de la connexion locale ou participer à des attaques sans afficher de problème évident à l’écran. Dans une entreprise ou une propriété administrée, un trafic sortant répété, une consommation de bande passante inexpliquée ou un appareil qui devient instable doivent conduire à comparer l’inventaire avec les journaux réseau.
Ne supposez pas que les anciens indicateurs de Kimwolf couvrent cette version. Par rapport aux versions précédentes, v7 a supprimé les fonctions de balayage, d’exploitation et de force brute. Cette évolution réduit les comportements attribués par Unit 42 à cet échantillon, mais ne rend pas sûr un service ADB exposé : le mode de propagation rapporté vise toujours un accès de débogage Android sans authentification.
Placez les événements dans leur chronologie
Unit 42 a découvert la variante le 3 février 2026, lors d’une opération de threat hunting. Son analyse de l’infrastructure a relié 22 adresses IP partageant la même clé SSH entre le 18 décembre 2025 et le 3 février 2026. Les hôtes regroupés appartenaient à l’AS202799 et étaient géolocalisés à Saint-Pétersbourg, en Russie.
Ces observations concernent l’infrastructure examinée par Unit 42. Elles ne prouvent pas que chaque connexion issue de ces lieux soit liée à Kimwolf. Conservez donc les dates avec les journaux locaux : un événement antérieur à l’enquête n’est pas automatiquement sans rapport, et un événement postérieur au 3 février n’est pas automatiquement lié à Kimwolf. L’identité de l’appareil, son exposition ADB, le calendrier et le comportement observé doivent correspondre avant de retenir une conclusion plus ferme.
Que faire si un appareil reste préoccupant ?
- Retirez le boîtier suspect du réseau ou placez-le dans un segment isolé afin qu’il ne puisse plus établir de connexions inexpliquées.
- Notez les détails de l’appareil, l’heure de son isolement et l’exposition ADB observée sur le réseau.
- Conservez les journaux pertinents avant d’effacer ou de remplacer l’appareil lorsqu’une enquête peut être nécessaire.
- Désactivez l’ADB sans authentification sur les autres boîtiers Android TV et décodeurs, puis répétez le contrôle du port.
- Ne reconnectez un appareil qu’après avoir examiné son état logiciel et son comportement réseau en suivant la procédure disponible pour son propriétaire ou son administrateur.
Le 19 mars 2026, Unit 42 a rapporté que le ministère américain de la Justice et des partenaires internationaux avaient annoncé une opération autorisée par un tribunal. L’infrastructure de commande et de contrôle utilisée par les botnets Aisuru, KimWolf, JackSkid et Mossad avait été saisie lors de cette opération. Ce contexte ne remplace pas le contrôle des appareils locaux : un boîtier doit toujours être évalué à partir de sa configuration et de ses journaux.
Unit 42 a également identifié eth[.]rpcuniverse[.]com comme un sixième point d’accès RPC évalué avec un niveau de confiance modéré comme contrôlé par les opérateurs, tout en précisant que la propriété du domaine n’avait pas pu être confirmée. Utilisez cette information comme une piste d’enquête, et non comme une confirmation autonome.
La décision immédiate est simple : mesurer l’état d’ADB et du port 5555, désactiver le service lorsqu’il n’est pas nécessaire, puis refaire le même test. Si l’exposition disparaît mais que des fichiers, applications ou connexions restent inexpliqués, poursuivez l’examen à partir de l’inventaire, de la chronologie et des journaux réseau plutôt que de conclure à partir d’un seul indicateur.