RAT distribuido mediante versiones maliciosas de Axios en npm

Informatec Digital » Recursos » RAT distribuido mediante versiones maliciosas de Axios en npm

La comunidad de desarrollo JavaScript acaba de llevarse uno de esos sustos que te hacen replantearte cómo confías en tus dependencias, como muestran casos de fallos en librerías. Axios, una de las bibliotecas HTTP más usadas en el ecosistema, fue manipulada en npm para distribuir un troyano de acceso remoto (RAT) mediante versiones aparentemente legítimas. El incidente apenas duró unas horas, pero ha dejado claro que la cadena de suministro de software pende de un hilo mucho más fino de lo que muchos pensaban.

Lo grave no es solo que los atacantes consiguieran colar malware en un paquete descargado decenas o cientos de millones de veces a la semana. El verdadero problema es que lo hicieron secuestrando la cuenta del mantenedor principal en npm, publicando versiones “oficiales” que parecían normales y que no tocaban ni una sola línea del código fuente de Axios. Todo el comportamiento malicioso vivía en una dependencia fantasma especialmente diseñada para el ataque.

Cómo se gestó el compromiso de Axios en npm

Para entender la magnitud del incidente hace falta empezar por el vector de entrada. El atacante logró tomar el control de la cuenta npm de “jasonsaayman”, el principal responsable de Axios, y cambió el correo asociado por una dirección bajo su control, alojada en Proton Mail. Desde ese momento tuvo vía libre para publicar nuevas versiones del paquete como si fuera el propio mantenedor.

Con esas credenciales, subió dos versiones maliciosas de Axios: 1.14.1 y 0.30.4, abarcando las dos ramas principales del proyecto. Las publicaciones se hicieron con apenas 39 minutos de diferencia y, según los análisis de StepSecurity, se realizaron directamente desde npm con un token clásico de larga duración, eludiendo completamente la canalización CI/CD habitual basada en GitHub Actions.

Dieciocho horas antes del golpe definitivo, el actor ya había publicado una versión “limpia” relacionada con la dependencia maliciosa en el registro de npm. Ese paso previo sirvió para generar historial y evitar que algunos controles automáticos saltaran al ver aparecer un paquete completamente nuevo en el momento del ataque.

Lo llamativo es que los atacantes no modificaron el código fuente de Axios ni introdujeron cambios visibles en el repositorio de GitHub. De hecho, las versiones 1.14.1 y 0.30.4 no tenían commits ni tags correspondientes en GitHub; solo existían en npm. La diferencia esencial estaba en el archivo de dependencias del paquete publicado en el registro.

Axios, en condiciones normales, solo declara tres dependencias: follow-redirects, form-data y proxy-from-env. Sin embargo, en las versiones comprometidas apareció una cuarta dependencia, inexistente hasta ese momento en el proyecto: plain-crypto-js en su versión 4.2.1. Esta librería fantasma no se utilizaba en ninguna parte del código de Axios, pero incluía un script postinstall que se ejecutaba automáticamente al instalar el paquete con npm, pnpm o herramientas similares.

plain-crypto-js: la dependencia fantasma que desplegaba el RAT

La clave del ataque estaba en esa dependencia adicional. plain-crypto-js fue publicada en npm por un usuario llamado “nrwise”, también con correo de Proton Mail, y su único propósito era ejecutar un script postinstalación ofuscado en Node.js (setup.js). Ese script actuaba como dropper, es decir, como instalador inicial de la segunda fase del malware.

Al instalar Axios en una de sus versiones envenenadas, el ciclo de vida postinstall de npm disparaba automáticamente el código de plain-crypto-js sin que el desarrollador tuviera que hacer nada especial. El dropper se conectaba a un servidor de comando y control (C2) activo en el dominio sfrclakcom, escuchando en el puerto 8000, y descargaba una carga útil específica según el sistema operativo de la máquina afectada; este comportamiento puede identificarse mediante análisis de tráfico de red.

Los investigadores de StepSecurity y otros equipos de análisis describen un comportamiento muy cuidado. Tras ejecutar la carga maliciosa, el dropper eliminaba sus propios rastros: borraba el script postinstall, reemplazaba el package.json por una versión “limpia” y dejaba un node_modules que, a simple vista, parecía inofensivo. De este modo, una inspección manual posterior no encontraba el código malicioso directamente dentro de Axios.

