ClickFix sur la blockchain : plus de 5 400 sites compromis distribuent du code malveillant

WordPress et PrestaShop transformés en points de distribution

Plus de 5 400 sites web compromis participent à une opération criminelle qui combine des leurres ClickFix, des smart contracts et des communications WebRTC. L’activité, analysée par Netskope et rendue publique le 5 septembre 2026, concerne principalement des portails construits avec WordPress et PrestaShop.

Les attaquants injectent dans les sites un script capable de récupérer la charge utile suivante depuis la BNB Smart Chain Testnet. Des pages appartenant principalement à de petites entreprises deviennent ainsi des points de distribution de code contrôlé à distance.

La méthode employée pour accéder initialement aux sites reste inconnue. Des composants vulnérables, des identifiants volés ou d’autres vecteurs pourraient être en cause, mais aucun élément ne permet de le déterminer. Les versions de WordPress, de PrestaShop ou des éventuels plugins concernés n’ont pas non plus été communiquées.

L’opération n’est associée à aucune vulnérabilité officiellement identifiée : aucun CVE, niveau de gravité standardisé ni référencement dans le catalogue Known Exploited Vulnerabilities de la CISA n’a été signalé. Le problème observé concerne des sites déjà compromis, et non une faille précise attribuée à un produit donné.

L’ampleur de l’opération est importante. Netskope estime que plus de 300 sites infectés sont utilisés chaque jour. Depuis le printemps, le nombre de domaines contactant les endpoints RPC de la BNB Smart Chain Testnet augmente régulièrement. En août, la moyenne a frôlé les 400 sites par jour, avec un pic à 536.

EtherHiding déplace la charge utile dans un smart contract

Le script injecté dans les sites ne contient pas nécessairement l’intégralité de la chaîne malveillante. Il interroge plutôt, via les endpoints RPC, un smart contract déployé sur la BNB Smart Chain Testnet afin d’en récupérer du code ou des données de configuration.

Cette technique est appelée EtherHiding. La blockchain sert de couche de distribution persistante, tandis que le site compromis joue le rôle de point d’entrée vers la victime.

Le choix de la testnet offre plusieurs avantages opérationnels. Le réseau est destiné aux développeurs, reproduit le fonctionnement de la mainnet et peut être utilisé gratuitement. Le trafic RPC peut en outre se confondre avec des activités légitimes liées aux applications blockchain et aux outils de développement.

Pour désactiver complètement la campagne, il ne suffit donc pas de supprimer un serveur web traditionnel. Le contenu accessible via le smart contract reste disponible sur le réseau, ce qui complique toute opération de démantèlement centralisée.

Les attaquants peuvent également modifier le contenu fourni par le contrat. Ils peuvent ainsi remplacer un leurre, un stager ou une configuration sans devoir réinjecter manuellement du code sur chacun des 5 400 sites.

C’est précisément ce qui s’est produit pendant l’opération analysée : la charge utile ClickFix initiale a été remplacée par un stager reposant sur un WebRTC Data Channel.

Le faux CAPTCHA convainc la victime d’exécuter PowerShell

La première variante observée affiche un CAPTCHA contrefait au sein du site compromis. Il ne s’agit pas d’une véritable vérification technique, mais d’une instruction d’ingénierie sociale conçue pour pousser l’utilisateur à compromettre lui-même son ordinateur.

La victime est invitée à ouvrir la fenêtre Windows Run, à y coller une commande PowerShell, puis à l’exécuter. Cette commande télécharge et lance la charge utile finale.

ClickFix contourne ainsi l’un des obstacles typiques des infections via navigateur. Le site n’a pas nécessairement besoin d’exploiter une vulnérabilité du système d’exploitation : il incite l’utilisateur à saisir une commande présentée comme nécessaire pour résoudre un problème ou terminer une vérification.

La nature exacte de la charge utile finale n’a pas été communiquée. Aucun hash, nom de fichier ou autre indicateur permettant de relier la chaîne à une famille de malwares précise n’est disponible.

Pour les utilisateurs, le signal le plus immédiat est comportemental. Un CAPTCHA légitime ne demande pas d’ouvrir Windows Run, de coller des commandes ou de lancer PowerShell. Toute page proposant cette procédure doit être fermée sans suivre les instructions.

La variante WebRTC exécute du JavaScript sans l’écrire sur le disque

Lors de la phase suivante, les opérateurs ont remplacé dans le smart contract le contenu ClickFix par un stager JavaScript reposant sur un WebRTC Data Channel.

