OmniStealer
quand des pirates nord-coréens utilisent la blockchain pour rendre leur infrastructure plus difficile à neutraliser.

OmniStealer est un logiciel de vol d’informations, ou infostealer, documenté en 2026 dans une campagne visant notamment des développeurs. Ransom-ISAC l’a décrit dans ses travaux sur une opération de dissimulation de données à travers plusieurs blockchains. Malwarebytes a ensuite consacré une analyse au procédé en avril 2026.

Le point technique important est le suivant : les attaquants utilisent des blockchains publiques comme une partie de leur infrastructure. Des données utiles à la chaîne d’infection peuvent être inscrites dans des transactions, puis relues par du code exécuté sur la machine de la victime. Malwarebytes cite notamment TRON, Aptos et Binance Smart Chain, aujourd’hui généralement appelée BNB Smart Chain.

La version initiale de cet article présentait OmniStealer comme un malware « caché directement dans la blockchain » et impossible à supprimer. Cette formulation mélange deux réalités. Les fragments ou informations inscrits sur le registre peuvent devenir durablement accessibles, mais l’infection d’un ordinateur dépend toujours d’autres éléments : un code initial exécuté par la victime, des mécanismes de récupération, des services intermédiaires et, selon la campagne, des infrastructures d’exfiltration.

Ce n’est donc pas la blockchain entière qui devient malveillante. Elle est détournée comme un hébergement ou un point de référence particulièrement résilient. Cette distinction évite de faire croire qu’utiliser TRON, Aptos ou BNB Smart Chain expose automatiquement un utilisateur à OmniStealer.

Le procédé s’inscrit dans une évolution plus large des menaces qui pèsent sur l’écosystème des cryptomonnaies. Les attaquants ne cherchent plus seulement à voler des actifs : ils exploitent aussi les caractéristiques techniques du Web3 pour rendre leurs opérations plus difficiles à interrompre.

L’immuabilité est au cœur de l’intérêt de cette technique. Une transaction confirmée sur une blockchain publique n’est pas comparable à un fichier hébergé sur un serveur classique : un administrateur ne peut pas simplement ouvrir une interface et l’effacer. Les données inscrites dans l’historique restent donc disponibles.

Mais il faut corriger une idée importante de la version précédente : il n’est pas nécessaire de « supprimer la transaction » pour casser toute la chaîne d’attaque. Google a montré à propos d’EtherHiding que des acteurs nord-coréens utilisaient des fournisseurs d’API centralisés pour interroger les blockchains plutôt que de communiquer directement avec des nœuds. Ces intermédiaires peuvent agir, bloquer certains usages ou devenir des points de détection.

De la même façon, un dépôt GitHub initial peut être retiré, une adresse IP bloquée, un processus malveillant détecté, des identifiants révoqués et une machine compromise nettoyée. Les données on-chain peuvent rester présentes alors que la campagne devient inutilisable dans sa forme d’origine.

La première version évoquait également une « attaque 51 % » comme seule manière de supprimer les données. Cette présentation est trop simplificatrice. Une attaque majoritaire concerne le mécanisme de consensus de certaines blockchains et ne constitue pas une procédure réaliste de nettoyage d’un historique malveillant. Surtout, toutes les blockchains citées ne fonctionnent pas selon le même modèle de consensus. Ce chiffre ne doit donc pas être présenté comme la solution technique à OmniStealer.

Le bon diagnostic est plus précis : l’hébergement de données sur une blockchain rend certains éléments de l’infrastructure extrêmement résistants aux procédures classiques de retrait. Il ne rend ni l’ordinateur infecté ni l’ensemble de l’opération « indélébiles ».

OmniStealer porte bien son nom : son objectif est de récupérer un éventail très large de secrets numériques. Les analyses publiques mentionnent plus d’une dizaine de gestionnaires de mots de passe, les principaux navigateurs, des informations liées au stockage cloud et plus de soixante portefeuilles de cryptomonnaies accessibles depuis le navigateur.

Les navigateurs sont particulièrement intéressants pour un infostealer. Ils peuvent contenir des mots de passe enregistrés, mais aussi des cookies et des jetons de session. Le vol d’une session active peut permettre à un attaquant d’accéder à un compte sans avoir besoin de connaître le mot de passe au moment de l’intrusion. C’est pourquoi la seule modification d’un mot de passe ne suffit pas toujours après une compromission : les sessions actives doivent également être révoquées.

Les portefeuilles crypto représentent une cible évidente. Les extensions comme MetaMask et Coinbase Wallet sont citées parmi les nombreuses applications recherchées. Des clés, fichiers, extensions ou données d’authentification récupérés sur une machine compromise peuvent permettre des vols directs ou alimenter d’autres attaques.