Para identificar la manipulación, la única pista fiable estaba en los lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock) y en la presencia de versiones concretas: axios 1.14.1 o 0.30.4 y plain-crypto-js 4.2.1, además de dos versiones de ese paquete con numeración intermedia (4.2.0, 4.2.2) relacionadas en algunos análisis. Socket, por su parte, detectó posteriormente que el mismo malware se distribuía también mediante los paquetes @shadanai/openclaw (varias versiones 2026.3.xx) y @qqbrowser/openclaw-qbot (0.0.130), y técnicas como honeypots en seguridad también pueden ayudar a identificar campañas similares.

RAT multiplataforma: Windows, macOS y Linux en el punto de mira

Una vez ejecutado, el script setup.js actuaba como un orquestador capaz de detectar el sistema operativo y seguir una ruta de ataque específica para cada plataforma. La campaña estaba claramente preparada de antemano: según StepSecurity, los atacantes tenían precompiladas tres cargas útiles separadas, una por cada sistema.

En sistemas macOS, el postinstall lanzaba un AppleScript que se encargaba de descargar un binario troyanizado desde el servidor sfrclakcom:8000. Ese binario se guardaba en la ruta /Library/Caches/com.apple.act.mond, se ajustaban sus permisos para hacerlo ejecutable y, por último, se arrancaba en segundo plano mediante /bin/zsh. Una vez puesta en marcha la RAT, el propio AppleScript se borraba para complicar aún más el análisis forense.

En máquinas Windows, el malware localizaba el binario de PowerShell del sistema, lo copiaba a %PROGRAMDATA%\wt.exe para camuflarlo como si fuera la terminal de Windows y generaba un script VBScript temporal. Ese VBScript contactaba de nuevo con el servidor C2 para descargar un script RAT adicional de PowerShell, lo ejecutaba y luego eliminaba el archivo descargado. Además, la variante para Windows creaba el archivo %PROGRAMDATA%\system.bat con una rutina de descarga que permitía recuperar el malware en cada inicio de sesión y añadía una clave de ejecución en el registro de Windows para garantizar persistencia.

En Linux y otros sistemas tipo Unix distintos de macOS, el dropper utilizaba execSync de Node.js para lanzar un comando de shell que descargaba un script Python desde sfrclakcom, lo guardaba como /tmp/ld.py y lo ejecutaba con nohup para mantenerlo activo en segundo plano. A diferencia de Windows, en esta variante no se observó un mecanismo de persistencia consolidado, lo que indica un enfoque más orientado a la exfiltración rápida de datos o al despliegue puntual de persistencia mediante comandos posteriores.

SafeDep y Elastic Security Labs analizaron las cargas de segundo nivel y concluyeron que las RAT para macOS (binario C++ Mach-O) y Linux (script Python) compartían el mismo conjunto de comandos, protocolo C2, formato de mensajes y comportamiento operativo. Ese tipo de análisis suele apoyarse en servicios de escaneo como VirusTotal, que facilitan la correlación de muestras y IOC.

En todos los casos, cada host comprometido realizaba un reconocimiento inmediato del sistema: directorios de usuarios, raíces de unidades, procesos activos y otros metadatos. Esa información se enviaba al servidor de mando y control y el agente mantenía un bucle de baliza de unos 60 segundos, quedando a la espera de instrucciones nuevas, incluida la ejecución de scripts adicionales o la inyección de binarios en memoria.

Ventana de exposición, objetivos y atribución a Corea del Norte

Las versiones maliciosas de Axios estuvieron disponibles en npm aproximadamente durante tres horas, en una franja horaria cuidadosamente elegida. Los paquetes comprometidos se publicaron justo antes de medianoche del domingo (en horario que maximizaba el tiempo de reacción de los defensores), y el incidente se contuvo hacia la madrugada del lunes, después de que empresas de seguridad alertaran del comportamiento anómalo.

Durante ese intervalo relativamente corto, Huntress detectó al menos 135 sistemas que se conectaron al servidor del atacante. Dado que Axios registra más de 80-100 millones de descargas semanales (según distintas fuentes, incluso más de 300 millones en algunos periodos), ese número probablemente solo representa la punta del iceberg, limitado a los sistemas que entran en el radar de las firmas de análisis que han hecho públicos sus datos.

