Imaginez un instant que les pirates informatiques n’aient plus besoin de serveurs physiques, de noms de domaine ou d’hébergeurs vulnérables aux saisies judiciaires. Imaginez qu’ils puissent changer d’infrastructure de commande en quelques minutes, sans jamais perdre le contrôle de leurs victimes, et ce, pour un coût dérisoire. Cette dystopie cybernétique n’est plus de la science-fiction : elle est déjà opérationnelle en 2026.
Depuis plusieurs mois, une technique particulièrement astucieuse fait doucement son apparition dans l’univers souterrain du ransomware. Elle ne repose ni sur des serveurs cachés en Russie, ni sur des infrastructures cloud anonymisées, mais sur une technologie que la plupart des gens associent à la finance décentralisée et aux NFT : la blockchain Polygon.
Quand la blockchain devient l’alliée inattendue des cybercriminels
Le concept paraît presque trop simple pour être vrai, et pourtant il fonctionne avec une efficacité déconcertante. Au lieu d’intégrer directement dans le malware une liste d’adresses IP ou de domaines de commande et contrôle (C2), les développeurs de ce ransomware ont choisi une approche radicalement différente.
Ils ont déployé plusieurs smart contracts sur le réseau Polygon. Ces contrats ne contiennent ni argent, ni fonction complexe : uniquement une simple variable texte mise à jour régulièrement. Et dans cette variable ? Une adresse proxy actuelle.
Le mécanisme expliqué étape par étape
Voici comment se déroule l’attaque du point de vue de la victime :
- L’ordinateur est infecté par le ransomware (souvent via phishing ciblé ou exploitation de vulnérabilité RDP)
- Après chiffrement des fichiers, le malware exécute une routine de récupération d’instructions
- Il se connecte au réseau Polygon (via une bibliothèque web3 légère intégrée)
- Il appelle la fonction de lecture d’un smart contract dont l’adresse est codée en dur
- Il récupère la chaîne de caractères qui contient l’URL du proxy actuel
- Il établit la communication via ce proxy temporaire
Ce qui rend cette méthode particulièrement vicieuse, c’est qu’elle n’exploite aucune vulnérabilité de Polygon. Elle utilise uniquement les fonctionnalités de base et publiques de n’importe quelle blockchain : l’immuabilité et la disponibilité des données on-chain.
Pourquoi les défenses traditionnelles échouent face à cette technique
Les équipes de réponse aux incidents et les CERT sont habitués à travailler selon un certain schéma :
« Identifier les IOC (Indicators of Compromise) → bloquer les domaines/IP → couper la communication C2 → stopper la progression de l’attaque »
Avec cette nouvelle approche, presque tous ces points de blocage disparaissent :
- Il n’y a pas d’IP fixe à bloquer (le proxy change fréquemment)
- Le seul point de contact initial est une adresse de smart contract
- Bloquer l’accès à Polygon = bloquer potentiellement des milliers d’utilisateurs légitimes
- Le contrat est déjà déployé → impossible de le « supprimer »
- Les nœuds du monde entier conservent une copie de ces données publiques
Le résultat est limpide : le ransomware bénéficie d’une résilience infrastructurelle digne des plus grandes blockchains publiques.
Un coût opérationnel ridicule
Déployer un smart contract sur Polygon coûte généralement entre 0,5 et 5 $ selon la complexité et le prix du gas. Mettre à jour une variable ? Quelques centimes. Même en changeant d’adresse de contrat tous les mois, le coût total pour une année entière reste inférieur à celui d’un seul VPS anonyme pendant trois mois.
Cette économie permet aux groupes les plus modestes d’accéder à une technologie de résilience autrefois réservée aux acteurs les plus importants et les mieux financés.
Un précédent qui existait déjà… mais en plus discret
Les personnes suivant la cybersécurité blockchain depuis plusieurs années se souviennent sans doute de la technique dite EtherHiding apparue vers 2018-2019. Des groupes (notamment APT chinois) cachaient du code malveillant JavaScript dans des commentaires de transactions Ethereum.
La méthode actuelle va beaucoup plus loin dans la simplicité et l’efficacité : plus besoin d’encoder du code complexe dans des hex strings, plus besoin de plusieurs transactions. Une simple variable string suffit.
Le ransomware en question : profil bas mais technique sophistiquée
Les chercheurs ont baptisé cette souche DeadLock. Première observation officielle : juillet 2025. Particularités notables :
- Absence totale de site de fuite public
- Pas d’affiliation connue avec les grands programmes RaaS
- Victimes confirmées : relativement peu nombreuses
- Exigence de rançon moyenne : tranche basse à moyenne
- Communication professionnelle mais sans menace de DDoS ou d’appels téléphoniques
Ces éléments suggèrent un groupe relativement jeune, prudent, qui préfère rester sous les radars tout en testant des techniques innovantes.
Et maintenant ? Scénarios possibles pour 2026-2027
Plusieurs trajectoires sont envisageables :
- Diffusion massive de la technique – les développeurs de DeadLock vendent ou leakent leur builder avec cette fonctionnalité
- Adoption par les grands noms – LockBit, BlackCat/ALPHV, Akira, etc. intègrent la méthode comme canal secondaire
- Course à l’armement – les EDR/XDR commencent à intégrer des règles de détection basées sur les bibliothèques web3 et les communications vers Polygon
- Régulation accrue – certains États envisagent d’imposer des restrictions sur les smart contracts contenant uniquement des adresses IP/URL
- Évolution vers d’autres chaînes – Solana (encore moins cher), Base, Arbitrum, TON… toutes les L2/L1 à faible coût sont candidates
Que peuvent faire les organisations pour se protéger ?
Voici les mesures concrètes que les RSSI et équipes sécurité devraient envisager dès maintenant :
- Surveiller les processus qui chargent des bibliothèques web3.js, ethers.js ou similaires
- Ajouter des règles de détection sur les communications sortantes vers les RPC publics Polygon
- Mettre en place un monitoring des smart contracts connus pour cette activité (les adresses circulent dans les rapports techniques)
- Renforcer la segmentation réseau : les postes de travail ne devraient pas pouvoir atteindre directement les nœuds blockchain
- Sensibiliser les équipes IT sur cette nouvelle vectorisation du C2
Ces mesures ne sont pas anodines et impliquent un certain niveau de friction, mais le jeu en vaut probablement la chandelle face à une menace qui pourrait se généraliser rapidement.
Une question philosophique qui émerge
La blockchain a été conçue pour créer un système de confiance minimale, résistant à la censure et à la fermeture arbitraire. Force est de constater qu’elle remplit parfaitement cette mission… même quand les acteurs qui en profitent sont des cybercriminels.
Doit-on pour autant remettre en cause les fondements mêmes de la technologie décentralisée ? Ou considérer qu’il s’agit simplement d’une nouvelle illustration du vieil adage : « Toute technologie suffisamment puissante est indistinguishable d’une arme » ?
Une chose est certaine : l’année 2026 vient de nous rappeler, une fois de plus, que dans le domaine de la cybersécurité, l’innovation ne dort jamais… et qu’elle ne choisit pas toujours le camp des gentils.
À suivre de très près.
