Ataque a la Cadena de Suministro de Axios
Anatomía de una vulnerabilidad en el corazón de JavaScript
El 31 de marzo de 2026 se identificó un ataque de cadena de suministro contra Axios, una de las librerías HTTP más utilizadas en el ecosistema JavaScript, distribuida a través del registro npm y con una cantidad de descargas semanales de entre70 a 100 millones. El atacante comprometió la cuenta npm del mantenedor principal y publicó dos versiones maliciosas (axios@1.14.1 y axios@0.30.4) que incorporaban una dependencia fantasma (plain-crypto-js@4.2.1) usada exclusivamente para desplegar un troyano de acceso remoto (RAT) multiplataforma en Windows, macOS y Linux.
La intrusión se ha atribuido con un alto nivel de confianza a un actor norcoreano de tipo estatal y cuya motivación es predominantemente financiera, rastreado como UNC1069 / STARDUST CHOLLIMA / BlueNoroff dependiendo de la empresa de seguridad que se utilice como referencia. El malware observado es el WAVESHAPER.V2, y las variantes ZshBucket/macWebT y un dropper denominado SILKBELL, eso demuestra continuidad con campañas previas de compromiso de cadenas de suministro orientadas al robo de credenciales en entornos de desarrollo y de nube.
La ventana de exposición de las versiones maliciosas fue de aproximadamente tres horas (aprox. 00:21–03:15/03:20 UTC del 31 de marzo de 2026), pero la ubicuidad de Axios como dependencia directa y transitiva implica que cualquier desarrollador, pipeline CI/CD o entorno de producción que ejecutara npm install durante ese intervalo y resolviera a dichas versiones debe considerarse potencialmente comprometido. El impacto incluye la posible exfiltración de claves de nube, tokens de CI/CD, credenciales SSH y acceso persistente a infraestructuras críticas.
Contexto y antecedentes
Axios es un cliente HTTP basado en promesas ampliamente utilizado en aplicaciones web y Node.js, con decenas o cientos de millones de descargas semanales y presencia en un altísimo porcentaje de entornos cloud y proyectos JavaScript. Al ser además una dependencia transitiva de innumerables paquetes, su compromiso como eslabón de la cadena de suministro genera un efecto multiplicador: proyectos que nunca declararon Axios explícitamente pudieron verse afectados a través de dependencias de terceros.
Los ataques a la cadena de suministro de software de código abierto (npm, PyPI, etc.) se han consolidado como una técnica habitual de actores estatales y criminales avanzados, que buscan maximizar alcance comprometiendo componentes muy populares en lugar de atacar directamente a cada víctima final. Campañas recientes contra otros paquetes y herramientas de CI/CD (por ejemplo, casos de Trivy o TeamPCP) muestran patrones similares: obtención de ejecución en entornos de confianza y pivotaje rápido hacia robo de credenciales y acceso a infraestructuras de nube.
Cronología del incidente
Basado en fuentes técnicas se obtiene la siguiente cronología aproximada (UTC):
30 de marzo, 05:57: publicación de
plain-crypto-js@4.2.0como señuelo benigno, clon casi bit‑a‑bit decrypto-js@4.2.0.30 de marzo, 23:59: publicación de
plain-crypto-js@4.2.1con la única diferencia significativa de un scriptpostinstall(node setup.js) que actúa como dropper.31 de marzo, 00:21: publicación de
axios@1.14.1, etiquetada comolatest.31 de marzo, ~01:00: publicación de
axios@0.30.4, cubriendo la rama 0.x/legacy.31 de marzo, ~03:15–03:20: npm despublica las versiones maliciosas de Axios y sustituye
plain-crypto-jspor un stub de seguridad.31 de marzo, primeras horas: diversos proveedores (StepSecurity, Elastic, Huntress, Trend Micro, Snyk, etc.) publican análisis iniciales y avisos; Elastic registra la creación de advisory en GitHub sobre las 01:50 UTC.
31 de marzo–1 de abril: Microsoft, Google GTIG, Google Cloud y otros emiten informes de inteligencia, confirmando la naturaleza de RAT multiplataforma y relacionándolo con actores norcoreanos.
Visión general del actor de amenaza
Identidades, atribución y confianza
La atribución no es unánime pero converge en un clúster norcoreano con motivación financiera:
Google Threat Intelligence Group atribuye el compromiso a UNC1069, descrito como actor de Corea del Norte de motivación financiera, con historial de ataques a cadenas de suministro y robo de criptomonedas.
CrowdStrike atribuye con confianza moderada la operación a STARDUST CHOLLIMA, subgrupo de Lazarus vinculado a campañas previas con el malware ZshBucket, aunque reconoce solapamiento de infraestructura con FAMOUS CHOLLIMA.
Otras fuentes enlazan UNC1069 y BlueNoroff, subunidad de Lazarus especializada en compromisos financieros, y relacionan WAVESHAPER.V2 y la etiqueta interna
macWebTcon módulos previos usados por BlueNoroff en la campaña RustBucket.
En conjunto, la evidencia técnica (reutilización de código, infraestructura, tooling) y el histórico de operaciones orientadas a monetización respalda una atribución a ecosistema Lazarus/BlueNoroff con motivación financiera, aunque la comunidad mantiene grados de confianza diferentes según proveedor.
Motivaciones y objetivos
Aunque en el momento de los primeros informes no se observó despliegue directo de ransomware ni robo inmediato de criptomonedas, la TTP encaja plenamente con campañas de obtención de acceso inicial y robo de credenciales para ataques posteriores de tipo financiero.
Los objetivos técnicos observados incluyen:
Compromiso de entornos de desarrollo y CI/CD con alto nivel de privilegios.
Recolección de secretos (tokens de despliegue, claves de nube, credenciales de repositorios) y llaves SSH.
Establecimiento de persistencia para operaciones de espionaje y/o preparación de ataques de monetización (por ejemplo, desvío de fondos, manipulación de despliegues, inserción de backdoors adicionales).
Campañas y alcance observado
La campaña documentada se centra en un único vector de distribución (Axios npm) pero con enorme alcance potencial, al ser uno de los paquetes más descargados del registro npm. Cálculos de varios proveedores estiman que, pese a la breve ventana de exposición, la ejecución efectiva del payload se produjo en aproximadamente un 3% de los entornos afectados, lo que, a la escala del ecosistema, se traduce en miles de terminales y pipelines comprometidos.
Huntress reportó al menos 135 endpoints observados conectándose a la infraestructura de mando y control (C2) durante la ventana, en una base de clientes limitada, lo que sugiere que el número real global es muy superior. Unit 42 y Elastic indican patrones consistentes de ejecución inmediatamente después de npm install de las versiones maliciosas, particularmente en estaciones de desarrolladores y runners de CI.
Sectores y regiones objetivo
No se han identificado listas de objetivos específicas codificadas en el malware; cualquier consumidor de Axios durante la ventana podía convertirse en víctima, lo que caracteriza a la campaña como oportunista pero diseñada para capturar accesos de alto valor. Dado el perfil de uso de Axios y la distribución geográfica del ecosistema JavaScript, es razonable suponer impacto en:
Proveedores SaaS, fintech, plataformas de criptomonedas y servicios en la nube.
Grandes empresas tecnológicas con pipelines de despliegue automatizados basados en Node.js.
Startups y organizaciones medianas con fuertes dependencias de paquetes npm sin controles de cadena de suministro maduros.
La atribución a actores norcoreanos enfocados en generación de ingresos refuerza la hipótesis de que, entre las víctimas, se priorizarán organizaciones del sector financiero y cripto para fases posteriores de explotación.
Arquitectura del ataque y cadena de infección
Compromiso de la cuenta del mantenedor
El ataque comienza con la toma de control de la cuenta npm del mantenedor principal de Axios (jasonsaayman). El propio mantenedor, en el post‑mortem del repositorio oficial, indica que el atacante obtuvo acceso a su PC mediante una campaña de ingeniería social y malware RAT, que proporcionó las credenciales necesarias para publicar paquetes en npm.
Una vez con acceso a la cuenta, el actor:
Cambia el correo asociado a npm a direcciones ProtonMail controladas por el atacante (por ejemplo,
ifstap@proton.me).Publica las versiones maliciosas manualmente mediante
npm publishcon un token de acceso de larga duración, en lugar de seguir el workflow habitual de GitHub Actions con OIDC Trusted Publisher, dejando un patrón anómalo en los metadatos (_npmUser, ausencia detrustedPublisherygitHead).
Dependencia fantasma plain-crypto-js
En lugar de modificar el código de Axios, el atacante introduce una nueva dependencia en package.json llamada plain-crypto-js@4.2.1, un typosquat y clon del paquete legítimo crypto-js@4.2.0.
La comparación a nivel de archivos muestra que todos los ficheros de la librería criptográfica son idénticos bit a bit al paquete original, salvo por package.json, donde se añade un script postinstall que ejecuta node setup.js.
Este patrón define el concepto de “phantom dependency”: un paquete añadido no por su funcionalidad normal, sino exclusivamente por los efectos colaterales de su instalación (ejecución del hook postinstall).
Dropper setup.js y RAT multiplataforma
Al ejecutarse npm install en un entorno con scripts habilitados, npm resuelve la dependencia y descarga plain-crypto-js@4.2.1, tras lo cual se ejecuta automáticamente el hook postinstall, lanzando el script ofuscado setup.js.
Analistas de Unit 42, Elastic y otros describen un esquema de ofuscación en dos capas basado en reverso de cadenas, Base64 y un XOR con clave OrDeR_7077 para reconstruir dinámicamente el código del dropper y las URLs de C2.
El dropper contacta con el dominio sfrclak[.]com sobre HTTP (puerto 8000), empleando un user‑agent anacrónico que imita Internet Explorer 8 en Windows XP para camuflar el tráfico. A partir de ahí descarga un payload RAT específico para la plataforma:
macOS: binario asociado a WAVESHAPER.V2 / macWebT, con similitudes de código con backdoors atribuidos a BlueNoroff y campañas RustBucket.
Windows: RAT con persistencia mediante claves de registro
Runy uso de scripts temporales VBS/PowerShell (por ejemplo,6202033.vbs/.ps1) en%TEMP%.Linux: script o binario desplegado en
/tmp/ld.pyu otros paths temporales.
Persistencia, C2 y capacidades
Una vez desplegado, el RAT realiza:
Reconocimiento inicial: enumeración de directorios de usuario, raíces de unidades y procesos en ejecución.
Exfiltración de inventario a C2, manteniendo un beacon en bucle de aproximadamente 60 segundos para recibir comandos.
Capacidad de ejecutar comandos arbitrarios / scripts, inyección de binarios en memoria, enumeración de directorios y eliminación de sí mismo (
kill).
En Windows se observa persistencia vía claves de registro Run con nombres verosímiles (por ejemplo, MicrosoftUpdate) para re‑descargar el payload en cada inicio de sesión. El malware implementa técnicas antiforenses sustituyendo sus propios ficheros por versiones limpias tras la ejecución (incluida la reescritura del package.json malicioso con una versión legítima), reduciendo trazas para análisis posterior.
Vectores de ataque y fallos de seguridad habilitantes
Vectores de ataque
Los vectores clave explotados fueron:
Compromiso de credenciales del mantenedor mediante ingeniería social y malware previo.
Uso de tokens npm de larga duración sin atar a OIDC ni a flujos de publicación inmutables.
Dependencia de rangos semánticos (
^1.14.0,^0.30.0) en lugar de pinning estricto, lo que hizo que instalaciones inocuas se resolvieran automáticamente a las versiones maliciosas.Ejecución automática de scripts
postinstallen entornos CI/CD y estaciones de desarrollo sin--ignore-scriptsni sandboxes.Falta de verificación sistemática de lockfiles (
package-lock.json,yarn.lock) y árbol de dependencias real frente a la intención declarada enpackage.json.
Fallos y ausencias de control
Entre los fallos de seguridad y vacíos de control que permitieron el ataque destacan:
Gestión insuficiente de identidades de mantenedores: 2FA, rotación de tokens y seguridad de endpoint del propio mantenedor insuficientes.
Configuraciones de pipelines que seguían pasando
NPM_TOKENde larga vida aunque se usara OIDC Trusted Publisher, permitiendo a un actor con dicho token evitar la verificación de procedencia.Ausencia de políticas de seguridad de cadena de suministro (por ejemplo, pinning obligatorio, revisión de dependencias nuevas, uso de herramientas como SLSA/verificación de firma).
Falta de segmentación entre entornos de build y recursos sensibles (repositorios, secretos de producción), lo que convierte un runner comprometido en puerta de entrada a toda la organización.
Indicadores de compromiso (IoCs)
Paquetes y versiones
axios@1.14.1– versión maliciosa (sha256:2553649f2322049666871cea80a5d0d6adc700ca).axios@0.30.4– versión maliciosa (sha256:d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71).plain-crypto-js@4.2.1– dependencia maliciosa con hookpostinstall(SNYK-JS-PLAINCRYPTOJS-15850652).
Red e infraestructura
Dominio C2:
sfrclak[.]com(HTTP, puerto 8000).IP asociada:
142.11.206[.]73.URLs observadas:
http://sfrclak[.]com:8000/6202033y variantes con cuerpos POST que simulan tráfico apackages.npm.org.
Artefactos y ficheros en host
macOS:
/Library/Caches/com.apple.act.mond.Linux:
/tmp/ld.py.Windows:
%PROGRAMDATA%\wty ficheros temporales%TEMP%\6202033.vbs/.ps1.
Estrategias de detección y respuesta
Detección basada en endpoints y logs
Recomendaciones comunes incluyen:
Buscar en lockfiles referencias a
axios@1.14.1,axios@0.30.4oplain-crypto-js@4.2.1.Correlacionar artefactos locales (
plain-crypto-jsennode_modules, ficheros RAT en rutas indicadas) y procesos Node.js anómalos que ejecuten scripts adicionales o contacten C2.Revisar registros de red en busca de conexiones hacia
sfrclak[.]como142.11.206[.]73durante la ventana de exposición y posteriormente.
Diversos proveedores han publicado reglas Sigma/YARA y detecciones específicas para WAVESHAPER.V2, ZshBucket y el dropper SILKBELL, así como reglas orientadas a identificar instalaciones de las versiones maliciosas de Axios en logs de proceso.
Estrategias de respuesta
La guía consensuada es tratar cualquier host que haya instalado las versiones afectadas como comprometido, aplicando medidas de respuesta a incidente completas:
Aislar la máquina y preservar evidencia forense.
Revertir a estado conocido (reimaging donde sea viable) y reinstalar dependencias con versiones verificadas.
Rotar todos los secretos, tokens y credenciales presentes en el entorno afectado (incluidos tokens de CI/CD, llaves SSH y credenciales de nube).
Revisar actividad posterior a la instalación en repositorios, pipelines y entornos de producción para detectar posibles movimientos laterales.
Impacto técnico, operativo y organizativo
Impacto técnico
El impacto técnico directo incluye:
Compromiso de estaciones de desarrolladores y runners de CI/CD con capacidad de ejecución remota de comandos, robo de credenciales y persistencia.
Uso potencial de dicho acceso para modificar código fuente, insertar backdoors, manipular pipelines y comprometer artefactos de build.
Riesgo de exfiltración de secretos de alta sensibilidad (claves de producción, certificados, tokens de despliegue) y uso de estos para ataques ulteriores.
Impacto operativo y de negocio
Interrupción de pipelines de compilación y despliegue mientras se realiza la contención y limpieza.
Necesidad de auditoría extensa de código, dependencias y artefactos desplegados, causando retrasos en releases y en roadmap de producto.
Incremento de carga de trabajo en equipos de seguridad, SRE y desarrollo durante la respuesta e implementación de nuevas salvaguardas.
Impacto financiero, legal y reputacional
Posible pérdida financiera directa si se explotan credenciales para desviar fondos, robar criptoactivos o comprometer servicios de pago.
Costes significativos asociados a respuesta a incidentes, auditorías externas, refactorización de pipelines y programas de compensación a clientes.
Riesgo de sanciones regulatorias si el incidente deriva en brechas de datos personales (GDPR, LGPD, etc.) o incumplimiento de marcos como PCI DSS.
Daño reputacional tanto para las organizaciones afectadas como para el ecosistema npm, minando la confianza en la cadena de suministro de software.
Recomendaciones y controles de mitigación
Buenas prácticas técnicas específicas para este caso
Basándose en recomendaciones de múltiples proveedores:
Pinning estricto de versiones: evitar rangos semánticos cuando se trate de dependencias críticas, complementándolo con verificación de lockfiles y firmas.
Configurar
npm ci --ignore-scriptspor defecto en pipelines CI/CD, permitiendo scripts solo en entornos controlados y cuando sean estrictamente necesarios.Auditar y monitorizar los scripts de ciclo de vida (
postinstall,preinstall, etc.) de dependencias directas y transitivas, especialmente cuando aparecen paquetes nuevos en el árbol.Aplicar herramientas de seguridad de cadena de suministro (SCA, firmas de artefactos, verificación de procedencia tipo SLSA) para validar integridad y origen.
Endurecer la seguridad de cuentas de mantenedores y de acceso a registries: MFA fuerte, tokens de corta duración, revisión de sesiones, restricciones de IP.
Controles organizativos y de proceso
Definir una política de seguridad de cadena de suministro de software que cubra selección de dependencias, revisión de nuevos paquetes, pinning y procesos de actualización.
Establecer acuerdos claros con proveedores y terceros sobre prácticas de desarrollo seguro, incluyendo el uso de registries privados y firmas.
Formar a desarrolladores y DevOps en riesgos de dependencias externas, ingeniería social contra mantenedores y buenas prácticas de pipeline seguro.
Implantar ejercicios regulares de simulación de incidentes (table‑top, red team/purple team) centrados en ataques de cadena de suministro y compromisos de CI/CD.
Conclusiones analíticas
El ataque a la cadena de suministro de Axios demuestra que incluso proyectos ampliamente adoptados y con prácticas modernas de publicación (OIDC Trusted Publisher, CI/CD automatizado) siguen siendo vulnerables cuando existen vías de escape, como el uso de tokens de larga duración. La sofisticación operativa —pre‑provisionamiento de dependencias, dropper multiplataforma, antiforénsica y atribución a actores norcoreanos con historial de operaciones complejas— sitúa este incidente entre los ejemplos más relevantes de la amenaza actual contra cadenas de suministro de software.
Desde la perspectiva de defensa, más allá de contener este incidente concreto, la prioridad debe ser cerrar las brechas estructurales: endurecer la seguridad de cuentas de mantenedores y registries, reducir el poder de scripts de instalación, adoptar modelos de confianza verificable de extremo a extremo y aplicar una gestión rigurosa de dependencias conforme a marcos como NIST SSDF, NIST CSF, ISO 27001 y CIS Controls. Solo así podrá reducirse el riesgo de que el próximo “Axios” sea otro componente crítico en la base del software moderno.
Las principales empresas y firmas de ciberseguridad que publicaron análisis técnicos detallados del ataque de cadena de suministro a Axios (marzo de 2026) son:
Microsoft Security (mitigación y análisis inicial).
Unit 42 (Palo Alto Networks) (threat brief con impacto amplio).
Arctic Wolf (impacto en el paquete npm).
Endor Labs (compromiso de cuenta de mantenedor).
Huntress (análisis de compromiso de npm).
Trend Micro (compromiso del paquete y TTPs).
Google Threat Intelligence Group (GTIG) (atribución a UNC1069).
Elastic Security Labs (detecciones y RAT multiplataforma).
Vectra AI (desglose del incidente).
CrowdStrike (atribución a STARDUST CHOLLIMA).
Loginsoft (análisis técnico, IOCs y mitigación).
Tanium (qué pasó y lecciones).
Socket Security (detección inicial de dependencia maliciosa).
StepSecurity (análisis y detección temprana).
Malwarebytes (IOCs y confianza en npm).
Snyk (compromiso npm y RAT).
Critical Start (advisory de seguridad).
ThriveNextGen (compromiso UNC1069).
Security Arsenal (detección WAVESHAPER y remediación).
Estas firmas emitieron reports, IOCs, YARA/Sigma rules y advisories en las primeras 24-48 horas, con atribución y mapeo MITRE ATT&CK en días posteriores.
Fuentes consultadas
Mitigating the Axios npm supply chain compromise, https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/, Microsoft Security.
Threat Brief: Widespread Impact of the Axios Supply Chain Attack, https://unit42.paloaltonetworks.com/axios-supply-chain-attack/, Unit 42 / Palo Alto Networks.
Supply Chain Attack Impacts Widely Used Axios npm Package, https://arcticwolf.com/resources/blog/supply-chain-attack-impacts-widely-used-axios-npm-package/, Arctic Wolf.
Axios compromised: hijacked maintainer account pushes malicious versions, https://www.endorlabs.com/learn/npm-axios-compromise, Endor Labs.
Supply Chain Compromise of axios npm Package, https://www.huntress.com/blog/supply-chain-compromise-axios-npm-package, Huntress.
Axios NPM Package Compromised: Supply Chain Attack Hits Millions of Apps, https://www.trendmicro.com/en_us/research/26/c/axios-npm-package-compromised.html, Trend Micro.
Google Attributes Axios npm Supply Chain Attack to North Korean Hackers, https://thehackernews.com/2026/04/google-attributes-axios-npm-supply.html, The Hacker News.
Inside the Axios supply chain compromise - one RAT to rule them all, https://www.elastic.co/security-labs/axios-one-rat-to-rule-them-all, Elastic Security Labs.
Elastic releases detections for the Axios supply chain compromise, https://www.elastic.co/pt/security-labs/axios-supply-chain-compromise-detections, Elastic Security Labs.
Post Mortem: axios npm supply chain compromise, https://github.com/axios/axios/issues/10636, Axios / GitHub.
Targeted Supply Chain Compromise of Axios NPM Distribution (UNC1069), https://thrivenextgen.com/targeted-supply-chain-compromise-of-axios-npm-distribution-unc1069/, ThriveNextGen.
Axios npm Supply Chain Attack (UNC1069): detecting WAVESHAPER and remediation, https://securityarsenal.com/blog/axios-npm-supply-chain-attack-unc1069-detecting-waveshaperv2-and-remediation-for-versions-11410, Security Arsenal.
STARDUST CHOLLIMA Likely Compromises Axios npm Package, https://www.crowdstrike.com/en-us/blog/stardust-chollima-likely-compromises-axios-npm-package/, CrowdStrike.
Cross-Platform Threat - Axios Package Compromise, https://research.jfrog.com/post/axios-compromise/, JFrog Security Research.
Axios NPM Supply Chain Attack: Technical Analysis, IOCs, Detection, Mitigation, https://www.loginsoft.com/post/axios-npm-supply-chain-attack-technical-analysis-iocs-detection-mitigation, Loginsoft.
Axios npm package compromise: What happened, what matters, https://www.tanium.com/blog/axios-npm-package-compromise/, Tanium.
UNC1069 Deploys Cross-Platform RAT via Supply Chain Attack, https://cybersecsentinel.com/axios-npm-backdoored-unc1069-deploys-cross-platform-rat-via-supply-chain-attack/, CyberSec Sentinel.
Axios supply chain attack chops away at npm trust, https://www.malwarebytes.com/blog/news/2026/03/axios-supply-chain-attack-chops-away-at-npm-trust, Malwarebytes.
Axios npm Package Compromised: Supply Chain Attack Delivers Cross-Platform RAT, https://snyk.io/blog/axios-npm-package-compromised-supply-chain-attack-delivers-cross-platform/, Snyk.
axios Compromised on npm - Malicious Versions Drop Remote Access Trojan, https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan, StepSecurity.
Threat Brief: Widespread Impact of the Axios Supply Chain Attack, https://unit42.paloaltonetworks.com/axios-supply-chain-attack, Unit 42 / Palo Alto Networks.
Axios Got Hacked. If You Ran npm install Yesterday, Read This Now., https://dev.to/alanwest/axios-got-hacked-if-you-ran-npm-install-yesterday-read-this-now-4bdb, DEV Community.
Axios npm packages backdoored in supply chain attack, https://www.helpnetsecurity.com/2026/03/31/axios-npm-backdoored-supply-chain-attack/, Help Net Security.
Axios NPM Supply Chain Compromise Emergency Briefing, https://www.sans.org/blog/what-we-learned-axios-npm-supply-chain-compromise-emergency-briefing, SANS Institute.
North Korea-Nexus Threat Actor Compromises Widely Used Axios npm Package, https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package, Google Cloud / Google Threat Intelligence