La campagne XCTDH masque les adresses de commande de ses malwares dans Ethereum

Fin septembre 2026, le groupe de renseignement spécialisé dans les rançongiciels Ransom‑ISAC a publié un rapport détaillant une nouvelle méthode, baptisée « HashHiding », employée par la campagne de ransomware XCTDH, largement attribuée à la Corée du Nord. Selon le rapport, les opérateurs de XCTDH ont commencé à encoder l’adresse du serveur de commande et de contrôle (C2) dans des champs de destinataire de transactions Ethereum qui ne correspondent à aucune adresse réelle ou qui ne transportent qu’une quantité négligeable de crypto‑actifs. Cette technique vise à rendre la découverte du serveur C2 plus difficile pour les analystes de sécurité, tout en conservant la capacité du malware à récupérer dynamiquement l’information depuis la blockchain.

Comment fonctionne la technique HashHiding

Dans une transaction Ethereum standard, le champ « to » indique l’adresse du destinataire. Les chercheurs de Ransom‑ISAC ont observé que les opérateurs de XCTDH remplacent cette adresse par une chaîne hexadécimale qui, lorsqu’elle est décodée, révèle l’identifiant du serveur C2. Le décodage s’appuie généralement sur une fonction de hachage inversée ou sur une table de correspondance pré‑établie par le malware. La transaction elle‑même peut contenir zéro ether ou un montant inférieur à 0,0001 ETH, ce qui la rend peu intéressante pour les mineurs et les explorateurs de blocs, mais suffisante pour être inscrite de façon permanente sur la chaîne.

Le composant de récupération du malware interroge un nœud Ethereum public ou un point d’accès RPC afin d’extraire les dernières transactions contenant le motif suspect. Une fois la transaction identifiée, le code du malware applique la même logique de décodage que celle utilisée par les opérateurs, reconstitue l’adresse IP ou le nom de domaine du serveur C2, puis établit une connexion chiffrée pour télécharger les charges utiles ou les clés de déchiffrement. Cette approche élimine le besoin d’un serveur DNS dynamique ou d’une liste durement codée, rendant la rotation du serveur presque invisible aux systèmes de détection traditionnels.

Preuves et portée de la campagne XCTDH

L’enquête menée par le Ransom‑ISAC a permis d’identifier plus de 2 600 transactions correspondant au modèle HashHiding sur une période de trois mois, de la fin juillet à la fin octobre 2026. Au cours de cette fenêtre, les opérateurs ont modifié l’adresse encodée à quatre reprises, ce qui a conduit à l’utilisation de trois serveurs C2 distincts. Chaque changement d’adresse a été accompagné d’une courte période de test où plusieurs dizaines de victimes ont reçu le nouveau chargeur, avant que la nouvelle configuration ne soit largement diffusée. Ces chiffres confirment que la technique n’est pas un test isolé, mais une composante intégrée de la chaîne d’infrastructure de XCTDH.

Outre Ethereum, les chercheurs ont constaté que les mêmes opérateurs reproduisent le schéma HashHiding sur d’autres réseaux de contrats intelligents, notamment BNB Smart Chain, TRON et Aptos. Cette diversification oblige les équipes de défense à surveiller simultanément plusieurs explorateurs de blocs et à mettre en place des règles de corrélation entre les différents ledgers. Le fait que chaque chaîne possède ses propres paramètres de frais et de confirmation complique davantage la mise en place d’un blocage automatisé, car une adresse masquée sur Ethereum peut être rapidement répliquée sur BNB Smart Chain avec un coût marginal.

Limites de la dissimulation

Si la technique HashHiding rend la rotation du serveur C2 plus résistante aux blocages manuels, elle ne rend pas le malware indétectable. Les analystes peuvent toujours identifier les transactions suspectes grâce à des filtres basés sur la taille de la transaction, l’absence de valeur transférée et la présence de motifs hexadécimaux récurrents. De plus, le code du malware qui effectue le décodage doit être présent dans le binaire ou être téléchargé lors de la première infection, ce qui offre un point d’ancrage pour les solutions de détection basées sur l’analyse statique ou dynamique.

Les équipes de réponse aux incidents ont commencé à intégrer des signatures de transaction HashHiding dans leurs systèmes de surveillance de la blockchain. Ces signatures recherchent des adresses de destination qui ne correspondent à aucun portefeuille connu et qui sont associées à des montants inférieurs à un seuil prédéfini, généralement 0,001 ETH. En parallèle, les solutions de sandboxing peuvent instrumenter le comportement du malware afin de repérer les appels aux API RPC d’Ethereum et le décodage de données hexadécimales, ce qui déclenche des alertes précoces avant que le chargeur ne contacte le serveur C2.

• Surveiller les transactions Ethereum, BNB Smart Chain, TRON et Aptos à la recherche de motifs de HashHiding
• Déployer des filtres de valeur minimale pour ignorer les micro‑transactions suspectes
• Intégrer des signatures de décodage dans les solutions EDR et sandbox
• Bloquer ou rediriger les requêtes RPC vers des nœuds de confiance contrôlés par l’entreprise
• Partager les indicateurs de compromission (IOCs) avec les communautés ISAC pour une réponse coordonnée

Pour les entreprises, la présence de HashHiding signifie que la simple mise en liste noire d’adresses IP ou de domaines ne suffit plus à interrompre la chaîne d’infection. Les acteurs malveillants peuvent changer d’adresse C2 en quelques heures sans alerter les systèmes de filtrage réseau, tout en conservant une trace permanente sur la blockchain. Les organisations doivent donc élargir leur périmètre de détection aux activités de la blockchain publique, en combinant analyses de trafic réseau, logs d’appels RPC et renseignement sur les transactions suspectes.

À la lumière de ces découvertes, les équipes de cybersécurité sont invitées à mettre à jour leurs playbooks de réponse aux rançongiciels en incluant des procédures de surveillance de la blockchain et des règles d’alerte spécifiques à la technique HashHiding. Le Ransom‑ISAC recommande également de renforcer la coopération entre les fournisseurs de services cloud, les explorateurs de blocs et les plateformes d’échange afin de faciliter le signalement et la neutralisation rapide des adresses masquées. En adoptant ces mesures, les défenseurs pourront réduire l’avantage que la dissimulation dans Ethereum confère aux opérateurs de XCTDH et limiter la portée de leurs futures campagnes.