Una nueva campaña de ciberataques ha salido a la luz: casi 800 paquetes npm maliciosos se publicaron en el registro de npm con el objetivo de infectar sistemas Windows, macOS y Linux. La intención principal no era solo ejecutar código, sino también desplegar un RAT (troyano de acceso remoto) y un infostealer capaz de robar información.
Según investigadores, los nombres de los paquetes intentan pasar desapercibidos mediante técnicas de “typo-squatting” y variantes aleatorias. Sin embargo, todos comparten una misma lógica de carga: conducen a un proceso que identifica el entorno del equipo y descarga el payload correcto para esa plataforma.
El patrón: de npm a una carga útil multiplataforma
El punto de partida de esta campaña está en paquetes recién publicados. La característica clave es que, en lugar de depender de ganchos del ciclo de vida típicos de npm (como preinstall o postinstall), estos paquetes incluyen un README con instrucciones para que el código se cargue mediante require(). Es decir, buscan que el contenido sea incorporado de forma funcional como parte del flujo normal del proyecto.
Una vez que el cargador se ejecuta, se activa un downloader llamado WEL1DROPPER. Este componente consulta el sistema operativo y la arquitectura del procesador, para después solicitar una carga compatible desde dominios en Cloudflare Workers.
Cómo el malware elige el payload correcto
Cuando las descargas por HTTPS funcionan, el sistema obtiene el siguiente estadio desde uno de estos destinos en Cloudflare Workers:
- oob-worker.cf103-070.workers[.]dev
- oob-worker.cf102-baf.workers[.]dev
- oob-worker.cf99-9b3.workers[.]dev
Si esa ruta falla, el malware cambia de táctica. Pasa a un mecanismo basado en registros DNS TXT y solicita más información desde el dominio wel1[.]ru. Allí, la siguiente etapa se entrega según la plataforma. Los dominios específicos por sistema y arquitectura son:
- Linux x64: sdk.dl.wel1[.]ru
- Linux ARM64: ext.dl.wel1[.]ru
- macOS: pkg.dl.wel1[.]ru
- Windows: net.dl.wel1[.]ru
El investigador describe el proceso así: el paquete realiza primero una solicitud TXT a c.<dominio>, interpreta el resultado como un número de fragmentos (con un rango entre 1 y 2.000), pide los fragmentos numerados y después los une. Finalmente, convierte el contenido combinado con Base64 para formar un búfer binario listo para ejecución.
Etapa final: escritura temporal y ejecución por sistema
En el último tramo de la cadena, el payload se escribe en una carpeta temporal y se ejecuta de forma distinta según la plataforma.
En Linux y macOS, la ejecución se realiza mediante /bin/sh. En Windows, el equivalente es cmd.exe. Con esto, el malware logra adaptar su activación a las herramientas disponibles en cada entorno.
La campaña también incluye acciones para reducir visibilidad y aumentar el control del atacante sobre la máquina comprometida.
Windows: persistencia y posible interferencia con la supervisión
En el caso de Windows, la fase final se lanza como un proceso desacoplado. Además, el flujo intenta dificultar el monitoreo: se mencionan pasos para ajustar componentes de telemetría (como ETW) y para interferir con AMSI, que suele usarse para inspección de contenido.
El malware también busca señales de análisis, revisando indicadores de sandbox o entornos virtuales. Si el entorno no parece “de laboratorio”, procede a establecer persistencia mediante una clave Run del Registro y una tarea programada.
Finalmente, descarga una carga cifrada desde una ruta indicada como /pkg/update_win.exe y la ejecuta.
macOS: verificación de análisis y apoyo en persistencia
La cadena para macOS es similar en intención. El malware intenta detectar depuradores y artefactos asociados al análisis, antes de recuperar un payload compatible desde un servidor remoto indicado como /pkg/beacon_mac.bin.
Si esa descarga no funciona, el comportamiento se ajusta al mismo enfoque de entrega por DNS TXT descrito anteriormente. Luego, configura persistencia mediante un LaunchAgent y arranca el ejecutable también como proceso desacoplado.
Linux: un binario ELF empaquetado y camino hacia Sliver
En Linux, el ejemplo reportado corresponde a un binario ELF empaquetado con UPX. Su configuración apunta a descargar cargas auxiliares a partir de un URL de Cloudflare Worker (en el caso citado se menciona uno específico).
El resultado final es la implementación de Sliver, un framework de comando y control de código abierto. En otras palabras, el objetivo no termina en la infección inicial: se prepara una infraestructura para controlar el host comprometido.
“Ruido” en el paquete: telemetría que parece legítima
Además del downloader y la lógica de carga, algunos paquetes incluyen un archivo llamado lib/telemetry.js. Sobre el papel, implementa un SDK de telemetría con apariencia verosímil.
Sin embargo, el componente también incorpora la misma lógica del descargador. El investigador remarca que el punto de entrada del paquete no importa ese archivo, por lo que no es necesario para el flujo principal. Esa desalineación sugiere que el contenido se agregó para crear ruido y hacer que la conducta maliciosa parezca, al menos en una revisión rápida, una funcionalidad nativa de analítica o perfilado.
Señales de posible objetivo financiero
En el payload de macOS se observan referencias a dominios como tcsbank[.]ru y cloudpayments[.]ru. Esto llevó a los analistas a sospechar que la campaña podría estar dirigida a instituciones financieras rusas y a pagos móviles.
La idea encaja con el enfoque de un infostealer: si el malware logra persistencia y ejecución estable, el siguiente paso suele ser recopilar datos valiosos del entorno comprometido.
Evolución de campañas previas en la cadena de dependencias
Los responsables también relacionan este desarrollo con una evolución de una campaña anterior de dependency confusion conocida como Moika. En aquella ocasión, se reportaron más de 250 paquetes publicados para robar información del entorno y entregar un segundo estadio adaptado al sistema operativo.
En esta nueva oleada, el mismo principio se refuerza: aprovechar la confianza en dependencias y empaquetados aparentemente funcionales para entregar una carga útil.
Panorama más amplio: npm, PyPI y extensiones maliciosas
La publicación llega en un momento en el que otras organizaciones también han documentado amenazas en ecosistemas de paquetes y extensiones. En particular, se han descrito campañas que afectaban tanto npm como PyPI.
Entre los ejemplos mencionados, algunos conjuntos de paquetes descargan un stealer de criptomonedas ofuscado y un RAT desde servidores externos. El flujo se basa en exportar funciones que construyen URLs y que embeben código JavaScript en objetos JSON para ocultar su lógica.
También se han observado capacidades más amplias: exfiltración de credenciales en la nube, droppers de C2 basados en blockchain, robo de llaves de billeteras Solana mediante Telegram, filtración de secretos en archivos .env, ejecución remota disfrazada de ingeniería social con mecanismos tipo CAPTCHA, y robo de tokens de Discord y credenciales en GitHub Actions CI/CD.
De los paquetes al navegador: extensiones como proxy de rastreo
En paralelo, se ha reportado el uso de extensiones de Chrome vendidas como emuladores de juegos, gestores de contraseñas, herramientas de productividad, inspectores CSS o convertidores de Markdown. La funcionalidad real gira alrededor de transformar el navegador en un proxy para rastrear la web.
El control remoto se realiza por medio de una conexión WebSocket persistente que envía comandos de rastreo. Además, estas extensiones integran un kit para compartir ancho de banda con una red de proxies residenciales de terceros. El rastreo se apoya en la inyección de un iframe oculto y en la conversión del contenido a Markdown que luego se envía a un backend en la nube.
En algunos casos, las descripciones en la Chrome Web Store y las políticas de privacidad ya mencionan la práctica, y la extensión solicita que el usuario acepte la función. Aun así, los analistas advierten que el opt-in puede presentarse como necesario para mantener el funcionamiento continuo, lo que facilita la aceptación del usuario.
Qué hacer: medidas prácticas para reducir el riesgo
Ante la aparición de paquetes npm maliciosos, la prioridad es reducir la superficie de ataque. Revisa dependencias nuevas con especial atención, sobre todo si su origen no es conocido o si los nombres se parecen mucho a librerías legítimas.
Conviene además:
- Verificar el contenido del paquete y el repositorio asociado cuando exista.
- Auditar scripts y flujos de carga, incluyendo el uso de require() y llamadas de red.
- Aplicar mínimos privilegios y aislar entornos de build cuando sea posible.
- Mantener un registro de cambios en dependencias para detectar incorporaciones inesperadas.
Con estas medidas, mejoras tu capacidad de detectar cadenas que intentan pasar por “componentes” normales, antes de que activen descargadores, persistencia o exfiltración de datos.
Conclusión
La campaña descrita demuestra cómo los atacantes continúan perfeccionando el abuso de la cadena de suministro: casi 800 paquetes npm maliciosos conducen a un cargador que adapta el payload a Windows, macOS y Linux. Además, la presencia de lógica disfrazada de telemetría y el uso de mecanismos de fallback (HTTPS y DNS TXT) muestran una estrategia diseñada para resistir fallos y mantener la efectividad.
Si gestionas proyectos con npm, este caso es una señal clara para reforzar el control de dependencias, revisar cambios y endurecer el flujo de instalación para que el “ruido” malicioso no encuentre una puerta abierta.
Fuente: https://thehackernews.com/2026/08/nearly-800-malicious-npm-packages.html
