Des botnets cachent leurs serveurs de commande derrière des noms Ethereum

Un serveur de commande ne sert à rien si les appareils infectés ne le trouvent pas. Pendant des années, cette recherche passait par un nom de domaine. Un registraire, ou un tribunal, peut saisir le domaine, et le botnet se tait jusqu’à ce que l’exploitant en enregistre un autre. Certains ont déplacé la recherche sur Ethereum, où le nom est contrôlé par une clé qu’ils détiennent, et où n’importe qui peut lire l’enregistrement, mais presque personne ne peut le modifier.

Le service de noms Ethereum

L’Ethereum Name Service (ENS) est un système de noms sur la chaîne de blocs Ethereum. Un nom comme example.eth n’est pas un site web et n’est pas un nom DNS. Le DNS ordinaire est un annuaire tenu par des registres et des registraires : des entreprises qui peuvent suspendre un nom quand un tribunal le leur ordonne. Un nom ENS est un enregistrement sur Ethereum, détenu par une adresse. Quiconque possède la clé privée de cette adresse peut changer ce vers quoi le nom pointe. Un registraire ne le peut pas.

Le nom a des parties, et le logiciel malveillant en utilise deux.

Un résolveur est un contrat intelligent, un petit programme stocké sur Ethereum, qui répond aux questions sur le nom. L’une de ces questions est un registre de texte : une chaîne étiquetée que le propriétaire peut régler à sa guise. Les gens s’en servent pour des liens de profil et des clés publiques. Un botnet peut y mettre une adresse de commande et de contrôle. Les chercheurs parlent d’EtherHiding quand les données de commande vivent dans l’état de la chaîne de blocs plutôt que dans le DNS. L’équipe d’intervention de Nokia Deepfield emploie le mot pour Kimwolf. L’adresse est encodée, de sorte qu’ouvrir l’enregistrement ne montre pas une adresse IP en clair.

Pour la lire, le logiciel envoie une requête JSON-RPC. C’est la façon ordinaire dont un portefeuille ou un explorateur de blocs parle à un nœud Ethereum : une petite requête en HTTPS, et une petite réponse. Le logiciel malveillant appelle deux fonctions. resolver() renvoie le contrat qui détient les enregistrements du nom. text() renvoie la chaîne. Aucun mot de passe n’est requis pour lire. Écrire exige encore la clé du propriétaire.

C’est le compromis. Le nom est difficile à saisir, et ce n’est pas un secret. N’importe qui peut consulter le même enregistrement que les bots consultent. Les défenseurs peuvent le surveiller. Ils ne peuvent simplement pas le faire pointer ailleurs.

Comment Kimwolf demande

Le texte de Unit 42 sur la version 7 de Kimwolf a trouvé cinq points d’accès Ethereum publics compilés dans le programme, en clair. Ce sont des services publics normaux, du genre qu’un portefeuille utilise quand il ne fait pas tourner son propre nœud :

• 0xrpc.io
• eth.llamarpc.com
• ethereum-rpc.publicnode.com
• eth-protect.rpc.blxrbdn.com
• eth.merkle.io

Avant chaque recherche, le logiciel malveillant mélange la liste et en essaie un. Cinq services connus, ça veut dire qu’il n’y a pas un seul fournisseur à couper, et les bloquer couperait aussi les gens qui s’en servent pour de vrai. Le conseil de Unit 42 est de surveiller ce trafic quand il part d’un boîtier de télé ou d’un téléphone, pas d’interdire ces points d’accès.

Deepfield, en cartographiant l’ensemble plus large de botnets le 20 mars 2026, a trouvé une étape de plus devant celle-là. La première recherche, celle qui trouve le point d’accès Ethereum lui-même, passe par le DNS sur TLS. L’appareil interroge un résolveur DNS sur une connexion chiffrée, donc le nom du service Ethereum n’apparaît pas comme une requête DNS ordinaire sur le réseau. Ce n’est qu’ensuite que l’appel JSON-RPC a lieu.

Deux des noms .eth que l’exploitant a fait tourner sont pawsatyou.eth et re6ce.eth. Deepfield en liste un troisième. C’est une insulte raciale, alors il n’est pas répété ici. Le rapport original l’imprime parce que les défenseurs ont besoin de l’indicateur.