Google, a través de su equipo de Threat Intelligence, atribuyó el ataque a un presunto actor norcoreano etiquetado como UNC1069. Elastic Security Labs reforzó esta hipótesis al encontrar una fuerte similitud entre la RAT entregada en macOS y WAVESHAPER, una puerta trasera en C++ descubierta por Mandiant y también vinculada a ese mismo grupo de amenazas.

Los analistas de Google subrayaron que los grupos asociados a Corea del Norte llevan años especializándose en ataques a la cadena de suministro y operaciones destinadas al robo de criptomonedas. El patrón encaja: comprometer infraestructuras de desarrollo, librerías de uso masivo o software de confianza para moverse lateralmente hacia objetivos donde se gestionan activos económicos, claves privadas o credenciales de alto valor.

Varios informes destacaron además que la moderación y el diseño del ataque daban la sensación de un equipo bien coordinado: tres implementaciones paralelas de la misma RAT (PowerShell, C++ y Python), un protocolo C2 coherente, un comportamiento casi calcado en todas las variantes y una estrategia clara de autolimpieza para evitar dejar huellas. Elastic remarcó que esa coherencia apunta a un único desarrollador o a un grupo que trabaja sobre un documento de diseño compartido, lejos de la improvisación.

Ingeniería social avanzada contra el mantenedor de Axios

Más allá del aspecto puramente técnico, uno de los puntos más inquietantes del caso es cómo se produjo el secuestro de la cuenta npm del mantenedor principal. El propio responsable de Axios explicó después que tenía activada la autenticación de doble factor en casi todos sus servicios y, aun así, acabó concediendo acceso sin darse cuenta.

Según el análisis post-mortem compartido por el equipo, los atacantes montaron una operación de ingeniería social muy elaborada, apoyada en herramientas impulsadas por IA, para ganarse su confianza. Se hicieron pasar por el fundador de una empresa, copiando su identidad visual, su fotografía y hasta la marca corporativa. Crearon un espacio real de Slack con el logo de la compañía, canales con publicaciones supuestamente sincronizadas con LinkedIn e incluso perfiles falsos de empleados y de otros mantenedores de software libre.

Dentro de ese entorno, programaron una reunión a través de Microsoft Teams en la que parecía participar un grupo completo de profesionales. Durante el encuentro, simularon un problema técnico y le indicaron que tenía un componente de su sistema desactualizado. El mantenedor, asumiendo que se trataba de un requisito legítimo relacionado con la propia herramienta de videoconferencia, descargó e instaló el archivo sugerido.

Ese archivo era, en realidad, el troyano de acceso remoto que permitió a los atacantes pivotar hasta sus credenciales y, finalmente, tomar el control de la cuenta npm utilizada para publicar Axios. Todo el proceso estaba tan bien orquestado, con tantos detalles creíbles, que la víctima lo describió como algo “perfectamente coordinado, profesional y completamente convincente”.

Este componente humano del incidente deja claro que ni siquiera las medidas técnicas como el 2FA son suficientes cuando se combina ingeniería social de alto nivel con suplantación de identidad visual, deepfakes o clonación detallada de organizaciones. El eslabón más débil vuelve a ser, una vez más, la interacción humana.

Impacto para organizaciones y desarrolladores que usan Axios

Desde el punto de vista práctico, el principal problema es determinar quién se vio realmente afectado. Cualquier organización que haya instalado axios@1.14.1 o axios@0.30.4 durante la ventana en la que estuvieron disponibles debe partir de la premisa de que la máquina o el pipeline que realizó la instalación puede estar comprometido.

Las recomendaciones de firmas como StepSecurity, Aikido, Huntress o Elastic son contundentes. En caso de sospecha, se debe asumir compromiso y no limitarse a “borrar y reinstalar node_modules”. Lo prudente es reconstruir las máquinas o entornos afectados desde imágenes de confianza y revisar cuidadosamente los logs de CI/CD para identificar qué jobs o pipelines pudieron ejecutar las versiones manipuladas.