Ransom-ISAC décrit aussi le ciblage de gestionnaires tels que 1Password, Bitwarden et LastPass, de clés SSH et d’identifiants cloud. Cette diversité montre que l’objectif dépasse largement la cryptomonnaie. Un poste de développeur compromis peut ouvrir l’accès à du code source, des environnements cloud ou des ressources internes d’entreprise.

Le chiffre d’environ 300 000 identifiants compromis a été relayé par Malwarebytes à partir des travaux des enquêteurs. Il doit être présenté comme une estimation issue de l’investigation, et non comme un décompte officiel de 300 000 personnes distinctes. Un même utilisateur peut posséder de nombreux identifiants et toutes les données collectées n’ont pas nécessairement produit une fraude financière.

Cette économie du vol d’identifiants alimente ensuite d’autres formes de cybercriminalité, comme les escroqueries crypto visant un grand nombre de victimes ou les usages criminels de certaines cryptomonnaies sur le dark web.

Le volet le plus concret pour les utilisateurs n’est pas la blockchain : c’est l’ingénierie sociale. Les campagnes nord-coréennes ciblant les développeurs utilisent depuis plusieurs années de faux recrutements, entretiens et missions freelance pour convaincre une victime d’exécuter elle-même un projet contaminé.

Dans les cas associés à OmniStealer, des offres peuvent être diffusées ou proposées via des plateformes professionnelles comme LinkedIn ou Upwork. Le recruteur demande ensuite au développeur de récupérer un dépôt de code, de lancer une application ou de corriger un exercice présenté comme un test technique. L’action paraît cohérente avec le métier de la cible, ce qui rend le piège plus crédible qu’une pièce jointe grossière.

eSentire a documenté en février 2026 une intrusion au cours de laquelle la victime avait cloné un dépôt GitHub piégé avant d’exécuter son frontend. La chaîne a finalement chargé DEV#POPPER et OmniStealer. Ce type de scénario montre pourquoi un antivirus, bien qu’utile, ne doit pas être la seule protection : l’utilisateur autorise lui-même l’exécution d’un projet qui semble professionnel.

Les campagnes de faux recrutement constituent aussi une continuité avec les opérations précédemment documentées par Google sous le nom « Contagious Interview ». Les données du FBI sur la cybercriminalité rappellent plus largement que l’ingénierie sociale demeure l’un des moyens les plus rentables de contourner les protections techniques.

Un développeur doit donc traiter un dépôt inconnu comme n’importe quel fichier potentiellement hostile. L’identité apparente du recruteur, un profil LinkedIn ancien ou un site d’entreprise crédible ne constituent pas une preuve suffisante. Une société réelle peut être usurpée et un compte professionnel compromis.

La première mesure est organisationnelle : ne jamais exécuter un test de recrutement inconnu sur son poste de travail principal. Un développeur peut isoler l’analyse dans une machine virtuelle ou un environnement de test dépourvu de clés privées, de mots de passe, de sessions professionnelles et d’accès au cloud de l’entreprise.

La deuxième consiste à réduire la quantité de secrets disponibles sur le poste. Les portefeuilles importants ne devraient pas dépendre uniquement d’une extension de navigateur sur la même machine que celle utilisée pour tester du code externe. Pour les actifs sensibles, un portefeuille matériel limite l’exposition des clés privées, même s’il ne protège pas contre toutes les formes d’ingénierie sociale ou de signature malveillante. Les évolutions des fabricants de wallets matériels doivent donc être vues comme une couche de sécurité, pas comme une immunité.

La troisième mesure est de protéger les comptes avec une authentification multifacteur résistante au phishing lorsque le service le permet, puis de surveiller les sessions actives. En cas d’infection soupçonnée, les mots de passe doivent être changés depuis un appareil sain et les sessions existantes révoquées. Les secrets techniques exposés, comme les clés API, jetons GitHub ou clés SSH, doivent être remplacés.

Enfin, les entreprises doivent surveiller les comportements plutôt que chercher uniquement un fichier précis. Une chaîne comme OmniStealer peut évoluer. Détecter un projet qui lance un interpréteur inhabituel, contacte des API blockchain puis accède massivement aux profils de navigateurs ou aux répertoires de portefeuilles est plus robuste que de dépendre d’une seule signature.

Cette logique vaut pour l’ensemble des violations de données à grande échelle : réduire les privilèges, segmenter les accès et limiter les secrets présents sur chaque poste diminue l’impact lorsqu’une première barrière échoue. Elle complète la vigilance nécessaire face aux messages et contenus malveillants.