Unit 42 décrit aussi un sixième point d’accès, eth.rpcuniverse.com, qu’il évalue avec une confiance modérée comme étant exploité par l’opérateur plutôt qu’offert comme service public. Il ne ressemble pas aux cinq autres. Ceux-là sont des services occupés, établis depuis longtemps, répartis sur beaucoup d’adresses. Celui-ci, dans le compte rendu de Unit 42, siège sur un seul serveur bon marché, et certains échantillons le contiennent à côté des cinq publics. Unit 42 n’a pas pu confirmer qui l’a enregistré. La distinction compte pour la vérification à la fin : un boîtier de télé qui parle à une API Ethereum publique est déjà étrange. Un boîtier de télé qui parle à une API peu connue est un signal plus fort. Ni l’un ni l’autre n’est une raison de bloquer les cinq publics.

Kimwolf, sur les boîtiers de télé Android

Kimwolf est le versant Android d’un botnet qui tourne aussi sur des appareils Linux sous le nom Aisuru. Unit 42 les décrit comme deux bases de code distinctes, aux mains des mêmes exploitants. Aisuru est actif depuis août 2024 et a commencé sur des appareils Linux. Vers août 2025, les mêmes exploitants se sont tournés vers les boîtiers de télé Android et les décodeurs, et ce versant s’appelle Kimwolf.

La porte d’entrée est le pont de débogage Android, le port que certains de ces boîtiers laissent ouvert sans mot de passe. Il écoute sur le port 5555. Les exploitants l’atteignent en passant par un proxy résidentiel, pour que le boîtier traite la connexion comme locale, puis installent le logiciel malveillant sans invite de connexion. La version 7 ne porte plus son propre scanner ni sa trousse d’exploits. Unit 42 y lit une séparation : d’autres chargeurs font l’intrusion, et le bot lui-même s’occupe des attaques et du relais.

Des démantèlements en décembre 2025 ont mis les serveurs de commande hors ligne plus d’une fois. La version 7, vue pour la première fois par Unit 42 le 3 février 2026, après des recherches publiques de XLab, Synthient, Infoblox et Cloudflare, a été écrite pour survivre au suivant. Elle a trois façons de trouver ses ordres :

1. L’ENS, comme ci-dessus. Si le registre de texte passe à un nouveau serveur, les bots suivent sans nouveau domaine et sans nouvelle version du logiciel.
2. Un service caché Tor. Si la recherche ENS échoue, la version 7 se rabat sur une adresse .onion compilée dans le programme. Cette adresse n’apparaît pas non plus dans le DNS public. Il n’y a pas de registraire sur ce chemin.
3. Un proxy local sur l’appareil, à 127.0.0.1 port 23075. Le trafic de commande y passe, que le saut suivant soit l’internet ordinaire ou Tor, et le proxy peut être remplacé sans remplacer tout le bot.

Sur un boîtier de télé, le processus se renomme netd_service, ce qui est censé ressembler à un processus système d’Android. Certaines versions apparentées sont livrées comme une application Android qui se fait passer pour un service système et porte le bot à l’intérieur.

À quoi servent les bots, dans cette version : surtout du trafic de déni de service dirigé vers quelqu’un d’autre, plus du relais. Unit 42 compte quinze méthodes d’inondation dans la version 7, en baisse par rapport à 43 méthodes nommées dans les versions plus anciennes. L’une des nouvelles est une inondation HTTP/2 qui construit le genre d’en-têtes qu’un navigateur envoie, de sorte que le trafic d’attaque est plus difficile à distinguer de quelqu’un qui charge vraiment une page. Une autre parle le trafic web chiffré ordinaire. Le boîtier n’a pas besoin d’avoir l’air brisé pour faire partie du botnet. Il peut avoir l’air de naviguer.

Jackskid, quatre jours après la saisie

Le 19 mars 2026, le ministère de la Justice des États-Unis et ses partenaires ont annoncé une opération autorisée par un tribunal contre l’infrastructure de commande d’Aisuru, de Kimwolf, de Jackskid et de Mossad. La note plus tardive de Unit 42 sur la même recherche dit que la saisie comprenait des domaines de commande. Saisir un serveur, ou un domaine, ce n’est pas détenir la clé qui écrit un enregistrement ENS.

Le rapport de Deepfield sur Jackskid décrit ce que cet exploitant a fait ensuite. Avant le démantèlement, Jackskid gardait son adresse de commande dans des domaines ordinaires et faisait tourner un grand ensemble d’adresses IP derrière eux : plus de 98 adresses sur six domaines. Après le 19 mars, beaucoup de ces domaines ont cessé de se résoudre, et la plupart des anciens serveurs ont cessé de répondre. Des versions datées du 23 mars résolvent le serveur de commande par le nom ENS m3rnbvs5d.eth, en lisant une adresse encodée dans un registre de texte. Même idée que Kimwolf, encodage différent. Deepfield a compté cinq adresses actives derrière ce nom. Le botnet était encore joignable. Il était beaucoup plus petit. Deepfield a aussi vu, la même semaine, des versions allégées qui sautaient entièrement le DNS et portaient une adresse de commande dans le programme lui-même, ce qu’on fait quand on ne fait plus confiance à l’annuaire.

