Une nouvelle opération malveillante repérée en 2026 met en lumière une méthode de distribution particulièrement “fluide” pour les attaquants : DoubleCup ClickFix combine des leurres ClickFix, de la stéganographie dans des images PNG et un traitement côté navigateur pour déclencher des charges utiles. L’objectif final consiste à livrer CountLoader et une nouvelle porte dérobée à distance, baptisée DeviceManager.
Selon une analyse technique publiée par une société de cybersécurité, la campagne commence par le dépôt d’une image PNG “camouflée” dans le cache du navigateur, avant d’en extraire le contenu dissimulé. Les étapes suivantes s’appuient sur un chiffrement en mémoire et des mécanismes d’anti‑analyse, afin de réduire les chances d’observer le chargement sur des machines non ciblées.
DoubleCup ClickFix : une livraison en deux temps via PNG
Le point central de la chaîne est l’utilisation de ClickFix comme vecteur de mise en place. D’après le rapport, la première phase injecte une image PNG stéganographiée dans le cache du navigateur de la victime. Ensuite, le contenu caché est récupéré à partir de cette image, puis la seconde phase est déclenchée.
La seconde étape décode et prépare la charge utile finale. Elle s’appuie sur un chiffrement appliqué en mémoire, avec un mécanisme combinant un flux basé sur CTR (mode compteur), un XOR et une clé dérivée à partir de l’adresse IP publique de la victime. En clair : si la clé ne correspond pas, le déchiffrement échoue.
Cette logique sert à limiter l’exécution hors de la cible visée, car le contenu ne se déchiffre correctement que sur la machine pour laquelle la clé a été calculée.
CountLoader et DeviceManager : deux charges utiles distinctes
La plateforme sert à distribuer au moins deux types de logiciels malveillants.
- CountLoader : disponible avec des variantes pour Windows et macOS. Son rôle consiste à préparer l’environnement et à lancer des composants secondaires à la demande de l’opérateur.
- DeviceManager : un RAT modulable écrit en Python, jusque‑là non documenté publiquement avant cette analyse.
Dans les deux cas, la livraison passe par la même idée : une commande initiale déclenchée dans le navigateur (via ClickFix) mène à l’extraction du contenu caché, puis à l’exécution de la charge utile.
Licences, clé unique et client d’exploitation
La campagne serait active depuis le début de juin 2026. Les développeurs auraient fourni aux opérateurs des licences et un agent client permettant de monter des campagnes et de charger les charges utiles en intégrant le code nécessaire dans leurs pages ClickFix.
Chaque licence porte une clé unique et renferme des métadonnées, notamment : l’IP du client, les jours actifs, un label et une version. Un même jeu de licences permettrait de lancer plusieurs campagnes.
Le travail d’enquête aurait aussi été déclenché par un répertoire exposé, repéré à une adresse incluant un port. Des fichiers de test auraient ensuite été identifiés comme faisant partie du “panneau” de licence.
Le rôle du client Go : configuration et panneaux d’actions
Le dispositif d’exploitation observé inclut un client Windows basé sur Go, doté d’une interface graphique. Il donne aux opérateurs la possibilité de mettre à jour des configurations, actualiser le logiciel et d’envoyer des instructions directement.
Le rapport décrit plusieurs vues fonctionnelles, dont un panneau pour la diffusion de commandes et un panneau de création de charge utile. L’opérateur paramètre notamment le domaine, le slug, la méthode de stéganographie, le type d’encapsulation, le format d’archive, l’action et des URLs de payload.
À partir de ces éléments, la plateforme génère un endpoint de configuration au format : https://{domain}/{slug}/api/config. Une requête GET vers cet endpoint renvoie des données utiles à la phase navigateur.
Ces données incluent l’URL de l’image stéganographiée hébergée sur le domaine contrôlé, la taille de l’image, un endpoint de session, ainsi que des commandes spécifiques selon le navigateur utilisé (Chrome, Edge, Firefox, Brave ou Opera).
Déclenchement côté ClickFix : préchargement, session et redirection
Pour que l’attaque fonctionne, les opérateurs doivent aussi injecter du code frontal sur leur site ClickFix. L’idée est d’orchestrer une séquence précise côté navigateur.
D’après la description, le processus inclut :
- la récupération de l’endpoint /api/config ;
- le préchargement de l’image stéganographiée ;
- l’enregistrement d’une session ;
- la lecture du User‑Agent pour choisir la charge utile adaptée au navigateur.
Ensuite, le site affiche des instructions ClickFix, copie une commande correspondante dans le presse‑papiers de la victime et lance un mécanisme de polling afin d’initier la redirection finale.
Le rapport précise que les attaquants peuvent ajouter des mécanismes supplémentaires d’obfuscation ou d’anti‑analyse. Toutefois, ces étapes complémentaires relèveraient de leur responsabilité.
Traçage via bot Telegram et publication d’une extension douteuse
Un élément de coordination intervient également : un bot Telegram, utilisé pour suivre les visites clients, envoyer des clés et recevoir des rappels liés au chargement.
Fait notable dans l’analyse : ce bot serait géré par un acteur identifié sous un pseudonyme, qui aurait aussi publié une extension Visual Studio Code appelée Agent IDE dans la place de marché officielle. Le rapport ne conclut pas à une preuve directe de malveillance par l’extension seule, mais indique un lien d’infrastructure avec l’activité observée.
Faux sites de connexion CRM et extraction depuis le cache
Pour attirer les victimes, des campagnes auraient utilisé un ensemble de sites factices imitant des pages de connexion CRM. Parmi les marques usitées dans le leurre : NetSuite, Odoo, HubSpot et Salesforce.
La livraison du chargeur se ferait via des éléments intégrés, tels que des iframes, qui acheminent ensuite les instructions ClickFix. Une fois déclenchées, les commandes chercheraient l’image PNG dans le cache du navigateur et en extrairait du code malveillant : JavaScript, VBScript ou PowerShell, selon la situation.
Le serveur de commande et contrôle est notifié après infection, puis la seconde étape agit comme un déposeur : elle déploie un payload chiffré, redirige la victime vers une page de destination et tente de réduire l’exposition de traces.
Anti‑analyse : la clé dépend de l’IP et du contexte machine
Au-delà du chiffrement principal, la chaîne intègre un mécanisme d’environment keying : le déchiffrement n’est réalisable que si la victime fournit la valeur attendue. Le procédé passe par la dérivation d’une clé à partir de l’adresse IPv4 publique de la machine, ce qui rend l’exécution difficile à reproduire sur un autre hôte.
Pour DeviceManager, le filtrage est encore plus strict. Le malware éviterait notamment l’exécution sur des machines qui se rattachent à des paramètres linguistiques associés à la région CIS. Si un tel contexte est détecté, une routine d’auto‑suppression est déclenchée : suppression de la tâche programmée, effacement du dossier d’installation via cmd.exe, puis terminaison du processus.
Fonctions observées dans CountLoader
Le rapport indique que CountLoader poursuit des objectifs concrets après le lancement : il se connecte à un serveur C2, collecte des métadonnées système et exfiltre ces informations. Il attend ensuite des instructions supplémentaires.
Selon l’analyse, il peut exécuter des composants secondaires tels que des exécutables, des DLL, des fichiers MSI ou des HTA. Il peut également télécharger une archive compressée, extraire son contenu, lancer le binaire principal puis nettoyer certains mécanismes de persistance afin d’entraver l’investigation forensique.
Parmi les capacités décrites : une fonction de reconnaissance visant à repérer des raccourcis .LNK de navigateurs dans le bureau et le menu Démarrer, puis à réécrire la cible afin que le double‑clic lance le navigateur légitime tout en exécutant en arrière‑plan un RAT. L’analyse souligne toutefois que cette fonction ne serait jamais appelée, ce qui peut suggérer un code incomplet ou une fonctionnalité abandonnée.
DeviceManager : EtherHiding et C2 résistants via blockchain
La seconde charge utile, DeviceManager, se distingue par son approche de résolution de l’infrastructure de commande. Elle utilise une technique connue sous le nom EtherHiding : la blockchain sert de “boîte aux lettres” pour retrouver les détails du C2.
Concrètement, le RAT résout dynamiquement les nœuds C2 actifs via des smart contracts Ethereum/Polygon avant d’établir les communications. Une fois la cible identifiée, le malware communique et exfiltre des informations via DNS ou HTTP, tout en attendant des tâches, téléchargeant des payloads et renvoyant des résultats de commandes.
Le rapport ajoute que DeviceManager s’exécute à partir d’un installateur compilé Delphi via Inno Setup, qui embarque un payload chiffré. Au lancement, il extrait un environnement Python complet pour faire tourner le code malveillant, tout en appliquant les contrôles linguistiques mentionnés plus haut.
Ce que révèle DoubleCup ClickFix sur l’évolution des campagnes
Au total, DoubleCup ClickFix illustre une tendance : l’industrialisation de la livraison de charge utile, avec des étapes conçues pour être fiables et difficiles à analyser.
La campagne combine plusieurs leviers : stéganographie dans des PNG, exécution déclenchée via le navigateur, clé de déchiffrement liée à l’environnement, et résolution “robuste” du C2 via blockchain pour la RAT.
La présence de méthodes d’évasion à différents niveaux (chiffrement, filtrage de contexte, contournement d’observation) renforce l’idée que ces campagnes sont pensées dès le départ pour réduire la visibilité côté défenseurs.
Conclusion
Cette analyse met en évidence un pipeline cohérent : DoubleCup ClickFix utilise des leurres ClickFix et des images PNG en cache pour récupérer du contenu caché, chiffrer et déchiffrer en mémoire, puis déployer CountLoader et DeviceManager. L’approche met l’accent sur l’anti‑analyse et sur une infrastructure C2 résiliente, rendant la campagne plus difficile à perturber.
Pour les équipes de sécurité, la leçon principale reste la même : surveiller non seulement les exécutables, mais aussi les comportements liés aux leurres web, au chargement d’images, à l’extraction depuis le cache et aux communications C2 via HTTP/DNS.
Source: https://thehackernews.com/2026/08/doublecup-uses-clickfix-and-cached-pngs.html
