El compromiso en la cadena de suministro del npm de axios en marzo salió a la luz como ocurre con muchos incidentes de seguridad: con una publicación en X a mitad de una noche de lunes.
“Necesito que alguien del equipo de seguridad de npmjs me escriba un DM YA”, publicó el líder técnico de Elastic, Joe Desimone.
need someone from npmjs security team to dm me NOW
— Joe Desimone (@dez_) March 31, 2026
La urgencia del mensaje estaba justificada. Como se supo después, un importante compromiso en la cadena de suministro había afectado al paquete npm de axios, una de las bibliotecas de JavaScript más utilizadas (con alrededor de 100 millones de descargas semanales).
Las dos versiones comprometidas ([email protected] y [email protected]) se eliminaron en un plazo de tres horas, pero esa ventana fue suficiente para afectar a muchas organizaciones que dependían del paquete (solo Huntress observó al menos 135 endpoints de todos los sistemas operativos comunicándose con la infraestructura de comando y control del atacante durante la ventana de exposición). Los atacantes pudieron entregar malware a sistemas macOS, Windows y Linux mediante la dependencia maliciosa que se había inyectado en las versiones de axios con backdoor.
En las horas siguientes, investigadores de seguridad –incluido John Hammond, de Huntress– desentrañaron el ataque generalizado de la mejor manera que sabían hacerlo: rastreando indicadores de compromiso (IoC) en distintos incidentes, creando detecciones y reconstruyendo las técnicas de los atacantes para entender cómo se había visto afectada cada organización víctima.
Dos semanas después, en el Tradecraft Tuesday de Huntress de abril, el 14 de abril, a Hammond (investigador principal sénior de seguridad) se sumaron otras tres personas que tuvieron un papel propio en descifrar este ataque masivo y los riesgos más amplios relacionados con las amenazas a la seguridad de la cadena de suministro en general: Ben Read, director de inteligencia estratégica de Wiz, Charlie Eriksen, investigador de seguridad de Aikido Security, y Logan MacLaren, ingeniero principal de seguridad ofensiva en Huntress.
Un resumen rápido del incidente
Entonces, ¿qué pasó? Por si no viste los titulares durante toda la semana del 30 de marzo, aquí va un resumen rápido.
Empecemos por lo básico: npm (abreviatura de Node Package Manager) es una biblioteca de componentes de software para el ecosistema de JavaScript. En el nivel más básico, npm es la herramienta que permite a los desarrolladores "tomar prestado" código ya escrito para sus aplicaciones.
Esto está muy bien para los desarrolladores que no quieren escribir sus aplicaciones desde cero, pero con el tiempo ha creado un ecosistema masivo de paquetes que dependen de aún más paquetes, a veces hasta cinco o seis capas de profundidad. Esto prepara el terreno para un "radio de explosión" muy peligroso si alguien logra subir un paquete malicioso, que luego se envía a estas otras dependencias posteriores.
Figura 1: Un blog de Huntress Rapid Response desglosó una línea de tiempo del ataque
Eso es exactamente lo que pasó cuando un actor de amenazas obtuvo acceso a la cuenta de npm jasonsaayman (el mantenedor principal de la biblioteca axios). A partir de ahí, los atacantes publicaron manualmente las dos versiones con puertas traseras. Para los innumerables paquetes, estaciones de trabajo de desarrolladores y pipelines de CI/CD que dependían de axios y ejecutaron npm install durante este período de tres horas, esto significó que el payload malicioso se ejecutó. Automáticamente.
Varios investigadores han señalado vínculos del ataque con infraestructura de Corea del Norte, y Google atribuye el incidente específicamente a UNC1069, un actor de amenazas norcoreano con motivación financiera, activo desde al menos 2018. El payload malicioso del ataque era un RAT con capacidades de payload multiplataforma, que permitía el reconocimiento de sistemas, el robo de credenciales y la ejecución remota de comandos. Esto en sí fue notable, ya que históricamente los ataques a la cadena de suministro de npm solían derivar en malware de minería de criptomoneda.
Temporada de caza para los malos
Los ataques a la cadena de suministro en el ecosistema de código abierto no son nada nuevo, pero hemos visto un punto de inflexión durante el último año con varios ataques masivos dirigidos específicamente a cuentas de npm. Además, los LLM están haciendo que los ataques sean más sin interrupciones, ya que permiten a los actores de amenazas combinar con más facilidad sus técnicas.
Algunos ejemplos se han destacado en particular:
- En septiembre de 2025, Josh Junon (un desarrollador conocido como "qix") fue blanco de un correo de phishing que afectó su cuenta de npm, lo que a su vez llevó al compromiso de 18 paquetes de npm muy populares. En ese caso, el fragmento de código distribuido en los paquetes apuntaba a transacciones de criptomoneda en varias blockchains.
- También en septiembre de 2025, un gusano autorreplicante llamado Shai-Hulud arrasó con el ecosistema de npm. Las capacidades de robo de credenciales del malware llamaron la atención, porque esto significaba que los atacantes podrían potencialmente usar las credenciales robadas para infectar más paquetes.
- En marzo de 2026, TeamPCP comprometió el popular escáner de vulnerabilidades de código abierto Trivy, de Aqua Security, lo que luego derivó en varios ataques posteriores (y más tarde se propagó al ecosistema de npm con un gusano que usó tokens de autenticación de publicación robados).
Shai-Hulud, en particular, usó técnicas que solo pueden describirse como de "maldad caótica". El malware primero buscaba tokens de autenticación de GitHub en los entornos de las víctimas, y luego usaba ese token de autenticación para subir a GitHub cualquier secreto que encontrara en la máquina, sin cifrar.
Como dijo Eriksen, de Aikido Security, si eres un actor de amenazas que usa esta táctica, "quieres ver el mundo arder".
El problema de la confianza
Al final del día, los desafíos de seguridad de código abierto se reducen a la confianza. Los atacantes dependen de la confianza al usar técnicas de ingeniería social para apuntar a los mantenedores antes de comprometer sus cuentas. Esta es la nueva normalidad, y quedó totalmente en evidencia durante el ataque a axios en npm:
- El mantenedor de axios, Jason Saayman, dijo en un informe posterior al incidente que los actores detrás del incidente lo contactaron haciéndose pasar por el fundador de una empresa
- Luego le enviaron una invitación a un espacio de trabajo falso de Slack, el cual estaba correctamente diseñado con la marca correspondiente, e incluía canales realistas, miembros del equipo y publicaciones.
- Luego invitaron a Saayman a una llamada programada de Microsoft Teams, que tenía "lo que parecía ser un grupo de personas involucradas".
- Durante la llamada, el actor de amenazas dijo que algo en el sistema de Saayman estaba desactualizado y lo instó a instalar un elemento para solucionar el problema, una táctica que los investigadores de Huntress han visto en otros ataques de ingeniería social. Sin que Saayman lo supiera, la instalación condujo al RAT.
Figura 2: el mantenedor de axios, Jason Saayman, habló sobre las tácticas de ingeniería social del atacante
Pero incluso más allá del acceso inicial, todo el ecosistema de código abierto está construido sobre una base de confianza. Los desarrolladores a menudo asumen que, como un paquete es popular o ampliamente usado, ha sido minuciosamente revisado. Muchos desarrolladores descargan paquetes según su nombre y utilidad sin verificar la identidad del mantenedor ni la integridad del código.
Para romper este ciclo, hay algunos pasos críticos que los mantenedores, desarrolladores y usuarios finales pueden tomar para ayudar a mitigar un futuro ataque a la cadena de suministro de código abierto:
- En lugar de descargar automáticamente la última versión de una dependencia, los desarrolladores deberían "fijar" sus dependencias a versiones específicas y verificadas, y usar un repositorio privado o un área de "cuarentena" para revisar las nuevas versiones antes de usarlas en producción.
- Los desarrolladores deberían establecer restricciones basadas en el tiempo ("antigüedad") para las nuevas versiones de paquetes, de modo que la industria pueda evaluarlas y responder primero.
- Asegúrate de que todas las dependencias (desde sistemas hasta cuentas) sean tan confiables como el objeto de alto privilegio al que acceden (esto también se conoce como el Principio de Fuente Limpia). Conoce lo que hay en tu software.
¿Te gustó lo que acabas de leer? Únete a nosotros cada mes para Tradecraft Tuesday, nuestro webinar en vivo donde exponemos técnicas de hackers y hablamos de temas técnicos con demostraciones en vivo. ¡Reserva tu lugar ahora!
