Cling cache ses commandes dans un trafic qui ressemble à un appel vidéo

Le 1er octobre 2026, Nozomi Networks Labs a publié un botnet Linux qu’il appelle Cling. Quatre jours plus tard, FortiGuard Labs a décrit une souche qu’il appelle ClingSTUN. Les deux textes ne se citent pas. Ils décrivent les mêmes cachettes sur un appareil, les mêmes scripts de démarrage, et la même idée : parler aux serveurs publics qu’utilisent les appels vidéo, pour que le trafic du botnet ressemble à un appel qui se met en place. Ce texte les traite comme une seule campagne et garde les endroits où ils ne sont pas d’accord.

Il n’arrive pas dans un courriel, et il ne s’installe pas à partir d’un lien sur un téléphone. Il entre dans des routeurs, des caméras, des enregistreurs et des boîtiers semblables, joignables depuis Internet et qui portent encore des failles vieilles de plusieurs années.

Ce qu’est STUN, quand ce n’est pas un botnet

Quand un appel vidéo ou un appel dans le navigateur doit joindre quelqu’un derrière un routeur domestique, l’ordinateur demande d’abord à un serveur public une question simple : à quelle adresse est-ce que j’ai l’air de l’extérieur, et quel port avez-vous vu ? Cette question est STUN, Session Traversal Utilities for NAT, spécifiée dans le RFC 8489. Zoom, Teams, Webex et les appels ordinaires du navigateur le font tous. Les serveurs qui répondent sont surtout légitimes, et beaucoup d’entre eux sont faits pour être utilisés par n’importe qui.

Cling utilise cette question comme annuaire. L’échantillon de Nozomi la pose environ toutes les cinq secondes. Le trafic autour peut se fondre dans le même bruit qu’un vrai appel.

Comment il entre

Nozomi l’a trouvé en observant des tentatives d’exploiter CVE-2021-35394, une faille d’exécution de code à distance dans le SDK Realtek Jungle. Le composant se retrouve dans des routeurs, des points d’accès, des répéteurs et d’autres appareils, et beaucoup d’entre eux ne reçoivent jamais de mise à jour, ce qui explique qu’une faille de 2021 soit encore projetée sur Internet. La plupart de ce que Nozomi a vu était le sondage habituel. Une partie téléchargeait un bot qui ne se comportait pas comme une copie typique de Mirai.

L’échantillon que Nozomi a démonté porte aussi des exploits pour sept autres failles connues, pour qu’un boîtier déjà dans le botnet puisse chercher le suivant. La plus ancienne est une faille Realtek, CVE-2014-8361. D’autres visent des enregistreurs numériques et une poignée de marques de routeurs. Fortinet, sur ses propres échantillons, a listé 24 failles publiées utilisées comme portes d’entrée, sur du matériel de Realtek, D-Link, TP-Link, Tenda, Ivanti, EnGenius et d’autres, et a dit que la liste grandissait encore le 5 octobre. Sa copie porte sept exploits codés en dur pour se propager, qui recoupent l’ensemble trouvé par Nozomi. Fortinet découpe la campagne en trois périodes, chacune avec un endroit différent d’où l’installateur était téléchargé, et dit que le logiciel malveillant changeait encore pendant la rédaction.

Rien de tout cela n’est un nouveau genre d’intrusion. Nozomi le dit directement. La nouveauté, c’est comment le bot reste en contact ensuite.

Des commandes qui ressemblent à la mise en place d’un appel

Le compte rendu de Nozomi sur le canal de commande a quatre étapes.

1. Le bot envoie une requête de liaison STUN à 13 serveurs. Une requête normale porte un identifiant de transaction aléatoire, un nombre que le serveur est censé renvoyer pour que le client associe la réponse à la question. Cling met cet identifiant à zéro, ce que la norme n’autorise pas. Au moment où Nozomi écrivait, ces serveurs avaient des réputations saines, et la plupart figurent sur des listes publiques de serveurs STUN.
2. Chaque serveur répond avec l’adresse publique et le port qu’il a vus. Cela ouvre un chemin temporaire en retour à travers le routeur.
3. Le bot envoie ensuite à chaque serveur un message d’inscription qui n’est pas du STUN du tout. Il comprend les ports qu’il vient d’apprendre, et une étiquette sur la façon dont ce bot a été infecté, par exemple le chemin Realtek. Les serveurs conformes l’ignorent. Dans l’essai de Nozomi, aucun des 13 n’a répondu.
4. Le bot attend. Les ordres arrivent plus tard sous forme de paquets UDP dont l’identifiant de transaction, le champ qui devrait être aléatoire, encode plutôt la commande.

Les commandes que Nozomi liste sont le menu habituel d’un botnet : télécharger et exécuter quelque chose, balayer et exploiter d’autres appareils, ouvrir un tunnel, relayer du trafic comme proxy, ou inonder une cible pendant un temps fixé. Sur plusieurs jours d’observation, Nozomi a reçu des tâches de balayage et des tâches d’inondation visant un fournisseur Internet sud-coréen, une grappe de l’Université de Chicago, et deux serveurs Minecraft.

