La campaña de ataque a la cadena de suministro de npm que imita a Alibaba y despliega un RAT multiplataforma

Investigadores de seguridad han identificado una campaña de ataque a la cadena de suministro que utiliza paquetes maliciosos en npm para dirigirse a desarrolladores que usan herramientas del ecosistema de Alibaba. La técnica no es un simple paquete único con código malicioso, sino una estructura por capas donde versiones aparentemente inocuas y paquetes "señuelo" con nombres idénticos a paquetes privados del ámbito @ali activan una red de dependencias que finalmente descarga y ejecuta un backdoor complejo.

El vector inicial incluía paquetes no scopeados como lib-mtop, que coincide en nombre con un paquete privado de Alibaba, y varias librerías adicionales publicadas desde la misma cuenta de mantenedor. Las versiones públicas dejaron pasar cambios en marzo/abril que añadieron un loader capaz de obtener un payload remoto (invocando curl) y ejecutar código JavaScript delimitado por una "rule engine" que usa el módulo vm de Node.js para decidir comportamiento por sistema operativo.

La campaña muestra un diseño cuidadoso para evadir detección: la carga útil secundaria se descarga desde un dominio que imita a Alibaba y el código malicioso está fragmentado en varios paquetes de la cadena de dependencias, de forma que el paquete que el desarrollador instala actúa como señuelo y la lógica real se materializa a través de middle- y low-layer packages. Esta separación dificulta el análisis manual y automatizado en revisiones rápidas de dependencias.

El payload final es un RAT multiplataforma con capacidades de ejecución remota, exfiltración, reconocimiento del host, staging de cargas adicionales y movimiento lateral. En Windows reemplaza o troyaniza componentes de seguridad y apps corporativas; en Linux descarga binarios en /tmp y los ejecuta en memoria; en macOS modifica arranques de shell y crea Launch Agents. Además puede persistir inyectando código en aplicaciones de colaboración empresarial como DingTalk, incrementando el riesgo de espionaje dirigido.

Aunque la atribución no está confirmada, hay indicios operacionales en los comentarios en chino y en marcas temporales con UTC+08:00 que apuntan a un actor de habla china. El objetivo aparente es la espionaje industrial contra desarrolladores en empresas vinculadas al Grupo Alibaba, lo cual convierte a esta campaña en un riesgo estratégico más que en una simple campaña de malware masiva.

Si has instalado alguno de los paquetes asociados (por ejemplo lib-mtop, aone-kit, smart-config-manager, local-config-parser y otros relacionados), debes asumir compromiso y actuar de inmediato desde máquinas limpias. Las acciones prioritarias incluyen rotar credenciales y claves desde un equipo que sabes no está comprometido; auditar sistemas de desarrollo y CI en busca de procesos persistentes; y buscar indicadores como entradas en ~/.zshrc, LaunchAgents en macOS, binarios ejecutados desde /tmp en Linux y servicios o DLLs modificadas en Windows.

Adicionalmente, conviene comprobar repositorios y flujos de CI: revisar y rotar tokens de publicación en npm y credenciales de GitHub, deshabilitar runners autoalojados hasta auditar su estado y extinguimos posibles webhooks filtrantes. Comandos simples de comprobación pueden ayudar: revisar package-lock.json/yarn.lock, ejecutar npm ls en los proyectos, y buscar las cadenas de nombre de paquete en el árbol de dependencias. También es recomendable limpiar caches y reinstalar dependencias desde lockfiles confiables o desde un registro interno.

Para mitigar riesgos futuros, activa autenticación multifactor en cuentas de npm y GitHub, limita permisos de publicación por equipo, emplea revisiones de dependencias en pull requests y considera políticas de bloqueo para paquetes no scopeados que puedan impersonar nombres internos. Herramientas de revisión de cadena de suministro y escaneo de dependencias pueden automatizar detección temprana; la documentación de GitHub sobre seguridad de la cadena de suministro y la guía de npm sobre prácticas seguras son buenos puntos de partida para implementar controles: Guía de seguridad de la cadena de suministro de GitHub y Buenas prácticas de seguridad de npm.

Si administras una organización, valora el uso de un registry privado o políticas de proxy que permitan auditar y aprobar paquetes antes de su consumo en entornos corporativos, y monitoriza el tráfico saliente hacia dominios sospechosos (por ejemplo el usado por los atacantes para mimetizar OSS de Alibaba). Para análisis y escaneo adicionales de dependencias, proyectos como OWASP Dependency-Check ofrecen recursos útiles para identificar componentes comprometidos: OWASP Dependency-Check.

En resumen, este incidente refuerza que la seguridad del software moderno depende tanto de la higiene en repositorios y entornos CI como del control estricto de qué paquetes se permiten en producción. La fragmentación deliberada de la funcionalidad maliciosa en múltiples módulos y el uso de señuelos que imitan paquetes privados subrayan la importancia de controles organizativos (políticas de publicación, permisos mínimos) y técnicos (escaneo automatizado, monitors de egress y detección de persistencia) para reducir la superficie de ataque.