El ataque a Axios y las falsas apps de Claude revelan el nuevo problema de confianza del software

Las versiones afectadas estuvieron disponibles aproximadamente tres horas. Google Threat Intelligence Group registró actividad entre las 00:21 y las 03:20 UTC del 31 de marzo, mientras que otros informes describen una ventana similar de entre dos y tres horas. Axios es una dependencia de gran impacto: distintas fuentes calculan entre 80 y más de 100 millones de descargas semanales en npm, aunque las estimaciones no coinciden.

Cómo se abusó de la cuenta del mantenedor

La información pública más sólida apunta a una toma de control de la cuenta de npm, no a una vulnerabilidad propia de Axios. Un informe señala que los atacantes utilizaron un token de acceso de npm de larga duración perteneciente al mantenedor principal; otras fuentes describen el hecho de forma más general como el compromiso de la cuenta o de las credenciales de publicación.

La diferencia es importante. El ataque atravesó la frontera de confianza entre la autoridad de publicación del mantenedor y el proceso de lanzamiento de npm. Como las versiones fueron publicadas desde una cuenta legítima, los desarrolladores y los sistemas automatizados tenían menos motivos para considerarlas sospechosas.

Qué hacía la dependencia maliciosa

plain-crypto-js@4.2.1 se presentó como una dependencia normal, pero existía para ejecutar un script postinstall. Este script contactaba con un servidor de mando y control y descargaba una segunda carga útil adaptada al sistema operativo del equipo.

Por tanto, el incidente no exigía que los desarrolladores descargaran un ejecutable evidentemente sospechoso. El detonante podía ser una actualización normal de dependencias, una compilación de CI o un

npm install

¿Fue BlueNoroff el responsable?

La atribución no está resuelta en el material disponible. Algunos informes relacionan la operación con actores vinculados a Corea del Norte, incluido BlueNoroff o grupos afines, mientras que Microsoft atribuyó el compromiso a Sapphire Sleet.

Estas evaluaciones no deben presentarse como una única conclusión confirmada. Las similitudes de código, infraestructura y procedimientos pueden orientar una atribución, pero por sí solas no demuestran qué grupo llevó a cabo el ataque. La conclusión más prudente es que el compromiso de Axios involucró una cuenta de mantenedor secuestrada, versiones manipuladas y un RAT multiplataforma; la identidad del actor sigue siendo objeto de debate en las evaluaciones públicas.

Cómo SilverFox utilizó aplicaciones falsas de Claude

SilverFox siguió una ruta distinta para entrar en las organizaciones: distribuyó aplicaciones falsificadas de Claude para Windows, macOS y Linux. La campaña se dirigió a organizaciones de los sectores industrial, consultoría, comercio y transporte en India, Indonesia, Sudáfrica y Rusia.

Las aplicaciones falsas suplantaban la marca Claude de Anthropic; no eran instaladores oficiales. Su eficacia dependía de una situación laboral creíble: un empleado busca una herramienta de productividad basada en IA, descarga lo que parece una aplicación conocida y, en realidad, instala malware. Los informes de Kaspersky describen la campaña como parte de la actividad de SilverFox observada en varias oleadas desde diciembre de 2025.

Del phishing fiscal a los señuelos de IA

La campaña también se apoyó en una fase anterior de phishing relacionado con impuestos. En enero y febrero de 2026, los investigadores registraron más de 1.600 correos maliciosos que se hacían pasar por avisos oficiales de auditoría fiscal o que afirmaban incluir listas de infracciones tributarias.

El mecanismo de distribución cambió, pero la señal de confianza siguió siendo familiar. Un aviso fiscal transmite urgencia y autoridad; un asistente de IA con una marca conocida transmite utilidad y comodidad. Ambos recursos pueden llevar a los usuarios a abrir un archivo adjunto, descargar un archivo comprimido o instalar software antes de comprobar su origen.

SilverFox utilizó un modelo de distribución por etapas, con infraestructura separada para distintas fases de la intrusión. Esta segmentación puede dificultar que los equipos de defensa bloqueen o identifiquen toda la cadena de ataque a partir de un único dominio o indicador.

La lección común: la confianza también forma parte de la superficie de ataque

Axios y SilverFox apuntaron a relaciones de confianza diferentes:

• Confianza en el mantenedor: las versiones de Axios parecían proceder de un editor autorizado en npm.
• Confianza en las dependencias: el gestor de paquetes trató la dependencia maliciosa como parte de una instalación normal.
• Confianza en la marca: los instaladores falsos de Claude se apropiaron de la identidad de un producto reconocible.
• Confianza en los flujos de trabajo: desarrolladores y empleados siguieron acciones rutinarias, como actualizar dependencias o instalar software de productividad.

El caso de Axios demuestra por qué una ventana de exposición breve puede ser peligrosa. Las instalaciones de paquetes y los trabajos de integración y entrega continuas pueden ejecutarse automáticamente, de modo que el alcance no se limita a quienes revisan manualmente una versión. El caso de SilverFox muestra el mismo principio en los equipos de usuario: las categorías de software que se adoptan con rapidez ofrecen a los atacantes nuevos señuelos creíbles.

Qué deberían hacer ahora las organizaciones

En relación con Axios, conviene revisar archivos de bloqueo, manifiestos de paquetes, registros de compilación, cachés e inventarios de dependencias en busca de axios@1.14.1, axios@0.30.4 y plain-crypto-js@4.2.1. Todo equipo que instalara una versión afectada durante la ventana de exposición debería investigarse para detectar cargas descargadas, mecanismos de persistencia no autorizados y credenciales expuestas. Los avisos recomiendan tratar las instalaciones afectadas como potencialmente comprometidas.

Para el software de IA, las empresas deberían exigir que los empleados obtengan las aplicaciones de escritorio a través de canales aprobados, verifiquen el editor y el dominio de descarga, y bloqueen o pongan en cuarentena los instaladores no autorizados. En la publicación de paquetes npm, la autenticación multifactor resistente al phishing, las credenciales de corta duración o con permisos estrictamente limitados, la trazabilidad del origen de las versiones, los archivos de bloqueo y la revisión de cambios en dependencias pueden reducir el riesgo de que una sola cuenta comprometida se convierta en un incidente de cadena de suministro.

El control más amplio es verificar cada frontera de confianza. Un nombre de paquete conocido no demuestra que todas sus versiones sean seguras, y el nombre de un producto conocido tampoco demuestra que todos sus instaladores sean auténticos.