Deux rapports convergents, publiés par Google Threat Intelligence Group (GTIG) et Unit42 (Palo Alto Networks), lèvent le voile sur une campagne malveillante particulièrement ingénieuse. En dissimulant un hameçonnage dans un smart contract stocké sur une blockchain publique, les attaquants combinent anonymat, persistance et exécution conditionnée. Ce cas d’école illustre la mutation des maliciels à l’ère post-antivirus : conçus pour l’orchestration, adaptatifs, encapsulés dans des couches de confiance trompeuses.
La scène s’est jouée dans le navigateur d’un développeur imprudent, happé par un hameçonnage atypique. Pas de pièce jointe ni d’URL douteuse, mais une promesse de contrat intelligent à évaluer. Derrière cette façade se dissimule un code JavaScript injecté dans un conteneur hébergé sur une chaîne de blocs. Une fois la victime piégée, le maliciel s’active uniquement si l’environnement système est propice. L’objectif est d’opérer une exfiltration silencieuse, rapide et personnalisée, sous la couverture des radars traditionnels.
Le conteneur malveillant découvert par Google GTIG contenait des scripts chiffrés en base 64, associés à un contrat hébergé sur la chaîne de blocs BNB Smart Chain, un écosystème blockchain décentralisé et communautaire pour les dApps Web3, alimenté par BNB. Les dApps Web3, ou applications décentralisées, reposent sur une logique radicalement différente des applications Web traditionnelles. Leur code est exécuté sur la chaîne de blocs (comme Ethereum), souvent via des contrats intelligents, tandis que l’interface frontale est servie par des réseaux distribués. Cette architecture sans serveur central offre une transparence apparente, mais prive aussi les dispositifs de cybersécurité classiques de points d’inspection ou de coupure.
Un cheval de Troie parfait
Dans le cas d’EtherHiding, cette structure sert de cheval de Troie parfait : le code malveillant peut rester dissimulé dans un contrat déployé sur la blockchain, consulté à la volée par le navigateur d’un utilisateur ciblé, sans qu’aucune alerte ne soit levée. Ce contrat était conçu pour stocker et appeler des données binaires au moyen de fonctions de lecture classiques, échappant ainsi aux filtres habituels. Un script JavaScript se connectait à ce contrat, récupérait les données via Web3, les déchiffrait à la volée, puis les exécutait localement dans le navigateur.
Ce contournement des canaux classiques d’infection rend l’infrastructure particulièrement difficile à détecter et à démanteler. La persistance est assurée par la nature même de la chaîne de blocs, car le contrat reste accessible tant que la chaîne existe. Aucun serveur d’hébergement n’est requis, aucune infrastructure centralisée ne peut être déconnectée. L’aspect open source et programmable des chaînes publiques devient ici une arme offensive.
Une exécution conditionnée, déguisée en projet légitime
Le plus impressionnant dans cette attaque reste la manière dont elle est déclenchée. Le code ne s’active que si certains critères sont réunis, comme la présence d’un environnement Windows, l’absence de machine virtuelle, des caractéristiques matérielles particulières. L’analyse menée par GTIG révèle une détection fine des navigateurs simulés et des sandbox de test, conditionnant l’exécution à un contexte perçu comme « réel ». Cette logique d’abstention délibérée préserve l’agent malveillant tant que la cible n’est pas confirmée.
Un témoignage direct, rapporté par un développeur victime, illustre la sophistication de cette approche. Il est sollicité pour commenter une application full stack, et choisit de l’exécuter dans une machine virtuelle par précaution. Face à cette prudence, son interlocuteur insiste : le code ne fonctionnerait soi-disant que sur une machine physique, en raison de prétendus conflits avec Windows et WSL. En réalité, l’exécution sur machine réelle déclenche une séquence d’instructions obfusquées, encapsulées dans un middleware JavaScript baptisé error.js. Ce fichier se charge immédiatement dès le démarrage de l’application, sous couvert d’une fonction de gestion d’erreur. Pendant un appel Google Meet destiné à occuper l’attention du développeur, le code parcourt silencieusement les journaux, les mots de passe et les fichiers système, qu’il exfiltre vers un serveur basé en Ukraine. Les attaquants avaient même prévu le lancement d’un processus Python secondaire pour prolonger la compromission. L’illusion d’un projet open source collaboratif masquait une opération d’ingénierie sociale redoutablement efficace.
Un système de commande et de mise à jour décentralisé
Selon les analyses croisées de Unit42 et GTIG, la logique de commande et de contrôle repose également sur des composants distribués. L’adresse du contrat sur la chaîne de blocs est codée dynamiquement dans un script d’appel, mis à jour régulièrement. Les opérateurs peuvent ainsi faire évoluer leur code malveillant sans jamais toucher au site initial de distribution. Chaque utilisateur interagit avec une version potentiellement différente, selon la date d’accès, la configuration du système ou la localisation géographique.
Cette modularité évoque le fonctionnement des plateformes C2 modernes, mais sans recourir à une infrastructure réseau classique. En guise de réseau, les blockchains servent ici de relais, de registre et de couche de persistance. En répliquant leur code sur plusieurs chaînes publiques, les attaquants augmentent leur résilience face à une éventuelle neutralisation d’un nœud. Ce choix stratégique rend toute opération de remédiation juridiquement et techniquement complexe.
Un tournant dans l’anonymat et la traçabilité
L’aspect le plus dérangeant réside sans doute dans la dissociation entre l’attaque et son origine. Contrairement aux maliciels traditionnels, qui laissent souvent des indices (serveurs, adresses IP, certificats compromis), ce mode opératoire repose sur des artefacts anonymes, signés avec des clés génériques ou jetables. La traçabilité se heurte à la nature même de la blockchain, où les données sont publiques, mais les auteurs dissimulés derrière des portefeuilles anonymes.
Cette configuration rend l’enquête post-incident difficile. Les équipes de réponse doivent croiser des indices techniques avec des heuristiques comportementales pour remonter jusqu’à une source plausible. L’absence d’infrastructure centrale empêche la coupure rapide de la chaîne d’infection. Le paradigme de défense doit évoluer vers une logique de détection comportementale en amont, couplée à une vérification systématique des scripts Web3 et des appels à des smart contracts non documentés.
Vers une ère des maliciels orchestrés et furtifs
Ce cas illustre une montée en gamme des acteurs malveillants, capables de combiner des techniques issues du développement logiciel (versioning, modularité, tests d’environnement) avec des vecteurs jusqu’ici perçus comme sûrs (blockchain, open source). L’avenir des attaques ne repose plus sur la force brute ou la simple ruse, mais sur l’orchestration adaptative, à la manière d’un chasseur à l’affût : disséminer le code malveillant, détecter, puis frapper lorsque les conditions sont réunies.
Pour les RSSI et les équipes de réponse, les développeurs et les architectes, ce type d’attaque appelle une vigilance renouvelée. L’analyse statique du code ne suffit plus. Il faut adopter une approche orientée scénario, documenter les dépendances Web3, restreindre les appels à des chaînes publiques dans les environnements sensibles, et imposer des règles d’audit renforcées. L’anatomie de cette attaque rappelle que le code, même s’il semble propre, n’est peut-être qu’un masque.
