Actualizado: 3 de abril de 2026: se han añadido detalles sobre cómo se vio comprometida inicialmente la cuenta.
--
Cuando se produce una vulnerabilidad en un paquete de uso generalizado, la mayoría de los equipos siguen un procedimiento habitual: revisan el historial de cambios, identifican la versión maliciosa y comprueban si se ha incorporado a su entorno. Esa respuesta es necesaria, pero solo resuelve una parte del problema.
Axios es un un cliente HTTP muy utilizado en el ecosistema de npm. Se encuentra profundamente integrada en las pilas de aplicaciones modernas, presente en las herramientas de desarrollo, los servicios de backend, los marcos de frontend y los procesos de integración continua. Las instalaciones no se realizan en un único lugar, sino que se llevan a cabo de forma continua en estaciones de trabajo, sistemas de compilación y entornos de producción. En muchos casos, las nuevas dependencias se resuelven automáticamente durante los procesos de implementación o escalado, lo que significa que una versión comprometida puede extenderse mucho más allá de los equipos de los desarrolladores.
Durante el periodo de vulnerabilidad, cualquier entorno que ejecutara las versiones afectadas ejecutaba código controlado por el atacante. Ese es el aspecto que debe determinar la respuesta. El problema no es el número de versión ni las diferencias en las dependencias, sino el hecho de que se ejecutara código no fiable dentro de sistemas que ya contaban con acceso privilegiado.
¿Qué pasó realmente?
Se vulneró una cuenta de administrador de axios, lo que permitió que se publicaran versiones maliciosas y se les asignaran etiquetas para que las instalaciones estándar las seleccionaran.
Los detalles posteriores facilitados por el administrador apuntan a una operación de ingeniería social dirigida, más que a una simple filtración de credenciales. El atacante se hizo pasar por una empresa legítima, creó un espacio de trabajo de Slack muy convincente con una imagen de marca clonada y perfiles de ingenieros conocidos, y organizó una reunión en directo a través de Microsoft Teams. Durante esa interacción, se le pidió al administrador que instalara lo que parecía ser una actualización rutinaria, pero que en realidad instalaba el malware para obtener acceso a su entorno.
A partir de ahí, el atacante aprovechó ese acceso para publicar versiones de Axios con puertas traseras directamente en npm, eludiendo el proceso habitual de lanzamiento del proyecto.
El cambio en sí fue mínimo. Una sola dependencia, plain-crypto-js, pero nunca se hizo referencia a ella en ninguna parte del código, ya que no era necesario. Su finalidad era la ejecución, no la funcionalidad.
Esa dependencia provocó un posinstalación gancho, que se ejecutaba automáticamente durante el proceso normal npm install proceso. No hubo ningún mensaje, ninguna advertencia ni ningún indicio de que algo hubiera salido mal. En lugar de contener la carga útil final, el script hizo las veces de gotero.
Tan pronto como se ejecutó, se conectó a una infraestructura controlada por los atacantes y envió una solicitud diseñada para parecerse al tráfico normal relacionado con npm. El cuerpo de la solicitud imitaba la comunicación legítima del registro, pero el destino era externo. La respuesta proporcionaba una carga útil específica para cada plataforma, adaptada a macOS, Windows o Linux, que luego se guardaba en el disco y se ejecutaba en segundo plano.
En ese momento, el objetivo ya se había alcanzado. En el sistema se estaba ejecutando una herramienta de acceso remoto, independiente del proceso de instalación.
A continuación, el dropper borró sus propios rastros. Se eliminó el script de instalación y se reescribieron los metadatos del paquete para que parecieran limpios. Cualquiera que revisara las dependencias posteriormente no encontraría nada que pareciera claramente malicioso. La instalación parecería legítima, aunque la carga útil ya se hubiera ejecutado.
Lo que hace que este incidente sea aún más relevante es que no se basó en una configuración claramente vulnerable. El administrador había implementado la autenticación multifactorial y había comenzado a adoptar la publicación de confianza mediante OIDC. Sin embargo, las vías de publicación heredadas seguían dependiendo de tokens de npm de larga duración, que, por su propio diseño, eluden la autenticación multifactorial.
Esa coexistencia creó la brecha. El control más estricto existía, pero no se aplicaba de principio a fin. El atacante no tuvo que interrumpir el flujo de trabajo de publicación previsto. Solo tuvo que utilizar la ruta que seguía estando disponible.
Las primeras conversaciones entre el responsable del mantenimiento y la comunidad coincidieron rápidamente en una misma conclusión: aunque se habían implantado controles estrictos, las vías de autenticación heredadas seguían suponiendo un riesgo.
del usuario Riteshkew en GitHub
Este es el patrón que se repite en los incidentes de la cadena de suministro. La intrusión se produce a través de la identidad, la carga maliciosa se distribuye a través de canales de confianza y la ejecución se disimula entre el comportamiento normal. Para cuando se detecta el cambio, el código ya se ha ejecutado.
Fuente: StepSecurity
Las solicitudes salientes que se muestran aquí se dirigen a una infraestructura controlada por el atacante, no al registro de npm. El cuerpo de la solicitud imita el tráfico relacionado con npm, lo que ayuda a que la actividad se camufle entre los flujos de trabajo de desarrollo normales mientras se recupera la carga útil de la segunda fase.
Por qué esto se integra perfectamente en los flujos de trabajo habituales
Los paquetes maliciosos no son nada nuevo, pero este caso destaca por encajar a la perfección en los flujos de trabajo habituales de desarrollo y , sobre todo, por combinar el acceso selectivo con una amplia distribución.
Como se ha comentado anteriormente, el exploit en sí mismo rara vez determina el resultado. Lo que importa es lo que ocurre tras la ejecución del código dentro del entorno.
Hay varios factores que hacen que este incidente tenga mayores repercusiones que las típicas vulneraciones de la cadena de suministro.
Axios está ampliamente integrado, lo que amplía el alcance potencial del impacto mucho más allá de una sola aplicación o equipo. La exposición no se limitó a las organizaciones que dependían explícitamente de él. Cualquier paquete, flujo de trabajo de compilación o tarea de integración continua que lo resolviera de forma transitiva durante ese periodo podría haber descargado la versión maliciosa, lo que dificulta determinar rápidamente el alcance total del impacto.
La ejecución fue inmediata. La carga útil se ejecutó a los pocos segundos de su instalación, a menudo a través de procesos automatizados. Huntress detectó el primer caso conocido de infección de un terminal tan solo 89 segundos después de que se publicara la versión maliciosa, lo que refleja la rapidez con la que los entornos de desarrollo modernos resuelven y ejecutan nuevas dependencias.
Al mismo tiempo, el atacante tomó medidas para reducir al mínimo su visibilidad. El instalador se eliminó a sí mismo, se reescribieron los metadatos del paquete y las comprobaciones posteriores al incidente no revelaban ningún problema. La modificación en sí fue precisa: se añadió una dependencia, no hubo cambios funcionales y no se detectó ninguna señal evidente a menos que se examinara detenidamente el archivo correspondiente.
Otro aspecto que distingue este caso es cómo se inició. La brecha de seguridad no se originó en el propio ecosistema de paquetes, sino en una campaña de ingeniería social dirigida contra el responsable del mantenimiento. Al actuar basándose en la confianza en lugar de aprovechar una vulnerabilidad técnica, el atacante eludió controles como la autenticación multifactorial (MFA) y obtuvo acceso directo al proceso de lanzamiento.
Esa combinación de suplantación de identidad selectiva y distribución a través de la cadena de suministro de software es lo que hace que este tipo de ataque sea difícil de prever y aún más difícil de contener.
Desde la instalación de paquetes hasta la filtración de credenciales
La instalación es solo el punto de partida. Una vez que se ejecuta el dropper, hereda los permisos y el acceso del sistema en el que se ejecuta.
En la práctica, esto suele incluir tokens de GitHub, tokens de npm, cloud , secretos de CI/CD, claves de API y datos de SSH. No es necesario aprovechar ninguna de estas credenciales , ya que están disponibles en entornos de confianza, como las estaciones de trabajo de los desarrolladores y los procesos de compilación.
En esa fase, el atacante ya no depende del propio paquete. La atención se centra en a qué pueden acceder esos sistemas y cómo se puede aprovechar ese acceso.
Ya hemos visto cómo se desarrolla este patrón. En el caso de Shai-Hulud, el ataque pasó rápidamente de la ejecución a la recopilación y reutilización de credenciales, propagándose a través de repositorios y canales de datos aprovechando las relaciones de confianza existentes.
El paquete actúa como mecanismo de entrega. El riesgo radica en lo que esa entrega permite.
Este patrón no se limita a los paquetes de npm. En el reciente incidente de la cadena de suministro de Trivy, los atacantes utilizaron herramientas de CI/CD comprometidas para ejecutar código directamente dentro de los procesos de compilación, obteniendo a gran escala cloud , secretos de Kubernetes y tokens de API. Un punto de entrada diferente, pero el mismo resultado: ejecución dentro de un entorno de confianza, seguida de un acceso inmediato a todo lo que ese entorno puede alcanzar.
La falta de visibilidad tras la instalación
Es aquí donde la mayoría de las organizaciones pierden la claridad.
Es relativamente sencillo comprobar si una versión maliciosa aparece en un archivo de bloqueo, pero eso no indica dónde se ejecutó realmente el código. Los registros de compilación rara vez recogen el comportamiento de los procesos en segundo plano independientes, y los equipos de los desarrolladores suelen funcionar sin el mismo nivel de supervisión que se aplica a los sistemas de producción.
Para cuando se identifica y se elimina la dependencia maliciosa, la ejecución inicial ya se ha producido, lo que deja a los equipos con pocas pruebas y una serie de preguntas sin respuesta.
¿La carga útil accedió a las credenciales?
¿Se reutilizaron esas credenciales?
¿Se extendió la actividad a entornos cloud SaaS?
En muchos casos, no hay una forma definitiva de responder a estas preguntas utilizando únicamente las herramientas tradicionales.
Una forma práctica de validar la exposición
Para los equipos que intentan pasar de pensar «quizá nos veamos afectados» a tomar medidas concretas, uno de los indicadores más rápidos que deben analizar es la comunicación externa.
Hemos publicado una búsqueda específica de 5 minutos en la Vectra AI para identificar los sistemas que podrían haber ejecutado la carga maliciosa de Axios, buscando indicios de comunicación con la infraestructura del atacante.
Esta investigación se centra en un pequeño conjunto de indicadores de alta fiabilidad relacionados con la campaña, incluido el dominio de mando y control sfrclak.com y la dirección IP correspondiente 142.11.206.73. Cualquier sistema que se comunique con esa infraestructura durante o después del periodo de exposición debe considerarse sospechoso.
La consulta muestra las sesiones de red relacionadas con ese dominio o dirección IP, junto con los hosts de origen y destino, el protocolo y la frecuencia de conexión. En la práctica, los analistas deben prestar atención a los sistemas que muestran conexiones repetidas o automatizadas, o a los hosts que no tienen antecedentes de comunicación con infraestructuras externas similares.
A partir de ahí, la investigación puede avanzar rápidamente. Pásate a la telemetría de DNS, HTTP y SSL para comprender el alcance de la comunicación y, a continuación, correlaciona los datos con los de los terminales para identificar el proceso responsable. Si se confirma la actividad, bloquea la infraestructura y aísla el sistema afectado para su corrección.
Este tipo de búsqueda específica no sustituye a una investigación más amplia, pero ofrece a los equipos una forma rápida de identificar los sistemas que podrían estar comprometidos y priorizar la respuesta. En un incidente en el que la ejecución se produce de forma silenciosa y las pruebas son escasas, esa señal inicial puede reducir considerablemente el tiempo que se tarda en comprender qué es lo que realmente se ha ejecutado en su entorno.
Los ataques a la cadena de suministro se centran ahora en la identidad
Una vez obtenido el acceso, el ataque ya no depende de malware . Las credenciales válidas ofrecen una vía más fiable y menos detectable para continuar.
Los atacantes pueden autenticarse, llamar a las API e interactuar con los sistemas utilizando las mismas interfaces y flujos de trabajo que los desarrolladores y los sistemas de automatización utilizan a diario. Esto les permite pasar desapercibidos entre la actividad normal, al tiempo que amplían su alcance a todos los entornos.
El ejemplo de Shai-Hulud ilustró cómo funciona esto, utilizando tokens robados para crear repositorios, modificar canalizaciones y expandirse a través de relaciones de confianza existentes sin introducir anomalías evidentes a nivel de eventos individuales.
El incidente de Axios ofrece la misma oportunidad. Una cuenta de servicio que accede a recursos que nunca antes había utilizado, un token que aparece en un nuevo contexto o un proceso que se comporta de forma diferente a lo esperado son, por separado, sucesos que pueden explicarse. Sin embargo, cuando se analizan en conjunto, forman un patrón que apunta a un uso indebido de los accesos, más que a un funcionamiento normal.
Detectar lo que ocurre tras el ataque
Una vez que se ha ejecutado el código, el reto pasa de la prevención a comprender cómo se está utilizando el acceso.
Una de las primeras señales en esta cadena de ataque es la comunicación saliente hacia la infraestructura de comando y control. Incluso cuando el dropper elimina sus propios artefactos, esa actividad de red persiste. Las conexiones externas inusuales desde máquinas de desarrolladores, ejecutores de CI o entornos de aplicaciones pueden ser un claro indicio de que algo va mal, especialmente cuando el destino no se ajusta al comportamiento esperado en cuanto a dependencias o compilaciones.
La Vectra AI se centra en identificar estos patrones en los sistemas de identidad, los entornos cloud SaaS, y la actividad de red. Detecta comportamientos de autenticación que no se ajustan al uso habitual, destaca patrones de acceso que se desvían del comportamiento esperado de la carga de trabajo y detecta actividades que sugieren preparación, persistencia o movimiento lateral.
Por separado, es posible que estas señales no llamen la atención. Sin embargo, al analizarlas en conjunto, revelan si un incidente se detuvo en la fase de ejecución o si derivó en un compromiso más amplio.
Para ofrecer un desglose más detallado de cómo se manifiestan estos patrones posteriores a la explotación en distintos entornos, este análisis repasa la investigación desde el punto de vista de la detección.
En qué puedes seguir confiando
El incidente de Axios no termina con la eliminación de un paquete malicioso. Marca el punto en el que la certeza da paso a la evaluación de riesgos.
La mayoría de los equipos pueden determinar si las versiones afectadas estaban presentes. Sin embargo, son menos los que pueden determinar dónde se ejecutaron o a qué entornos dieron acceso en ese momento. Esa distinción es importante, ya que determina si el incidente fue de alcance limitado o si generó un acceso duradero.
Si existe la más mínima posibilidad de que se hayan ejecutado las versiones comprometidas, lo más prudente es considerar que ya no se puede confiar en el entorno tal y como estaba antes. Los equipos de los desarrolladores, los servidores de integración continua y los sistemas de compilación suelen tener más permisos de los previstos, y esos permisos rara vez se registran en su totalidad.
La respuesta inicial sigue siendo sencilla: volver a una versión limpia, eliminar la dependencia y recompilar los sistemas afectados, en lugar de intentar una limpieza parcial. Lo más complicado es decidir en qué se puede seguir confiando después.
Las credenciales asociadas a esos entornos deben considerarse expuestas, no porque haya pruebas de un uso indebido, sino porque no existe una forma fiable de demostrar lo contrario. La rotación resulta necesaria para restablecer la confianza.
Este incidente también pone de manifiesto problemas estructurales en la gestión de las dependencias. Los procesos de CI/CD que incorporan automáticamente las últimas versiones disponibles crean una vía directa para que los paquetes maliciosos recién publicados se ejecuten de inmediato. Introducir un plazo de espera entre la publicación y la adopción, junto con una fijación de versiones más estricta, reduce la exposición al dar tiempo a que los problemas salgan a la luz antes de la implementación.
Al mismo tiempo, la causa principal sigue siendo el robo de identidad. Las cuentas de mantenimiento y de implementación deben tratarse como activos de gran valor, con una separación clara entre el acceso diario para el desarrollo y los privilegios de publicación. Reducir la dependencia de los tokens de larga duración y aplicar controles más estrictos en los flujos de trabajo de publicación limita el impacto de este tipo de ataques.
La conclusión general es la misma en todos los incidentes relacionados con la cadena de suministro. El punto de entrada puede ser una dependencia comprometida, pero el impacto viene determinado por el uso que se haga del acceso posteriormente. La intrusión en Axios fue breve, pero las condiciones que generó pueden persistir mucho más allá del periodo de instalación.