Además, es crítico rotar todas las credenciales y secretos a los que pudiera haber accedido el RAT desde esos nodos: tokens de npm, claves de proveedores cloud, secretos almacenados en el pipeline, credenciales de bases de datos, llaves SSH, etc. Dejar esas credenciales en circulación tras un ataque de este tipo es dejar la puerta abierta a movimientos laterales silenciosos.

A nivel técnico, los equipos deben revisar sus ficheros de bloqueo (package-lock.json, pnpm-lock.yaml, yarn.lock) en busca de referencias a las versiones comprometidas de Axios y a plain-crypto-js. Si aparecen estos elementos, el siguiente paso es inspeccionar los posibles artefactos del RAT en los sistemas afectados: /Library/Caches/com.apple.act.mond en macOS, %PROGRAMDATA%\wt.exe y %PROGRAMDATA%\system.bat en Windows, o /tmp/ld.py en Linux.

En paralelo, se recomienda fijar de forma explícita versiones seguras de Axios, como 1.14.0 y 0.30.3, y utilizar mecanismos de overrides o resolutions para impedir que las dependencias transitivas puedan resolver hacia versiones no deseadas. Bloquear el tráfico saliente hacia el dominio sfrclakcom también es una medida de contención sensata, al menos mientras se analiza el alcance completo del ataque.

Lecciones de seguridad para la cadena de suministro de software

El incidente de Axios no es un suceso aislado, sino otro eslabón en una cadena de ataques a la cadena de suministro que incluye casos como SolarWinds, Kaseya, 3CX, Polyfill.io o vulnerabilidades explotadas en Log4j. La idea central es siempre la misma: comprometer una pieza de confianza ampliamente utilizada para maximizar el alcance, en lugar de intentar atacar máquina por máquina.

Una de las lecciones más repetidas por los expertos es que la confianza no puede recaer solo en la popularidad de una librería o en la reputación de un mantenedor. Si el canal de publicación (la cuenta en npm, el pipeline de CI/CD, la infraestructura de build) se ve comprometido, todo lo que se publica a través de él hereda ese riesgo. La revisión manual de código tampoco basta si el malware se esconde en dependencias transitivas y se borra tras ejecutarse.

También se ha puesto de relieve que la “velocidad por defecto” en la actualización de dependencias tiene un coste en superficie de ataque. Adoptar siempre la última versión automáticamente es cómodísimo, pero abre la puerta a que una actualización maliciosa se propague en cuestión de minutos. Algunas organizaciones ya están valorando políticas como exigir que una nueva versión lleve cierto tiempo en el ecosistema antes de adoptarla, o que cambios en paquetes críticos pasen por una revisión manual adicional.

En cuanto a la infraestructura de desarrollo, los entornos de CI/CD deben tratarse como activos de máxima sensibilidad. Cualquier RAT que se ejecute durante la instalación de dependencias va a buscar, casi con total seguridad, los secretos del pipeline y el acceso a otros entornos. Segmentar estos nodos, monitorizarlos con más celo y rotar sus secretos de manera periódica deja de ser una recomendación “ideal” para convertirse en una necesidad.

Por último, la detección de este tipo de ataques requiere combinar información de múltiples fuentes: versiones instaladas, lockfiles, indicadores de compromiso en el sistema operativo y telemetría de red. Herramientas que generan y gestionan SBOM (Software Bill of Materials) ayudan a trazar rápidamente qué proyectos usan qué paquetes, algo vital cuando saltan alertas masivas como esta.

Todo este episodio con Axios ilustra hasta qué punto el ecosistema de dependencias, por muy maduro y consolidado que parezca, sigue dependiendo en buena medida de la confianza y de la vigilancia constante. Una librería aparentemente inocua, mantenida por una sola persona que sufre una buena maniobra de ingeniería social, puede convertirse en cuestión de horas en un vector global para desplegar RATs multiplataforma en empresas, freelancers y organizaciones de todos los tamaños; reforzar los controles alrededor de cuentas de publicación, pipelines y dependencias críticas ya no es una buena práctica opcional, sino una condición para seguir desarrollando en un entorno donde los atacantes juegan cada vez con más paciencia, más recursos y mejores herramientas.

Artículo relacionado:

Scripting y hardening de sistemas: guía completa para reforzar servidores