Un serveur dans la liste de 13 ne se comportait pas comme les autres. Un serveur STUN conforme renvoie l’identifiant de transaction qu’on lui a envoyé. Celui-ci a répondu avec des zéros, la même valeur qu’utilise le bot. Nozomi s’est ensuite fait passer pour un nouveau bot, mais a dit à chaque serveur un ensemble de ports différent. Des heures plus tard, des commandes sont apparues sur un port qui n’avait été annoncé qu’à ce seul serveur. C’est la preuve de Nozomi que l’exploitant peut voir les inscriptions qui y arrivent, et s’en servir pour apprendre où est le nouveau bot.

Les paquets qui portaient ces commandes prétendaient venir d’une adresse vers laquelle stun.l.google.com se résout. Nozomi dit ne connaître aucune façon légitime de faire répéter à un serveur STUN un identifiant de transaction choisi par l’attaquant. Le trafic est en UDP et à sens unique. L’explication la plus probable, selon eux, est que l’expéditeur a falsifié l’adresse de Google, depuis un réseau qui ne vérifie pas si les paquets viennent vraiment d’où ils le prétendent. Ils signalent une différence stable dans le nombre de sauts entre les vraies réponses STUN et les paquets de commande. Ce n’est pas un rapport selon lequel le service de Google a été pénétré. C’est un rapport selon lequel un paquet peut porter une adresse de retour de confiance. Un paquet étrange venu d’un hôte étrange se fait examiner. Le même paquet, après que l’appareil a déjà parlé au service STUN de Google, est facile à classer sous « appel vidéo ».

Le compte rendu de Fortinet du 5 octobre correspond à l’idée STUN et s’arrête avant cette dernière affirmation. Sa version plus récente utilise aussi 13 points d’accès publics, en baisse par rapport à 24 dans la version d’avant, et après l’échange de liaison elle envoie à ces serveurs un identifiant de groupe et la liste des ports mappés. Fortinet dit n’avoir pas trouvé de serveur de coordination distinct sur ce chemin, et que la façon dont l’exploitant apprend le mappage externe puis livre les commandes à travers le routeur restait non vérifiée dans l’échantillon qu’ils avaient. Leur bot écoute un court paquet qui peut déclencher une commande à distance ou lui dire de se propager. Deux labos, une semaine, le même déguisement, et un désaccord sur la part du chemin de retour qu’ils ont pu prouver.

Ce qu’il fait au boîtier

Les deux rapports disent que le logiciel malveillant se copie vers /root/.cling et /usr/local/bin/.cling, et ajoute ces copies aux scripts de démarrage /etc/inittab, /etc/init.d/rcS et /etc/rc.d/rc.boot, pour qu’un redémarrage le relance.

Nozomi a aussi trouvé une seconde prise sur l’appareil. Il met le vrai wget de côté, se souvient où cette copie est allée, et se met à la place de wget. La prochaine fois que quelque chose sur le boîtier télécharge un fichier, y compris une tâche planifiée ou un autre attaquant, le logiciel malveillant s’exécute d’abord, puis fait le téléchargement pour que l’appelant ne remarque rien. Fortinet décrit un déguisement de plus : le programme efface sa propre ligne de commande pour qu’une liste de processus paraisse vide, et il peut couvrir ses propres informations de processus avec une copie de ce à quoi ressemble le premier processus du système.

La conclusion de Fortinet rejoint celle de Nozomi sur le point qui compte pour le blocage : les serveurs STUN publics ne devraient pas être traités automatiquement comme une infrastructure d’attaquant. Le signal, c’est l’appareil, et la forme du trafic, pas le fait qu’un serveur STUN existe.

Quoi vérifier

1. Retirez les vieux routeurs, caméras et enregistreurs de l’Internet ouvert. Mettez à jour le micrologiciel si le fabricant en publie encore. Si l’appareil n’est plus pris en charge depuis des années, remplacez-le ou ne laissez pas Internet l’atteindre. Un réseau invité est une version plus petite de la même idée. Les failles de ces rapports sont publiques et anciennes. Corriger est tout le correctif pour un boîtier qui peut encore l’être.
2. Le STUN d’un portable pendant un appel est normal. Le STUN d’une caméra, d’un enregistreur ou d’un routeur qui n’est pas dans un appel ne l’est pas. L’étrangeté précise de Nozomi est une requête de liaison toutes les quelques secondes avec un identifiant de transaction à zéro, ou un paquet qui n’est pas du STUN envoyé vers un port STUN. Vous n’avez pas besoin de bloquer STUN pour agir là-dessus. Le bloquer casserait de vrais appels.
3. Si vous pouvez regarder l’appareil, les noms de fichiers sont clairs. .cling sur le disque, des scripts de démarrage qui le mentionnent, ou un wget déplacé vers wget.r avec un wget.p à côté. La plupart des gens ne peuvent pas ouvrir une session sur une caméra. Le débrancher est la vérification qui n’exige pas cela.

Les téléphones et les PC domestiques ordinaires ne sont pas la voie de propagation de celui-ci.

Sources (en anglais) :

• A STUNning Disguise: Cling Malware Masquerades as Google, Nozomi Networks Labs, 1er octobre 2026.
• ClingSTUN Linux Backdoor Abuses Public STUN Infrastructure, FortiGuard Labs, 5 octobre 2026.
• RFC 8489, Session Traversal Utilities for NAT, IETF.