WebRTC est généralement utilisé par les navigateurs pour les communications en temps réel. Dans ce cas, le stager crée une connexion peer-to-peer et un canal de données, en produisant une description de session comparable à celle utilisée lors d’un handshake normal.

Le flux présente toutefois une anomalie : le stager construit lui-même la réponse et la réinjecte dans la connexion. Il évite ainsi tout handshake réel, tout en parvenant à ouvrir un canal de données vers l’infrastructure de l’attaquant.

Le code JavaScript est reçu depuis une adresse de commande et de contrôle intégrée au stager. Les données sont accumulées dans la mémoire du navigateur, puis exécutées lorsque le canal se ferme ou au bout de 10 secondes.

L’exécution s’effectue dynamiquement en ajoutant le code à l’élément head du DOM. Le contenu n’a donc pas besoin d’être enregistré sous forme de fichier sur le disque.

Cette méthode réduit le nombre d’artefacts accessibles aux contrôles axés sur les fichiers. Elle ne rend toutefois pas l’activité invisible : les requêtes RPC, le trafic WebRTC, le comportement du navigateur et les communications vers le C2 restent observables.

L’adresse hardcodée du serveur de commande et de contrôle n’a pas été rendue publique. Les adresses précises des endpoints RPC concernés ne sont pas non plus connues, bien que Netskope ait indiqué un ensemble d’endpoints à bloquer dans ses recommandations.

Les contrôles à appliquer aux sites, au réseau et aux endpoints

Les administrateurs de sites WordPress et PrestaShop devraient examiner les pages, les templates et les composants à la recherche de scripts injectés. L’analyse doit inclure les requêtes vers les endpoints RPC de la BNB Smart Chain Testnet et vérifier qu’elles correspondent au comportement attendu du portail.

L’absence de versions vulnérables connues empêche de limiter l’intervention à l’application d’un correctif unique. La mise à jour du CMS et de ses composants reste utile, mais elle ne prouve pas qu’un site déjà compromis a été nettoyé. Un contrôle direct du code et des appels réseau est nécessaire.

Pour les équipes de défense, Netskope recommande de :

• bloquer l’ensemble des endpoints RPC de la BNB Smart Chain Testnet identifiés par les chercheurs ;
• surveiller le trafic UDP non web associé à WebRTC ;
• rechercher les requêtes RPC anormales provenant de sites WordPress et PrestaShop ;
• détecter PowerShell lancé depuis Windows Run ;
• contrôler l’exécution dynamique de JavaScript dans la mémoire du navigateur ;
• repérer les connexions vers des adresses C2 intégrées au code.

Un blocage systématique nécessite d’évaluer les usages légitimes de la testnet, en particulier dans les environnements de développement. Lorsqu’il n’est pas possible de le mettre en œuvre, les requêtes RPC devraient être journalisées et corrélées avec le domaine d’origine, le navigateur, le processus et le trafic WebRTC qui suit.

Les indicateurs les plus utiles sont donc corrélés. La consultation d’un site, suivie d’un appel RPC vers la testnet puis de l’ouverture d’un canal WebRTC inattendu, fournit un signal plus solide que chacun de ces événements pris isolément.

Après l’accès initial, de nombreuses actions restent indétectées

L’opération met en évidence deux niveaux distincts de compromission. D’un côté se trouvent les gestionnaires des sites, dont l’infrastructure sert à atteindre d’autres victimes. De l’autre, les utilisateurs sont exposés à des commandes PowerShell ou à du JavaScript transmis via WebRTC.

Aucune attribution nominative des attaquants n’a été fournie. La méthode utilisée pour compromettre les sites et la destination finale de l’ensemble des chaînes d’infection restent également inconnues.

Le Blue Report 2026, cité séparément par Netskope, permet de replacer le problème des phases postérieures à l’intrusion dans son contexte. Sur la base de 338 millions de simulations menées dans les environnements de production de ses clients, le rapport constate qu’après l’utilisation d’identifiants valides, seulement 37 % des actions des attaquants sont bloquées.

Ce chiffre n’attribue pas la campagne ClickFix à un vecteur précis et ne prouve pas que des identifiants volés ont été utilisés. Il souligne toutefois les limites d’une défense évaluée uniquement sur sa capacité à bloquer l’accès initial.

Dans cette opération, la détection doit couvrir l’ensemble de la chaîne : compromission du site, interrogation de la blockchain, interaction avec la victime, PowerShell ou WebRTC, puis communication avec le C2. Bloquer une seule de ces étapes peut interrompre l’attaque. En revanche, ne pas corréler les événements laisse aux opérateurs plusieurs voies alternatives.