Cyril François, chercheur chez Elastic Security Labs, a publié en juillet 2026 une analyse technique de TELEPUZ, un malware modulaire écrit en C distribué selon un modèle Malware-as-a-Service (MaaS). TELEPUZ se propage via des leurres ClickFix depuis fin avril 2026 et déploie une chaîne d'infection en plusieurs étapes qui commence par un téléchargeur PowerShell, enchaîne avec une variante Go du stealer Vidar, et aboutit au chargement de la DLL principale TELEPUZ via rundll32.exe. Ce qui distingue TELEPUZ des stealers conventionnels est son infrastructure de commande et contrôle : si son canal de communication principal est bloqué, le malware récupère l'adresse de son C2 de secours depuis un profil Telegram, un profil Steam Community, une requête DNS vers codebasecode[.]com, ou un smart contract sur la blockchain Polygon à l'adresse 0xf55Bea1FdCf1c3ABb39ab92567C09aC1BFf6753E.
L'utilisation de la blockchain Ethereum/Polygon comme mécanisme de résistance à la censure pour l'infrastructure C2 est particulièrement intéressante d'un point de vue défensif. Un enregistrement de smart contract sur une blockchain publique ne peut pas être supprimé ou modifié par les forces de l'ordre ou les registraires de domaines une fois déployé. Contrairement aux domaines C2 traditionnels qui peuvent être saisis, aux comptes Telegram qui peuvent être fermés, ou aux enregistrements DNS qui peuvent être bloqués, un smart contract sur Polygon existe tant que la blockchain elle-même existe. Cette résilience architecturale rend le blocage de l'infrastructure C2 de TELEPUZ qualitativement plus difficile que pour les malwares qui dépendent uniquement de domaines ou d'adresses IP.
ClickFix est une technique d'ingénierie sociale qui exploite l'instinct de dépannage des utilisateurs confrontés à des erreurs. L'utilisateur visite une page web (généralement via un lien dans un email, un message, ou une publicité malveillante) qui affiche une fausse erreur système ou un faux avertissement de sécurité. La page propose de "corriger" le problème en demandant à l'utilisateur de copier et de coller une commande dans un terminal PowerShell ou une fenêtre Exécuter. Cette commande est le payload initial de l'attaque.
La technique ClickFix contourne plusieurs couches de protection de sécurité des navigateurs modernes. Les navigateurs Chrome, Edge et Firefox bloquent l'exécution automatique de JavaScript qui tenterait de télécharger et d'exécuter des fichiers, et ils affichent des avertissements pour les téléchargements suspects. Mais ils ne peuvent pas empêcher un utilisateur de copier du texte depuis une page web et de le coller dans un terminal qu'il ouvre lui-même. L'utilisateur effectue l'action d'exécution de façon active et semi-délibérée, ce qui contourne les protections qui reposent sur le blocage de l'exécution automatique. Elastic Security Labs a constaté une augmentation significative des campagnes ClickFix depuis début 2026, avec plusieurs familles de malware (dont OkoBot analysé séparément par Kaspersky la même semaine) adoptant ce vecteur d'infection.
Dans la chaîne TELEPUZ, la commande PowerShell initiale télécharge un payload de deuxième étape depuis un serveur externe. Ce payload est une variante Go du stealer Vidar, un stealer connu depuis plusieurs années qui a fait l'objet de nombreuses variantes et adaptations. La variante Go de Vidar collecte les données sensibles initiales (identifiants de navigateur, cookies, données d'authentification) pendant que le stager binaire qui suit charge TELEPUZ lui-même. TELEPUZ ("telepuz.dll") est ensuite lancé via rundll32.exe, l'utilitaire Windows légitime pour charger des bibliothèques DLL, ce qui lui confère un processus parent d'apparence légitimide. Stager et DLL sont tous deux récupérés depuis hurgadatour[.]shop.
Avant de commencer ses opérations principales, TELEPUZ désactive méthodiquement les mécanismes de surveillance et de détection de Windows. Il "déhookte" NTDLL, la bibliothèque Windows de bas niveau qui fait office d'interface entre les applications et le noyau Windows. De nombreux outils de sécurité endpoint installent des hooks dans NTDLL pour surveiller les appels système des applications et détecter les comportements malveillants. En restaurant NTDLL à son état original (sans les hooks des outils de sécurité), TELEPUZ rend ses propres appels système invisibles à ces outils.
TELEPUZ désactive également AMSI (Antimalware Scan Interface), l'interface Windows qui permet aux solutions antivirus d'analyser les scripts PowerShell, les macros Office, et d'autres contenus dynamiques avant leur exécution. La désactivation d'AMSI empêche les solutions de sécurité qui dépendent de cette interface d'analyser les scripts que TELEPUZ peut exécuter ultérieurement. ETW (Event Tracing for Windows), le mécanisme de journalisation des événements système sur lequel de nombreux outils EDR s'appuient pour collecter des données de télémétrie sur les comportements des processus, est également désactivé par TELEPUZ. Enfin, les callbacks DllNotification des tierces parties, utilisés par certains outils de sécurité pour être notifiés du chargement de nouvelles DLL dans les processus, sont supprimés.
Cette combinaison de désactivations, NTDLL déhooké, AMSI désactivé, ETW coupé, callbacks de notification supprimés, crée un angle mort significatif dans la télémétrie disponible aux outils de détection endpoint. Un processus qui s'exécute dans cet environnement dépouillé de ses mécanismes de surveillance peut effectuer des actions qui ne seront pas capturées par les solutions EDR qui dépendent de ces mécanismes. La détection de TELEPUZ par des outils qui n'ont pas de mécanismes de détection redondants indépendants de NTDLL, AMSI, et ETW est significativement plus difficile.
TELEPUZ tente d'obtenir des privilèges SYSTEM en volant le token d'accès du premier processus système correspondant à une liste prédéfinie : spoolsv.exe (le spouleur d'impression), msdtc.exe (le coordinateur de transactions distribuées Microsoft), WmiPrvSE.exe (le fournisseur WMI), et svchost.exe (l'hôte générique de services Windows). Cette technique d'escalade de privilèges par vol de token est connue sous le nom de "token impersonation" et exploite le modèle de sécurité Windows basé sur les tokens d'accès.
Dans Windows, chaque processus s'exécute avec un token d'accès qui représente les droits du compte sous lequel il tourne. Les processus système comme spoolsv.exe ou WmiPrvSE.exe s'exécutent sous des comptes locaux SYSTEM ou LocalService avec des privilèges élevés. Un processus qui dispose des droits appropriés peut dupliquer le token d'un processus système et s'empersonner ce token pour effectuer des actions avec les privilèges du processus système. TELEPUZ utilise cette technique pour élever ses privilèges de ceux du compte utilisateur courant (obtenu via l'infection initiale) au niveau SYSTEM, lui donnant un contrôle complet sur le système d'exploitation, notamment la capacité de modifier des fichiers système, d'accéder à des données protégées, et de désactiver des protections supplémentaires.
L'infrastructure de commande et contrôle de TELEPUZ est conçue pour la résilience. Le canal principal est un WebSocket avec TLS optionnel sur lequel TELEPUZ tente jusqu'à 10 connexions initiales. Si ces connexions échouent (parce que l'infrastructure principale est bloquée ou hors ligne), TELEPUZ passe à une série de méthodes de fallback pour retrouver l'adresse de son C2 de secours.
La première méthode de fallback est de récupérer l'adresse C2 depuis le profil Telegram du canal @chanadarkpart, créé le 28 avril 2026. Les canaux Telegram publics sont accessibles sans compte et leurs messages peuvent être lus par un programme automatisé. L'adresse du C2 de secours est encodée dans la description ou un message du canal, et TELEPUZ la récupère pour établir sa communication de secours. La deuxième méthode est similaire via un profil Steam Community, autre plateforme dont le trafic est difficile à bloquer en entreprise sans perturber les utilisateurs légitimes de Steam.
La troisième méthode, une requête DNS vers codebasecode[.]com, utilise le protocole DNS comme canal de récupération d'information, similaire au DNS tunneling mais uniquement pour la découverte du C2 et non pour la communication elle-même. La quatrième et dernière méthode est la plus innovante : TELEPUZ lit l'état d'un smart contract Polygon (Ethereum Layer 2) à l'adresse 0xf55Bea1FdCf1c3ABb39ab92567C09aC1BFf6753E. L'adresse du C2 de secours est stockée dans l'état de ce contrat, que son propriétaire peut mettre à jour à volonté. Ni les forces de l'ordre, ni les registraires de domaines, ni les équipes de sécurité des plateformes ne peuvent modifier ou supprimer cet enregistrement une fois déployé. C'est précisément la propriété d'immuabilité-cum-mutabilité (le propriétaire peut mettre à jour, personne d'autre ne peut supprimer) que TELEPUZ exploite pour maintenir une adresse C2 récupérable permanente.
TELEPUZ implémente un ensemble extensif de techniques destinées à compliquer son analyse et à éviter son exécution dans des environnements qui ne correspondent pas à des machines réelles de victimes. L'obfuscation par instructions garbage insère des opérations sans effet dans le flot de code pour augmenter le volume de code à analyser sans changer le comportement fonctionnel. Le hachage des noms d'import remplace les références aux fonctions importées par leurs valeurs de hachage, empêchant l'identification rapide des API Windows que le malware appelle par analyse statique. Le chiffrement des chaînes de caractères cache les URL, les noms de fichiers, les clés de registre et autres constantes textuelles que les analystes utilisent pour rapidement comprendre les actions d'un malware.
Les appels système indirects contournent les hooks NTDLL installés par les outils de sécurité en effectuant les appels système directement sans passer par les fonctions NTDLL habituellement hookées. Les vérifications anti-VM testent le nombre de CPUs, la quantité de RAM et l'espace disque disponible : TELEPUZ s'arrête sur des machines avec moins de 2 CPUs, moins de 2 GB de RAM, ou un espace disque insuffisant, car ces caractéristiques sont typiques des environnements d'analyse automatisés qui utilisent des ressources minimales. La vérification géographique basée sur les paramètres de langue du système (LCID) exclut les pays CIS pour éviter d'infecter des machines dans les juridictions d'où proviennent probablement ses opérateurs.
La détection d'environnement sandbox et la détection de débogueur complètent l'arsenal anti-analyse. Si TELEPUZ détecte qu'il tourne dans un environnement sandbox de malware ou sous un débogueur, il peut altérer son comportement ou crasher de façon contrôlée pour empêcher l'analyse de ses capacités réelles. Ces techniques sont caractéristiques d'un malware développé avec une attention particulière pour survivre aux analyses automatisées qui constituent la première ligne de détection des solutions antivirus modernes.
La neutralisation des mécanismes de surveillance standard de Windows par TELEPUZ (NTDLL, AMSI, ETW) crée un angle mort pour les outils EDR qui dépendent principalement de ces mécanismes. Les solutions qui maintiennent des agents de détection au niveau du noyau (kernel driver), indépendants des mécanismes en mode utilisateur que TELEPUZ désactive, sont moins affectées par ces désactivations. C'est l'une des raisons pour lesquelles les EDR modernes tendent vers des architectures à plusieurs niveaux avec des composants kernel qui fonctionnent indépendamment des mécanismes AMSI et ETW.
Pour les équipes de sécurité qui cherchent à détecter TELEPUZ, les indicateurs comportementaux les plus fiables sont ceux qui précèdent les désactivations : le comportement ClickFix initial (un processus PowerShell lancé depuis le contexte d'un navigateur ou d'une fenêtre Exécuter), les connexions vers hurgadatour[.]shop, et les modifications des processus système liées à la technique de vol de token (un processus non système qui accède au token de spoolsv.exe ou WmiPrvSE.exe). Ces comportements se produisent avant que TELEPUZ ait eu l'opportunité de désactiver les mécanismes de détection, et leur capture nécessite une détection en temps réel plutôt qu'une analyse post-exécution.
La résistance C2 de TELEPUZ via la blockchain rend le blocage basé sur les IOC de domaine insuffisant comme unique défense. Bloquer hurgadatour[.]shop, codebasecode[.]com, et même les accès aux profils Telegram et Steam depuis le réseau d'entreprise peut ralentir mais pas empêcher la communication C2 tant que l'adresse blockchain reste accessible. Une approche défensive qui inclut le filtrage des requêtes vers les RPC blockchain publics (infura.io, alchemy.com, polygon-rpc.com) depuis des endpoints non autorisés à effectuer des transactions blockchain peut fermer ce canal de récupération spécifique. Plus généralement, une politique de proxy sortant qui n'autorise que les connexions vers des destinations approuvées réduit significativement la surface d'attaque pour tous les canaux C2 non standard que TELEPUZ exploite. La cyber threat intelligence sur les techniques comme le C2 blockchain permet aux équipes de sécurité d'anticiper et de déployer ces contrôles avant d'être confrontées à un incident impliquant TELEPUZ ou des malwares similaires qui adoptent cette architecture.
L'adoption de ClickFix comme vecteur d'infection par TELEPUZ s'inscrit dans une tendance plus large documentée par plusieurs équipes de recherche en sécurité depuis début 2026. ClickFix a été initialement documenté en 2024 comme une technique utilisée par des groupes d'acteurs opportunistes, et son adoption s'est depuis étendue à des opérateurs de différents niveaux de sophistication, des cybercriminels opportunistes aux groupes sponsorisés par des États. La semaine du 14 au 20 juillet 2026 a vu deux analyses publiées de malwares distincts (OkoBot par Kaspersky et TELEPUZ par Elastic) utilisant tous deux ClickFix comme vecteur initial, reflétant la popularité croissante de cette technique dans l'écosystème du malware.
Les raisons de cette popularité sont structurelles. Les leurres ClickFix sont facilement personnalisables : le même mécanisme de base peut être habillé pour ressembler à une erreur Google Chrome, une vérification reCAPTCHA, une erreur Microsoft Teams, ou un avertissement de sécurité d'entreprise selon la cible visée. Chaque customisation augmente la crédibilité du leurre pour une catégorie spécifique d'utilisateurs sans nécessiter de modifications techniques de la payload. Les équipes de détection qui ont créé des signatures pour une variante ClickFix spécifique ne détectent pas nécessairement les autres variantes, ce qui maintient un taux d'évasion élevé pour les opérateurs qui restent agiles dans leurs leurres.
La défense contre ClickFix est principalement organisationnelle plutôt que technique. La mesure la plus efficace est une politique claire qui informe les utilisateurs qu'aucun système d'entreprise légitime, aucun site web officiel, et aucun logiciel de sécurité ne leur demandera jamais de copier et de coller une commande dans un terminal PowerShell ou une fenêtre Exécuter pour "corriger" un problème. Cette instruction doit être communiquée régulièrement et renforcée dans les formations de sensibilisation à la sécurité, avec des exemples visuels de leurres ClickFix réels pour que les utilisateurs puissent reconnaître la technique quand ils la rencontrent. Au niveau technique, la politique de restriction d'exécution PowerShell (Constrained Language Mode ou exécution restreinte aux scripts signés par un certificat d'entreprise) limite l'impact des commandes ClickFix même si un utilisateur les exécute.
L'inclusion d'une variante Go du stealer Vidar dans la chaîne d'infection TELEPUZ mérite un commentaire sur la structure des opérations MaaS modernes. Vidar est un stealer qui circule dans l'écosystème cybercriminel depuis 2018, disponible en tant que service depuis des forums souterrains. Il a fait l'objet de nombreuses variantes, adaptations, et réécritures depuis lors, y compris des portages dans des langages autres que le C++ original. Son inclusion dans la chaîne TELEPUZ ne signifie pas que les opérateurs de TELEPUZ ont développé Vidar : ils l'ont probablement acquis ou loué comme un composant séparé qu'ils intègrent dans leur propre infrastructure d'attaque.
Cette modularité est caractéristique de l'écosystème MaaS mature. Les opérateurs d'une campagne d'attaque n'ont plus nécessairement à développer tous leurs outils de A à Z. Ils peuvent assembler une chaîne d'infection à partir de composants disponibles sur le marché (ClickFix leurres, Vidar stealer, TELEPUZ implant principal) et les orchestrer avec leur propre infrastructure. Cette approche réduit le coût de développement, permet de mettre à jour un composant sans réécrire l'ensemble de la chaîne, et complique l'attribution parce que plusieurs groupes peuvent utiliser les mêmes composants de base avec des configurations différentes. La signature distincte de TELEPUZ est la chaîne C2 multi-canal avec le recours à la blockchain, pas les composants individuels de sa chaîne d'infection.
Elastic Security Labs, dans l'analyse publiée par Cyril François, a inclus des recommandations de détection qui mettent l'accent sur la surveillance de la chaîne de processus plutôt que sur les signatures statiques. La chaîne de processus d'une infection TELEPUZ a des caractéristiques identifiables : un processus PowerShell lancé depuis un contexte inattendu (navigateur, fenêtre Exécuter, wscript.exe), suivi d'un processus rundll32.exe chargeant une DLL depuis un répertoire temporaire ou un emplacement non standard, suivi d'opérations réseau vers des destinations externes. Cette séquence, même sans signature de fichier malveillant connue, est suffisamment anormale pour justifier une alerte dans un système EDR ou SIEM bien configuré.
Les règles de détection Sigma publiées par Elastic pour TELEPUZ couvrent spécifiquement les comportements de désactivation (tentatives de suppression des hooks NTDLL, de désactivation d'AMSI, d'arrêt d'ETW) qui surviennent tôt dans l'exécution. Détecter ces comportements de désactivation plutôt que les comportements post-désactivation offre une fenêtre d'intervention plus précoce dans la chaîne d'infection. Un processus qui tente de désactiver AMSI ou ETW est, dans presque tous les contextes légitimes, un processus qui mérite une investigation immédiate. Les règles Elastic pour TELEPUZ sont disponibles publiquement et peuvent être adaptées pour les plateformes EDR et SIEM qui ne sont pas Elastic mais qui supportent des conditions de détection équivalentes.
Pour les organisations qui cherchent à évaluer leur exposition au vecteur ClickFix plus largement, une simulation contrôlée de leurre ClickFix dans le cadre d'un exercice de phishing interne permet de mesurer le taux de clics et de commandes exécutées parmi les employés. Cette mesure fournit une baseline du risque humain spécifique à ClickFix, distincte du risque de phishing par lien classique, et permet d'orienter les efforts de sensibilisation vers les équipes et les profils d'utilisateurs les plus susceptibles de tomber dans ce type de piège. La compréhension des indicateurs de compromission commence par comprendre les vecteurs d'infection qui sont actifs dans le paysage des menaces actuel, et ClickFix est clairement l'un de ceux qui nécessitent une attention particulière en 2026.
Des attaques comme celles décrites dans cet article rappellent pourquoi la surveillance proactive de votre exposition externe est essentielle. Quand des identifiants sont volés, quand des clés privées sont exfiltrées, ou quand des données d'organisation circulent dans des canaux souterrains, les dégâts sont souvent déjà faits au moment où votre équipe les détecte.
Defendis surveille le dark web, les forums criminels et les marchés souterrains pour remonter les preuves d'exposition de votre organisation avant que les attaquants ne passent à l'action. Si des identifiants ou des données liés à votre organisation apparaissent dans un log de stealer ou une annonce de broker, Defendis les remonte avec le contexte complet : l'individu concerné, les données exposées, et comment la compromission s'est probablement produite.
Réservez une démo pour voir Defendis en action.
