La reciente comprometación del paquete Axios en npm no fue un incidente aislado, sino parte de una campaña coordinada de ingeniería social dirigida a mantenedores de proyectos críticos de la ecosistema Node.js. El informe detallado del mantenedor de Axios, Jason Saayman, junto con el análisis de la empresa Socket, revela una operación cuidadosamente planificada que combina suplantación de identidad corporativa y despliegue de un remote access trojan (RAT) para atacar la cadena de suministro de software.
Cómo se produjo el compromiso de Axios: ingeniería social y RAT WAVESHAPER.V2
Los atacantes lograron tomar control de la cuenta del principal mantenedor de Axios y publicar dos versiones maliciosas del paquete en npm: 1.14.1 y 0.30.4. Al instalarse, estas versiones desplegaban en el equipo de los desarrolladores un RAT identificado como WAVESHAPER.V2, abriendo la puerta a la manipulación de proyectos y a la emisión de nuevas versiones comprometidas, con impacto potencial en toda la cadena de suministro.
El vector inicial fue un sofisticado escenario de suplantación de una empresa real. Los atacantes reprodujeron con gran fidelidad la marca y estética de una organización conocida, invitaron al mantenedor a un supuesto workspace corporativo de Slack y poblaron el entorno con canales, “noticias” de LinkedIn y perfiles falsos de empleados y mantenedores de otros proyectos open source, generando una falsa sensación de legitimidad y confianza.
El siguiente paso fue un videollamada concertada en Microsoft Teams. Durante la conexión apareció un mensaje de error aparentemente legítimo, indicando que parte del software estaba obsoleto y requería una actualización urgente. El ejecutable de “actualización” proporcionado durante la sesión era, en realidad, el remote access trojan que permitió a los atacantes acceder a las credenciales de npm y subir las versiones trojanizadas de Axios.
Vinculación con UNC1069 y la táctica de los falsos errores en videollamadas
Según el Google Threat Intelligence / TAG, este ataque encaja con la actividad de la agrupación UNC1069, un actor con motivación financiera y presuntos vínculos con Corea del Norte, activo al menos desde 2018. Una de sus tácticas distintivas es mostrar a la víctima un error falso durante una videollamada y ofrecer inmediatamente un “parche” o “actualización” para Zoom, Teams u otras plataformas, que en realidad instala un RAT.
Investigaciones previas de empresas como Huntress y Kaspersky describen patrones casi idénticos: el usuario experimenta un supuesto fallo de conexión a la reunión, se le insta a descargar un nuevo cliente o actualización y, al ejecutarlo, el atacante obtiene control remoto completo sobre la estación de trabajo del desarrollador.
Una campaña más amplia contra mantenedores de npm y proyectos Node.js
El caso de Axios es solo la parte visible de una campaña dirigida a múltiples mantenedores de npm y Node.js. Socket ha documentado intentos de ataque muy similares contra varios desarrolladores influyentes: el mantenedor de polyfills de ECMAScript Jordan Harband, el creador de Lodash John-David Dalton, el mantenedor de Fastify y Undici Matteo Collina, el autor de dotenv Scott Motte y el mantenedor de Mocha Pelle Wessman, entre otros, incluidos ingenieros de la propia Socket.
En el caso de Pelle Wessman, los atacantes le invitaron a participar en la grabación de un podcast a través de una falsa plataforma de Streamyard. Ante su negativa a ejecutar la aplicación proporcionada, intentaron convencerle de lanzar directamente un comando curl desde su terminal para “solucionar” el problema. Tras un nuevo rechazo, los atacantes eliminaron de forma inmediata el historial de chats, lo que apunta a un guion de ataque bien ensayado y orientado a no dejar rastros.
De forma similar, el contribuidor de Node.js core y Express Jean Burellier reportó un acercamiento desde una supuesta empresa Openfort, con invitaciones a varios workspaces de Slack y a una videollamada en Teams, durante la cual se le instó a instalar una actualización del “Teams SDK”. El objetivo, de nuevo, era ejecutar código malicioso en su estación de trabajo.
Por qué 2FA y OIDC no bastan cuando la estación de trabajo está comprometida
El CEO de Socket, Feross Aboukhadijeh, subraya un punto crítico para la seguridad de la cadena de suministro de software: una vez que el atacante ha desplegado un RAT en el equipo del desarrollador, la autenticación de dos factores (2FA) y la publicación basada en OIDC dejan de ser una barrera suficiente. El malware puede acceder a archivos sensibles como .npmrc, sesiones activas de navegador, llaveros locales y tokens de autenticación, reutilizándolos para publicar paquetes maliciosos aun cuando existan políticas de seguridad avanzadas.
Tras el incidente, Jason Saayman llevó a cabo una revisión integral de su postura de seguridad: restableció todos sus dispositivos, rotó credenciales, adoptó releases inmutables en npm, migró a publicación con OIDC y endureció la configuración de GitHub Actions siguiendo prácticas actualizadas de DevSecOps. Estas medidas ilustran el nivel de respuesta necesario cuando la estación de trabajo del desarrollador ha sido comprometida.
Recomendaciones clave para proteger a desarrolladores y la cadena de suministro
La campaña contra mantenedores de npm demuestra que los desarrolladores y los proyectos open source críticos se han convertido en objetivos prioritarios. Incluso los controles estrictos en repositorios y registros de paquetes resultan insuficientes si el endpoint del desarrollador es vulnerado. Para reducir el riesgo, conviene adoptar las siguientes prácticas:
1. Higiene estricta en comunicaciones y descargas
Evitar ejecutar binarios o scripts recibidos por LinkedIn, Slack, correo o videollamadas. Las ofertas inesperadas de “actualizar Zoom/Teams/SDK” deben considerarse un indicador claro de posible ingeniería social. Cualquier software debe descargarse solo desde sitios oficiales y verificados.
2. Separación de entornos críticos
Utilizar, siempre que sea posible, estaciones de trabajo dedicadas o entornos virtuales aislados para la publicación en npm y la gestión de repositorios críticos. La segmentación limita el alcance de un compromiso y dificulta que un RAT afecte a todo el entorno de desarrollo.
3. Monitorización, trazabilidad y respuesta temprana
Habilitar logging detallado en CI/CD, controlar cambios en los lanzamientos, emplear herramientas de análisis de dependencias y monitorizar versiones publicadas en npm ayuda a detectar con rapidez anomalías, versiones inesperadas o cambios de comportamiento en paquetes populares, reduciendo la ventana de exposición.
4. Formación continua en ingeniería social para desarrolladores
Realizar formaciones periódicas sobre tácticas de ingeniería social, analizar casos reales como el ataque a Axios y establecer procedimientos claros para verificar identidades corporativas y solicitudes técnicas sensibles. Un equipo entrenado es una de las defensas más eficaces frente a campañas dirigidas.
La fiabilidad de la moderna ecosistema de software depende cada vez más de la seguridad de quienes lo construyen. Cuanto más crítico es un paquete o framework, mayor es su atractivo para atacantes que buscan explotar la cadena de suministro. Es el momento de revisar procesos, endurecer la seguridad en estaciones de trabajo y reforzar la cultura de ciberseguridad en los equipos de desarrollo, antes de que la próxima “videollamada falsa” se convierta en el punto de entrada de un incidente de gran escala.
