Alerta en npm: 800 paquetes maliciosos que se activan con require y entregan un dropper con RAT multiplataforma

Un amplio operativo de paquetes maliciosos ha inundado el registro npm: cerca de 800 módulos —publicados bajo nombres que parecen generados al azar o typo‑squatting— contienen un cargador que desemboca en un troyano de acceso remoto (RAT) y un infostealer multiplataforma. Los investigadores han confirmado que la cadena de infección no se apoya en hooks de instalación (preinstall/postinstall) sino en instrucciones para que el desarrollador invoque require() desde su código, lo que activa un descargador llamado WEL1DROPPER.

Cómo funciona técnicamente la campaña: el paquete malicioso introduce código que, una vez importado con require(), ejecuta un dropper que detecta sistema operativo y arquitectura de CPU. El dropper intenta descargar la siguiente etapa desde tres Workers de Cloudflare (dominios observados por los investigadores). Si la descarga HTTPS falla, la muestra recurre a un mecanismo alternativo basado en registros DNS TXT apuntando a un dominio de infraestructura (wel1[.]ru). En ese flujo, el dropper solicita primero un registro TXT que indica cuántos fragmentos de carga hay, pide esos fragmentos numerados, concatena las cadenas recibidas y las decodifica desde Base64 para reconstruir el binario, que luego se escribe en una carpeta temporal y se ejecuta con /bin/sh en Linux/macOS o cmd.exe en Windows.

En la etapa final, según Sonatype y otros análisis, el malware despliega comportamientos propios de amenazas persistentes: la muestra de Windows parchea ETW y AMSI para evadir detección, comprueba entornos de análisis/sandbox, establece persistencia (Run key y tarea programada), descarga un payload cifrado y lo ejecuta; macOS sigue una cadena similar con LaunchAgent; Linux descarga un ELF comprimido con UPX que acaba desplegando Sliver, un framework de C2 de código abierto. Las mismas publicaciones señalan además que muchos paquetes incluyen un archivo "lib/telemetry.js" —una SDK de telemetría aparente— que contiene el mismo downloader pero no es importado por el entrypoint, lo que sugiere intención de camuflar la finalidad maliciosa durante una revisión superficial.

Hechos confirmados: la existencia de cientos de paquetes maliciosos en npm con el patrón descrito, los dominios de Cloudflare Workers implicados, el uso de wel1[.]ru para la entrega por DNS TXT, la técnica de reconstrucción por fragmentos Base64 y la detección de Sliver en la cadena de Linux. Fuentes públicas que cubren el operativo y explican técnicas similares incluyen investigaciones de respuesta y análisis público (Cobertura de BleepingComputer) y documentación de la plataforma que se usa como infraestructura (Cloudflare Workers: documentación oficial).

Estimaciones e incertidumbres: algunos indicadores encontrados dentro de binarios macOS referencian dominios con nombres de servicios financieros rusos, por lo que los analistas estiman que el actor podría interesarse en objetivos del sector financiero ruso; esto es una inferencia basada en artefactos internos, no una declaración del atacante ni prueba de objetivos concretos. También se ha comentado que la campaña podría ser una evolución de otra operación denominada "Moika" observada anteriormente, pero la relación entre campañas es una hipótesis razonable basada en tácticas y objetivos, no una certidumbre probada.

¿A quién afecta esto? Desarrolladores y proyectos que importan paquetes de npm sin vetos estrictos, entornos de CI/CD que ejecutan código de dependencias en pipelines, y equipos de operaciones que no filtran egress hacia infraestructuras externas quedan expuestos. Además, cualquier estación de trabajo o servidor donde un desarrollador requiera un paquete comprometido (localmente o en builds automatizados) puede terminar ejecutando el dropper y recibir la carga maliciosa. Organizaciones con repositorios públicos o privadas que permitan paquetes de terceros sin control son de alto riesgo.

Consecuencias reales: la campaña permite exfiltración de credenciales y ambiente (según análisis previos de campañas similares), ejecución remota y persistencia del atacante en máquinas Windows, macOS y Linux, y la eventual incorporación de equipos a una botnet o a una infraestructura de C2 (Sliver) que facilita movimientos laterales y robo de datos. Para equipos de desarrollo, esto también implica riesgo de comprometer secretos y credenciales usadas en CI/CD, despliegues y repositorios.

Medidas concretas y urgentes que deberían tomar lectores y equipos técnicos:

1) No require() paquetes desconocidos ni de nombres sospechosos. Si debe evaluarse un paquete nuevo, revisarlo localmente en un entorno aislado o sandbox y no importarlo directamente en pipelines de producción.

2) Implementar políticas de allowlist/denylist en repositorios y gestores de paquetes. Use controles en la organización de npm, un proxy de registro interno (p. ej. Nexus, Artifactory) o bloqueo por nombre para evitar que paquetes externos se descarguen directamente en entornos de build.

3) Proteger pipelines CI/CD y evitar ejecución de código de dependencias sin revisión. No ejecute scripts ni procesos de terceros en etapas que tengan acceso a secretos; habilite separación de credenciales y variables de entorno, y aplique el principio de menor privilegio.

4) Aplicar escaneo de dependencias y análisis estático/ dinámico. Integrar herramientas como Snyk, Dependabot, o soluciones de SCA (Software Composition Analysis) para detectar paquetes maliciosos o inusuales; complementar con EDR/antivirus capaz de detectar trampas como manipulación de ETW/AMSI y binarios ofuscados/UPX.

5) Restringir el tráfico de salida y bloquear dominios/infrastructuras sospechosas. Filtrar egress con proxy/firewall para evitar descargas desde Cloudflare Workers/dominios externos no autorizados y bloquear comunicaciones hacia wel1[.]ru hasta investigar. Registrar y revisar conexiones salientes desde sistemas de compilación y estaciones de desarrollo.

6) Revisar persistencias y artefactos en endpoints. En Windows buscar Run keys, tareas programadas recientes y procesos hijos inusuales; en macOS listar LaunchAgents/Daemons; en Linux revisar binarios temporales, crontabs y procesos que hablen con infraestructuras externas. Use herramientas forenses para detectar Sliver o C2 activo.

7) Rotar credenciales y secretos expuestos. Si un proyecto o pipeline usó paquetes comprometidos, rote inmediatamente claves, tokens y certificados que hubieran podido estar accesibles y audite los logs de acceso para actividad inusual.

Por último, es clave adoptar una práctica sostenida de minimización de dependencias, revisión manual de paquetes críticos, y segregación entre entornos de desarrollo y producción. Campañas como ésta explotan la confianza implícita en ecosistemas abiertos: mitigarlas exige controles técnicos y cambios de proceso en la gestión de dependencias. Para quien necesite una visión técnica más amplia sobre paquetes maliciosos en registros públicos, las investigaciones de equipos de respuesta y blogs técnicos siguen actualizando IOCs y recomendaciones operativas (Unidad 42 de Palo Alto Networks, entre otras fuentes especializadas).