La campaña que hackeó Axios expone la fragilidad de las cadenas de suministro de software

Esta semana la comunidad de desarrollo de Node.js tuvo que encajar un recordatorio incómodo: las cadenas de suministro del software son tan frágiles como las personas que las mantienen. Los responsables del popular cliente HTTP Axios publicaron un informe detallado sobre un incidente en el que atacantes lograron comprometer una cuenta de mantenimiento y publicar dos versiones maliciosas del paquete en el registro npm. Esas versiones, etiquetadas como 1.14.1 y 0.30.4, introdujeron una dependencia llamada plain-crypto-js que desplegaba un troyano de acceso remoto capaz de ejecutarse en macOS, Windows y Linux.

La ventana de exposición fue corta —las versiones maliciosas estuvieron en el registro alrededor de tres horas antes de ser retiradas—, pero ese breve lapso fue suficiente para que proyectos y entornos que las descargaron quedaran en riesgo. Los mantenedores de Axios han advertido que cualquier sistema que instaló esas versiones durante ese periodo debe considerarse comprometido y han recomendado rotar credenciales y claves de autenticación. Además, el equipo afectado borró máquinas comprometidas y restableció accesos mientras implementa medidas para reducir la probabilidad de que algo similar vuelva a ocurrir. Puedes leer el post-mortem oficial en el repositorio de Axios en GitHub: https://github.com/axios/axios/issues/10636.

Lo que hace especialmente inquietante este incidente no es sólo el malware en sí, sino la forma en que los atacantes obtuvieron acceso: una campaña de ingeniería social muy trabajada dirigida a mantenedores. Según la crónica de los afectados, el ataque comenzó con la suplantación de una empresa legítima, replicando su imagen corporativa y creando perfiles falsos que simulaban empleados y colaboradores del ecosistema de código abierto. A partir de ahí, invitaron a los desarrolladores a un espacio de Slack «de confianza» y organizaron videollamadas que parecían auténticas.

Durante una de esas reuniones simuladas los atacantes mostraron un supuesto error técnico que motivaba a instalar una actualización de Microsoft Teams. Esa «actualización» no era otra cosa que un instalador que desplegó un RAT en el equipo del mantenedor, permitiendo a los atacantes acceder a sesiones autenticadas y extraer credenciales de npm. Es decir, la protección basada en MFA quedó socavada porque el acceso se materializó desde sesiones ya autenticadas. La explicación y análisis de Google Threat Intelligence Group, que atribuye la operación al actor rastreado como UNC1069, incluye más detalles sobre la infraestructura usada y sus paralelismos con campañas previas: https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package.

Grupos de seguridad que han seguido la pista a esta actividad señalan que no se trata de un ataque aislado, sino de una campaña coordinada y dirigida a proyectos con mucha dependencia en el ecosistema Node.js. La firma Socket, que publicó un análisis del patrón de ataque, ha documentado cómo los atacantes contactaron a múltiples mantenedores a través de LinkedIn, Slack u otras plataformas y replicaron el mismo modo operandi: invitaciones a espacios privados, reuniones con actores aparentemente reales y la presión para instalar software «nativo» o ejecutar comandos de consola que terminaban descargando malware. Socket resume sus hallazgos y la preocupación por el impacto en paquetes de alto uso en este artículo: https://socket.dev/blog/attackers-hunting-high-impact-nodejs-maintainers.

No todos los objetivos cedieron. Varios mantenedores compartieron cómo rechazaron las peticiones de instalar binarios o ejecutar comandos, y uno de ellos, Pelle Wessman, mostró una captura del mensaje fraudulento que les presentaron —un supuesto error de conexión RTC— y explicó que cuando se negó a ejecutar el instalador los atacantes incluso intentaron convencerlo de ejecutar un comando curl para descargar código. Su testimonio está disponible en LinkedIn y en los hilos del post-mortem: publicación de Pelle Wessman.

Una dimensión técnica relevante aquí es que los atacantes no modificaron directamente el código fuente del proyecto Axios. En lugar de ello inyectaron una dependencia maliciosa en paquetes legítimos, una táctica que permite a los actores maliciosos empaquetar código dañino dentro de una actualización aparentemente confiable. Esa estrategia subraya por qué las cadenas de suministro de software, y en particular los repositorios de paquetes, son objetivos tan atractivos: comprometer una librería popular puede amplificar un ataque a miles o millones de usuarios.

¿Qué puede hacer un desarrollador o un equipo si sospecha que ha instalado una de las versiones afectadas? Lo más inmediato y prudente es actuar como si el sistema estuviera comprometido: asumir que tokens, credenciales de npm y sesiones fueron expuestas, y proceder a rotarlas y revocarlas. También conviene auditar los archivos de bloqueo (package-lock.json, yarn.lock) para detectar dependencias inesperadas, examinar historiales de instalación, y revisar logs de CI/CD por actividad inusual. Para la gestión específica de cuentas npm, activar o reforzar la autenticación de dos factores y revisar tokens de automatización es recomendable; npm documenta buenas prácticas y la configuración de 2FA en su sitio: https://docs.npmjs.com/configuring-two-factor-authentication.

Más allá de las operaciones de emergencia, este episodio abre preguntas más amplias sobre cómo proteger el ecosistema de código abierto. Los mantenedores suelen trabajar con recursos limitados y reciben solicitudes de colaboración legítimas con asiduidad; sin embargo, la sofisticación de estas campañas exige protocolos más estrictos: verificación de identidad de nuevos colaboradores, canales de comunicación claramente definidos, prácticas de hardening de máquinas de mantenimiento (máquinas dedicadas y segregadas), y procesos de publicación que minimicen el uso de tokens personales en favor de credenciales de corto tiempo o flujos de CI con permisos mínimos.

Finalmente, conviene recordar que actores con motivaciones financieras o estatales han utilizado tácticas similares antes, desplegando una variedad de herramientas como backdoors, descargadores e infostealers destinados a recolectar credenciales, cookies y otros secretos. La atribución de Google a UNC1069 menciona el uso de una variante bautizada WAVESHAPER.V2, lo que conecta este incidente con patrones observados en campañas anteriores contra víctimas del sector cripto y otras infraestructuras: análisis de GTIG.

La lección es clara y dura: la seguridad del software no es solo un problema técnico, es también una cuestión humana. Proteger proyectos de alto impacto exige no solo controles automáticos, sino formación, protocolos y recursos para que quienes mantienen las piezas críticas no sean el eslabón más débil. Mientras tanto, si administras proyectos que dependen de Axios o trabajas con paquetes de npm, revisa tus instalaciones, asume precaución si se descargaron las versiones mencionadas y rota claves y tokens.

Para ampliar la lectura sobre el incidente y su investigación, además del post-mortem de Axios y el informe de Google, puedes consultar la cobertura técnica en medios especializados, por ejemplo en BleepingComputer, que resume el ataque y su alcance: https://www.bleepingcomputer.com/news/security/hackers-compromise-axios-npm-package-to-drop-cross-platform-malware/.