L’ENS n’a pas remis Jackskid d’aplomb. Il a donné à l’exploitant un canal que la saisie ne couvrait pas, à une fraction de l’ancienne capacité.

Pourquoi intercepter un canal ne suffit pas

Deepfield rattache Aisuru, Jackskid, Kimwolf et MossadProxy (Mossad, dans le communiqué du ministère de la Justice) à une même lignée de code et d’infrastructure. Sur ces quatre, il compte cinq façons de trouver les ordres : des enregistrements DNS TXT, le DNS sur HTTPS, l’ENS, un système DNS alternatif appelé OpenNIC, et un protocole chiffré sur mesure qui ne laisse pas de trace DNS une fois la première recherche faite. Ce n’est pas chaque bot qui utilise chaque canal. Les noms OpenNIC ne se résolvent pas par les résolveurs que la plupart des gens utilisent, comme 1.1.1.1 ou 8.8.8.8, donc ils n’apparaissent pas dans un journal DNS normal. Les noms ENS n’y apparaissent pas non plus. Un démantèlement visant l’un de ces canaux laisse les autres.

C’est le point pratique des noms Ethereum. Ils ne sont pas cachés. Ils sont difficiles à retirer.

Quoi vérifier à la maison

Vous n’avez pas à utiliser Ethereum pour que cela vous concerne, et un téléphone ou un portable n’est pas la cible habituelle. Ces botnets tournent sur des boîtiers de télé et d’autres appareils toujours allumés, et le tort qu’ils causent est surtout du trafic d’attaque dirigé vers quelqu’un d’autre. Quelques vérifications valent quand même la peine :

1. Sur un boîtier de télé Android, laissez les options de développement fermées. La porte d’entrée de Kimwolf est un pont de débogage Android ouvert. Si un menu offre le débogage USB ou le débogage réseau, fermez-le. Si vous avez vraiment besoin du débogage, USB seulement est le réglage que Unit 42 indique. Un boîtier que vous ne pouvez pas mettre à jour, d’une marque que vous ne pouvez pas retrouver, est le genre que ces campagnes balaient.
2. Gardez le boîtier à l’écart du reste du réseau si vous le pouvez. Un réseau invité, ou un câble réseau débranché, limite ce qu’un boîtier compromis peut voir. La version simple de Unit 42 : traiter un boîtier de télé Android comme non fiable.
3. Le trafic Ethereum qui part d’un boîtier de télé ou d’un téléphone est le signal. Ces appareils n’ont pas besoin de parler à un nœud Ethereum, et ils n’ont pas besoin de Tor. Unit 42 nomme les signes : des connexions sortantes vers des services Ethereum publics, Tor depuis un boîtier de télé, un processus appelé netd_service, ou quelque chose qui écoute sur le port 23075 du boîtier lui-même. La plupart des gens ne peuvent pas inspecter la liste des processus d’un téléviseur. Le trafic, et un boîtier qui ne reste pas tranquille, suffisent.
4. Ne « réglez » pas cela en bloquant les services Ethereum publics. Ces cinq points d’accès sont une infrastructure partagée. Les bloquer ne retire pas le bot, et ça casse de vrais portefeuilles et explorateurs sur les machines qui utilisent vraiment Ethereum. Ce qui cloche, c’est l’appareil qui demande.
5. Débranchez un boîtier qui ne reste pas tranquille. Un trafic lourd pendant que l’écran est éteint, ou un boîtier qui continue d’appeler après que vous le croyez éteint, suffit pour le retirer du réseau.

Rien de tout cela ne se règle avec un outil de nettoyage que quelqu’un vous envoie par texto.

Sources (en anglais) :

• Kimwolf v7: An Evolution of the Kimwolf Botnet, Palo Alto Networks Unit 42. L’article note une mise à jour du 13 août 2026 sur la saisie du ministère de la Justice.
• Shared code, shared secrets: tracing four DDoS botnets to one ecosystem, Nokia Deepfield ERT, 20 mars 2026.
• Jackskid, Nokia Deepfield ERT.
• Authorities disrupt IoT DDoS botnets, ministère de la Justice des États-Unis, 19 mars 2026.