Ataque a la cadena de suministro de Axios: qué sucedió y cómo proteger su entorno

El 31 de marzo de 2026, unos atacantes utilizaron la cuenta npm comprometida del principal responsable del mantenimiento de Axios para publicar dos versiones maliciosas del paquete en el registro. Estas versiones comprometidas incluían una nueva dependencia con un programa malicioso multiplataforma que descarga e instala un troyano de acceso remoto (RAT) específico de la plataforma en cualquier máquina que haya instalado el paquete mediante npm. El programa se conecta a un servidor de comando y control predefinido, descarga cargas útiles específicas para macOS, Windows o Linux, y luego borra del disco toda evidencia de sí mismo y del contenido malicioso del paquete, dejando únicamente el RAT instalado.

¿Qué es Axios?

Axios es la biblioteca cliente HTTP más utilizada en el ecosistema JavaScript. Frameworks de frontend, servicios de backend, herramientas de CI/CD, aplicaciones internas empresariales: si realiza una solicitud HTTP en Node.js o en el navegador, es muy probable que Axios esté involucrado. Cualquier proyecto que utilice un rango estándar como ^1.14.0 en su package.json se habría instalado automáticamente con la versión maliciosa en su siguiente instalación, sin cambios visibles en el código fuente de Axios ni indicios en el nombre del paquete, el editor o el número de versión que sugieran algún problema.

Axios cuenta con más de 100 millones de descargas semanales y forma parte del árbol de dependencias de casi todas las aplicaciones Node.js que realizan solicitudes HTTP, lo que le confiere un potencial de vulneración de seguridad extremadamente grave.

¿Cómo se descubrió esto?

El escáner automatizado de Socket Security detectó la dependencia maliciosa plain-crypto-js@4.2.1 a los seis minutos de su publicación. StepSecurity identificó de forma independiente ambas versiones comprometidas de Axios y publicó un análisis técnico completo, confirmando mediante análisis en tiempo de ejecución que el malware realizó su primera llamada C2 1,1 segundos después de que comenzara la instalación de npm.

Feross Aboukhadijeh, cofundador de Socket, publicó la alerta pública:

"Ataque activo a la cadena de suministro de Axios, uno de los paquetes más utilizados por npm. Se trata de un malware típico de instalación en la cadena de suministro."

El equipo de seguridad de npm retiró ambas versiones infectadas y las reemplazó con versiones de prueba de Security-Holder. Axios@1.14.1 estuvo activa durante aproximadamente tres horas, y Axios@0.30.4 durante unas dos horas y quince minutos. Durante ese tiempo, el responsable legítimo, Jason Saayman, no pudo acceder a su cuenta, y un colaborador de Axios informó en GitHub que no pudieron revocar el acceso del atacante porque sus permisos excedían los suyos.

Análisis técnico 

Versiones afectadas 

Las dos versiones comprometidas son axios@1.14.1 y axios@0.30.4. Tanto la rama moderna 1.x como la antigua 0.x fueron infectadas con tan solo 39 minutos de diferencia. Las versiones seguras para fijar son axios@1.14.0 y axios@0.30.3. Socket también identificó dos paquetes adicionales que distribuían la misma carga útil a través de dependencias: @shadanai/openclaw y @qqbrowser/openclaw-qbot@0.0.130.

Cómo se desarrolló el ataque

El atacante comprometió la cuenta npm de jasonsaayman (el principal responsable del mantenimiento de Axios), cambió su correo electrónico registrado por una dirección anónima de ProtonMail y publicó ambas versiones maliciosas directamente a través de la CLI de npm, eludiendo por completo el proceso habitual de GitHub Actions del proyecto. No existen confirmaciones, etiquetas ni versiones correspondientes en el repositorio de GitHub de Axios para ninguna de las dos versiones.

Dieciocho horas antes del ataque a Axios, una cuenta desechable (nrwise, también con ProtonMail) publicó plain-crypto-js@4.2.0. Esta es una copia limpia de la biblioteca crypto-js legítima, diseñada únicamente para generar un historial de publicaciones en npm y evitar las alertas de los escáneres de historial cero.

A las 23:59 UTC del 30 de marzo, el atacante publicó plain-crypto-js@4.2.1 con una carga útil ofuscada y un archivo package.json limpio preconfigurado, listo para la destrucción de pruebas tras la ejecución.

Veintidós minutos después, axios@1.14.1 se puso en marcha con una única dependencia nueva añadida: "plain-crypto-js": "^4.2.1", un paquete que nunca se importó ni se mencionó en ninguna parte del código fuente de Axios. Su único propósito era activar el gancho postinstall de npm.

Flujo de explotación 

El programa malicioso (setup.js) utiliza ofuscación de dos capas: inversión de cadenas más base64, seguida de descifrado XOR para ocultar todas las cadenas sensibles en reposo y decodificarlas únicamente en tiempo de ejecución. Importa dinámicamente `child_process`, `os` y `fs` para evitar la detección mediante análisis estático, y luego se ramifica según el sistema operativo objetivo.

