El 31 de marzo de 2026, el Grupo de Inteligencia de Amenazas de Google (GTIG) descubrió un sofisticado ataque a la cadena de suministro de software dirigido a Axios, la biblioteca de JavaScript más utilizada para peticiones HTTP, la cual registra más de 100 millones de descargas a la semana.
El ataque ha sido atribuido a UNC1069, un grupo de ciberdelincuentes con base en Corea del Norte y motivaciones financieras, activo desde al menos 2018.
A diferencia de otros ataques donde se explotan vulnerabilidades del código, los atacantes no tocaron el código fuente de la herramienta. En su lugar, lograron comprometer un token de acceso npm de larga duración perteneciente al mantenedor principal del proyecto.
Con este acceso, alteraron la cadena de confianza publicando las versiones envenenadas 1.14.1 y 0.30.4 de Axios.
¿Cómo funcionó el ataque?
Las versiones comprometidas incluían una dependencia oculta e inyectada maliciosamente llamada plain-crypto-js.
Este paquete parecía inofensivo, pero incluía un script de tipo postinstall (setup.js). Esto significa que al momento de ejecutar un simple npm install, el código se ejecutaba silenciosamente en segundo plano sin levantar sospechas.
El script determinaba el sistema operativo de la víctima (Windows, macOS o Linux) y procedía a descargar una puerta trasera (RAT) conocida como WAVESHAPER.V2.
Una vez instalada, la puerta trasera se conectaba al servidor de Comando y Control (C2) de los atacantes, permitiendo el robo masivo de credenciales, claves en la nube (AWS, GCP, Azure), tokens SSH y la ejecución de comandos arbitrarios. Finalmente, el malware borraba sus propios rastros en el archivo de dependencias para ocultar la evidencia forense.
Reacciones y corroboración por parte de expertos en ciberseguridad
El impacto del evento generó alertas inmediatas en toda la industria de la ciberseguridad. Diversas firmas y analistas utilizaron sus blogs y redes sociales para dimensionar el problema:
Google Threat Intelligence Group: John Hultquist, Analista Principal, destacó en comunicados públicos que «los hackers vinculados a Corea del Norte tienen una profunda experiencia en ataques a la cadena de suministro, los cuales han usado históricamente para robar criptomonedas». Advirtió además sobre el efecto dominó de este ataque debido a la popularidad masiva de Axios.
Socket y Aikido Security: Investigadores de ambas plataformas de seguridad publicaron advertencias detallando que la dependencia plain-crypto-js había sido orquestada de forma premeditada para evitar los escáneres de seguridad. Indicaron categóricamente que cualquier sistema que haya instalado Axios durante la ventana crítica de aproximadamente tres horas del 31 de marzo, debe considerarse totalmente comprometido.
Acciones inmediatas de corrección (Si fuiste afectado)
Si tu equipo o tus pipelines automatizados (CI/CD) descargaron módulos de npm la mañana del 31 de marzo de 2026, debes ejecutar este protocolo de contención recomendado por el Grupo de Inteligencia de Amenazas de Google:
- Control de versiones: No actualice a la versión 1.14.1 o 0.30.4 de axios. Asegúrese de que los repositorios NPM administrados por la empresa estén configurados para servir solo versiones que se sabe que funcionan correctamente (por ejemplo, 1.14.0 o anterior; 0.30.3 o anterior).
- Fijación de dependencias: Fije axios a una versión segura conocida en su sistema
package-lock.jsonpara evitar actualizaciones accidentales. - Auditoría de paquetes maliciosos: Inspeccione los archivos de bloqueo del proyecto específicamente para el paquete ‘plain-crypto-js’ (versiones 4.2.0 o 4.2.1). Utilice herramientas como Wiz u Open Source Insights para una auditoría de dependencias más exhaustiva.
- Seguridad de la canalización: Pausar las implementaciones de CI/CD para cualquier paquete que dependa de axios. Validar que las compilaciones no estén descargando versiones «más recientes» antes de volver a implementar con versiones fijas y seguras.
- Respuesta ante incidentes: Si
plain-crypto-jsse detecta una vulnerabilidad, asuma que el entorno del host está comprometido. Restaure el entorno a un estado seguro conocido y rote todas las credenciales o secretos presentes en esa máquina. - Defensa de red: Bloquear todo el tráfico a sfrclak[.]com y la IP de comando y control: 142.11.206.73. Monitorear y alertar sobre cualquier intento de comunicación de punto final a este dominio.
- Corrección de caché: Borre las cachés locales y compartidas de npm, yarn y pnpm en todas las estaciones de trabajo y servidores de compilación para evitar la reinfección durante las instalaciones posteriores.
- Protección de endpoints: Implemente EDR para proteger los entornos de desarrollo. Supervise los procesos sospechosos que se originan en aplicaciones Node.js y que coinciden con los indicadores de compromiso (IOC) conocidos.
- Gestión de credenciales: Rote todos los tokens y claves API utilizados por las aplicaciones que se ha confirmado que han ejecutado indicadores de compromiso (IOC).
- Aislamiento de desarrolladores y bóveda de secretos : aísle los entornos de desarrollo en contenedores o entornos aislados para restringir el acceso al sistema de archivos del host y migre los secretos en texto plano al llavero del sistema operativo mediante aws-vault . Esto garantiza que los paquetes comprometidos no puedan extraer credenciales mediante programación ni ejecutar scripts maliciosos directamente en la máquina host.
Perspectivas e implicaciones
El impacto de este ataque, ejecutado por grupos norcoreanos, es alarmante debido al efecto dominó que genera sobre los miles de paquetes que dependen de Axios.
Este no es un caso aislado: recientemente, otros grupos como UNC6780 (TeamPCP) han comprometido proyectos en GitHub Actions y PyPI (como Trivy y Checkmarx) para distribuir el malware SANDCLOCK, facilitando extorsiones y el robo masivo de credenciales.
La magnitud de estas ofensivas sugiere que cientos de miles de secretos corporativos podrían estar circulando en el mercado negro.
Esta filtración masiva de datos prepara el terreno para una oleada inminente de ataques a entornos SaaS, incidentes de ransomware, robos de criptomonedas y nuevas vulneraciones en cadenas de suministro de software a corto plazo.
Lo que hace que esta táctica sea especialmente peligrosa es que explota la confianza ciega que empresas y desarrolladores depositan en proveedores de renombre y comunidades de código abierto. Ante este escenario, es imperativo que los equipos de seguridad monitoreen sus proyectos activamente y que las organizaciones ejecuten auditorías profundas para mitigar daños actuales y blindar sus infraestructuras contra futuras amenazas.
¿Cómo protegerse a futuro contra amenazas en la cadena de suministro?
Aunque los sucesos de hackeos altamente peligrosos en el contexto del software libre suelen ser pocos, está prohibido confiar ciegamente en el ecosistema open-source (aunque sea bastante seguro).
Para mantener tus proyectos seguros contra amenazas en la cadena de suministro y otros tipos de amenazas, es fundamental mantener un control estricto sobre las configuraciones de tu entorno y la ejecución de código de terceros.
Esto se logra fijando versiones exactas en tu archivo package.json, eliminando los rangos dinámicos que podrían descargar automáticamente actualizaciones maliciosas.
Además, es vital deshabilitar la ejecución automática de scripts usando la bandera --ignore-scripts tanto en desarrollos locales como en flujos CI/CD, cerrando así la puerta a los ganchos de instalación (postinstall) que suelen ser el vector de ataque principal.
Gestión segura de credenciales y el monitoreo continuo
Por otro lado, la gestión segura de credenciales y el monitoreo continuo son líneas de defensa indispensables.
Para que todo vaya bien es necesario depurar y eliminar los viejos tokens de NPM de larga duración que hayan quedado olvidados en tus variables de entorno, ya que los atacantes los buscan activamente como «llaves de repuesto».
Esto debe complementarse con la implementación de herramientas de análisis de dependencias (SCA) capaces de supervisar tu proyecto en tiempo real, bloqueando de inmediato la introducción de sub-módulos desconocidos.
Finalmente, para contener cualquier posible brecha y limitar el radio de daño, debes aislar tus entornos de desarrollo locales. Ejecutar tus proyectos dentro de contenedores con acceso restringido al sistema anfitrión y utilizar bóvedas integradas en el sistema operativo evitará que cualquier paquete comprometido pueda raspar credenciales en texto plano o ejecutar scripts directamente sobre tu máquina.
Enlaces de referencia para profundizar:
- Software Improvement Group (SIG): Axios npm supply chain attack explained
- The Record: Google links axios supply chain attack to North Korean group
- Help Net Security: North Korean hackers linked to Axios npm supply chain compromise
Mira el artículo original: North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack
SEO estratega y redactor de contenidos especializado en temas de tecnología. Experto en crear estrategias de contenido que comunican complejidad técnica de forma clara y accesible.