1. npm resuelve plain-crypto-js@4.2.1 como una dependencia de la versión comprometida de Axios y la instala automáticamente.
2. El gancho postinstall se activa, ejecutando node setup.js antes de que finalice npm install.
3. El dropper identifica el sistema operativo mediante os.platform() y contacta con el servidor C2 en sfrclak[.]com:8000 con un identificador de plataforma, disfrazado como una URL del registro de npm en el cuerpo de la solicitud POST.
4. Distribución de RAT específica de la plataforma:
   • macOS: AppleScript descarga un binario en /Library/Caches/com.apple.act.mond (simulando el nombre de un demonio de Apple), lo hace ejecutable y lo inicia mediante /bin/zsh.
   • Windows: Copia powershell.exe legítimo a %PROGRAMDATA%\wt.exe (disfrazado como Terminal de Windows) y luego ejecuta una cadena oculta de VBScript/PowerShell para obtener y ejecutar el RAT con -ExecutionPolicy Bypass. Linux: curl descarga un RAT de Python a /tmp/ld.py y lo ejecuta de forma independiente con nohup python3, asegurando su supervivencia tras la finalización del proceso padre.
   • Autodestrucción: El dropper elimina setup.js, borra el package.json que contiene el hook postinstall y renombra un stub limpio preconfigurado en su lugar. La inspección posterior a la infección de node_modules/plain-crypto-js/ no revela nada sospechoso.
5. Self-destruction: The dropper deletes setup.js, removes the package.json containing the postinstall hook, and renames a pre-staged clean stub into its place. Post-infection inspection of node_modules/plain-crypto-js/ reveals nothing suspicious.

El análisis estático y en tiempo de ejecución completo de StepSecurity, que incluye las cadenas descifradas del troyano y el árbol de procesos de Harden-Runner, está disponible en https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan.

El análisis de Socket se encuentra en https://socket.dev/blog/axios-npm-package-compromised.

Una característica importante del RAT es que carece de mecanismo de persistencia. Si se reinicia un dispositivo infectado, aunque el binario seguirá existiendo en el disco, no se ejecutará. Esto podría ser intencional por parte del atacante, ya que establecer un mecanismo de persistencia haría que el RAT fuera más visible para los sistemas EDR y de defensa. Alternativamente, podría ser que el RAT estuviera diseñado para conectarse al servidor C2 y recuperar una carga útil secundaria o recibir comandos que establecieran la persistencia. También podría ser que el atacante pretendiera reservar la funcionalidad de persistencia solo para sus objetivos específicos o víctimas de alto valor. Algunos informes han identificado mecanismos de persistencia de Windows en dispositivos comprometidos, pero aún no está claro si estos se crean mediante comandos C2 posteriores a la infección o mediante una modificación del proceso de infección genérico inicial.

Atribución y propósito 

ACTUALIZACIÓN 01-04-2026: Este ataque probablemente fue perpetrado por UNC1069, un actor malicioso patrocinado por el Estado de la RPDC con fines lucrativos. Esta atribución se basa en múltiples coincidencias de confianza media con la actividad previa de UNC1069, tales como:

Malware

• Las URL del servidor de comando y control (C2) se proporcionan dinámicamente en la línea de comandos.
• Se utiliza la misma cadena de agente de usuario poco común para la transmisión de señales.
• Se utiliza la misma ubicación de directorio temporal en macOS.

C2

• Se observaron conexiones a la dirección C2 de axios desde un nodo VPN de Astrill utilizado previamente por UNC1069.
• La infraestructura adyacente en el mismo sistema autónomo (ASN) que la dirección C2 de axios se ha vinculado históricamente con UNC1069.

La funcionalidad del RAT es genérica y versátil, como se espera de un RAT en etapa inicial, con comandos predefinidos como:

1. Autodestrucción
2. Descarga y ejecución de un binario
3. Ejecución de scripts y comandos
4. Enumeración de directorios (los objetivos predefinidos eran /home/user/.ssh y /etc/passwd)

La funcionalidad del RAT podría ser útil para cualquier atacante, y al no incluir funcionalidades maliciosas específicas (como la minería de criptomonedas o el robo de credenciales), su probabilidad es menor. Se sospecha que el RAT sería detectado por EDR. La vulneración de los paquetes fue rápida y las acciones llevadas a cabo de forma relativamente sigilosa; sin embargo, esto no permite identificar al atacante como un Estado o un atacante con fines lucrativos, ya que cualquiera de ellos podría haber realizado este ataque si hubiera tenido acceso a la cuenta del mantenedor.

Actores de la RPDC han realizado repetidamente ataques a la cadena de suministro de software dirigidos a desarrolladores de criptomonedas. Si bien Axios no se utiliza exclusivamente para proyectos de software relacionados con criptomonedas, su uso es extremadamente extendido, por lo que probablemente se superpondría con ese subconjunto de desarrolladores.

La clave XOR utilizada incluye varios sietes, lo que suele indicar que el atacante es chino, pero también parece hacer referencia a la "Orden 66" de Star Wars, una franquicia poco popular en China.

Es posible que pronto se encuentren más pruebas de atribución mediante el análisis forense de las acciones de npm y/o GitHub sobre la cuenta del mantenedor comprometida, o del método de vulneración de dicha cuenta, aunque la atribución del ataque probablemente no aporte mucha más claridad.

Cómo detectar si estás afectado 

1. Revisa tu archivo lockfile en busca de referencias a axios@1.14.1, axios@0.30.4 o plain-crypto-js. Si existe node_modules/plain-crypto-js/ en algún proyecto, el dropper se ejecutó en esa máquina, aunque la rutina de limpieza haya reemplazado su contenido con un archivo ficticio aparentemente inofensivo.
2. Busca artefactos de RAT en las rutas específicas de la plataforma: /Library/Caches/com.apple.act.mond en macOS, %PROGRAMDATA%\wt.exe en Windows y /tmp/ld.py en Linux. Ten en cuenta que la autolimpieza del dropper puede significar que estos ya no existan.
3. Revisa la telemetría de red en busca de conexiones salientes a sfrclak[.]com o 142.11.206.73 en el puerto 8000. Este es el indicador más fiable, ya que los artefactos del sistema de archivos se autoeliminan, pero los registros de red persisten.
4. Auditar las canalizaciones de CI/CD en busca de cualquier flujo de trabajo que haya ejecutado npm install entre las 00:21 y las 03:15 UTC del 31 de marzo. Estos tuvieron acceso a secretos inyectados y claves de despliegue.

Si sospecha que su sistema está afectado: 

Cambie a la versión 1.14.0 o 0.30.3 de axios, elimine `node_modules/plain-crypto-js` y reinstale con `npm install --ignore-scripts`. Si encuentra artefactos de RAT, considere el sistema completamente comprometido y restaure a partir de una imagen segura.

Rote todas las credenciales accesibles en la máquina comprometida: contraseñas guardadas, tokens de npm u otros, claves SSH, claves de acceso a la nube, contenido de `.env` y secretos de CI/CD.

Bloquee `sfrclak[.]com` y `142.11.206.73` en su firewall y en la capa DNS.

Refuerza tu cadena de suministro 

1. Fija las versiones exactas de las dependencias y confirma tu archivo de bloqueo. Los rangos de caracteres permitieron la resolución automática de la versión maliciosa. Usa `npm ci` en CI/CD para garantizar instalaciones solo con archivo de bloqueo.
2. Deshabilita los scripts de postinstalación en las compilaciones automatizadas con `npm ci --ignore-scripts`. Toda la cadena de ataque depende del gancho del ciclo de vida de postinstalación de npm, y la mayoría de los paquetes no lo necesitan.
3. Establece una antigüedad mínima para los paquetes, por ejemplo, configurando `min-release-age=7` en `.npmrc`. Herramientas como Safe Chain de Aikido también pueden bloquear paquetes publicados dentro de un período de espera configurable. La versión maliciosa del paquete `plain-crypto-js@4.2.1` había existido durante menos de 24 horas, e incluso un límite de antigüedad de 48 horas para los paquetes nuevos habría evitado la explotación.
4. Controla el tráfico de salida de los ejecutores de CI/CD: el dropper se comunica con su servidor en 1,1 segundos después de la instalación. Si sus ejecutores permiten conexiones salientes sin restricciones, cualquier script posterior a la instalación puede llegar a cualquier servidor C2.

Una historia conocida 

El ataque a Axios sigue el mismo patrón que todos los ataques importantes a la cadena de suministro de npm del último año: credenciales de mantenedor comprometidas, un pequeño cambio en el manifiesto de dependencias y un hook postinstall que ejecuta una carga útil autodestructible. En septiembre de 2025, el robo de credenciales mediante phishing provocó el compromiso de Chalk y Debug (con más de 2 mil millones de descargas semanales combinadas). Ese mismo mes, el gusano Shai-Hulud se convirtió en el primer malware de npm con capacidad de propagación. Para diciembre, su segunda iteración había robado aproximadamente 400 000 secretos de desarrolladores.

Recientemente, npm ha anunciado mejoras de seguridad planificadas, como la autenticación de dos factores (2FA) FIDO obligatoria, la desactivación de tokens de automatización por defecto y la publicación segura. Sin embargo, estas mejoras aún están en desarrollo. Hasta que se implementen, son las herramientas de terceros y la concienciación de los desarrolladores las que deben detectar lo que npm no detecta.

¿Necesita ayuda?

Si sospecha que su organización se ha visto afectada por este incidente y necesita asistencia urgente, o si desea evaluar la vulnerabilidad de su cadena de suministro antes del próximo ataque, LRQA puede ayudarle.

Contáctenos 

Indicadores de Compromiso (IOC)