TL;DR:
- Amazon Threat Intelligence atribuye los ataques a typo-crypto, debug, chalk y axios a un solo actor ligado a Corea del Norte, activo entre marzo de 2025 y marzo de 2026.
- axios rebasa los 100 millones de descargas semanales, y el episodio de septiembre de 2025 llegó a cerca de 1 de cada 10 entornos de nube en unas dos horas, según Wiz.
- La atribución es de confianza media, llega diez meses después del caso más grande y Aikido, la firma que lo detectó, responde que ese vínculo ya se conocía.
Amazon Threat Intelligence atribuyó a un mismo actor vinculado con Corea del Norte el compromiso de cuatro paquetes de npm ocurrido entre marzo de 2025 y marzo de 2026: typo-crypto, debug, chalk y axios. La investigación, publicada el 29 de julio de 2026 y firmada por CJ Moses, director de seguridad de Amazon Integrated Security, sostiene que las tres campañas empezaron igual: ingeniería social contra un mantenedor de confianza y, después, una actualización envenenada publicada desde una cuenta legítima. Cualquier organización que jalara la última versión de forma automática se llevó el paquete comprometido. Amazon rastrea al grupo con los alias SAPPHIRE SLEET, STARDUST CHOLLIMA, BlueNoroff, CageyChameleon y Alluring Pisces, y califica su propia atribución como de confianza media.
El cálculo del atacante es aritmético. En lugar de perseguir empresa por empresa, envenena una pieza que ya vive dentro de todas. axios rebasa los 100 millones de descargas semanales, y del episodio de septiembre de 2025 el propio Amazon rescata el número más incómodo, calculado por Wiz Research: el código malicioso alcanzó a alrededor de 1 de cada 10 entornos de nube en una ventana de unas dos horas.
Cuatro paquetes, tres campañas y una sola puerta de entrada
La cronología que publica Amazon empieza en la periferia y termina en el centro del ecosistema JavaScript:
- Marzo de 2025, typo-crypto. Un paquete menor con un archivo troyanizado, core.js, que se hacía pasar por la librería legítima core-js. Las descargas fueron pocas y Amazon lo lee como banco de pruebas. Amazon Inspector lo reportó a la base de datos Open Source Vulnerabilities, donde quedó registrado como MAL-2026-3400.
- Septiembre de 2025, debug y chalk. Cayeron dentro del incidente que alcanzó al menos 18 paquetes que suman más de 2,000 millones de descargas semanales. Durante diez meses ese caso figuró en el expediente público como un robo de criptomonedas y nada más.
- Marzo de 2026, axios. El cliente HTTP más popular de npm, presente en el árbol de dependencias de buena parte de las aplicaciones web modernas.
Amazon interpreta el patrón como puramente financiero: comprometer un puñado de paquetes muy usados abre miles de entornos aguas abajo al mismo tiempo, algo mucho más eficiente que atacar de uno en uno. Y el equipo llegó a typo-crypto por casualidad, siguiendo un dominio registrado en 2025 que apareció mientras investigaba el caso de axios.
El ataque a axios empezó en un Slack falso, no en el código
El post-mortem que publicaron los propios mantenedores de axios y que reportó BleepingComputer explica cómo se armó la trampa, y el detalle importa porque ahí no hubo ninguna vulnerabilidad de software. Los atacantes suplantaron a una empresa real, clonaron su marca y la imagen de sus fundadores, y sumaron al mantenedor principal, Jason Saayman, a un espacio de Slack con canales activos, publicaciones montadas y perfiles falsos de empleados y de otros mantenedores de código abierto.
Después vino una junta por Microsoft Teams. En plena llamada apareció un error técnico que pedía instalar una actualización para corregirlo. Esa actualización era un troyano de acceso remoto, y con él llegaron las credenciales de npm del proyecto. Como los atacantes trabajaron sobre sesiones ya autenticadas, la verificación en dos pasos quedó en el camino.
Con esas llaves publicaron las versiones 1.14.1 y 0.30.4, que inyectaban una dependencia llamada plain-crypto-js y con ella un troyano para Windows, macOS y Linux. Estuvieron disponibles cerca de tres horas. El código fuente de axios nunca se tocó.
Otros mantenedores de proyectos muy usados reportaron el mismo guion. Pelle Wessman, que mantiene varios proyectos de código abierto, entre ellos Mocha, contó que se negó a instalar la aplicación y que entonces intentaron convencerlo de ejecutar un comando en la terminal.
"Cuando me negué, desaparecieron y borraron todas las conversaciones", escribió Pelle Wessman.
La atribución llega tarde y no dice qué evidencia liga a qué incidente
Amazon presenta el hallazgo como la primera vez que estos compromisos se atan públicamente a este actor. Ahí es donde conviene bajar la velocidad.
The Hacker News revisó el reporte y señala un hueco: el texto cita tácticas compartidas (paquetes troyanizados, ganchos que se ejecutan al instalar, reutilización de código) e indicadores de mando y control que se solapan, pero no aclara qué evidencia conecta cada incidente en particular. Ese vacío pesa sobre todo en debug y chalk, donde Aikido y Wiz habían documentado un interceptor que corría en el navegador y reescribía direcciones de transacciones antes de que el usuario firmara, sin dejar persistencia en la máquina y sin depender del gancho de instalación que sí usó axios.
La diferencia de tiempos también cuenta. Las atribuciones de axios aterrizaron en dos días: Google lo asignó a UNC1069 por un backdoor y por infraestructura ya vista antes, y Microsoft lo asignó a Sapphire Sleet, aclarando que ese nombre se solapa con UNC1069, STARDUST CHOLLIMA, BlueNoroff, Alluring Pisces, CageyChameleon y CryptoCore. Las otras dos atribuciones tardaron diez y dieciséis meses.
Aikido, la firma que detectó el ataque de septiembre de 2025, respondió a The Hacker News que ella viene señalando el vínculo con Corea del Norte desde hace tiempo, en publicaciones, charlas y pódcast, y que en la comunidad de cadena de suministro eso ya se daba por sabido. Sobre el tamaño real del botín de aquel episodio hay un dato que ordena la conversación: Socket calculó entonces que las billeteras de los atacantes habían juntado unos 600 dólares.
Hay un detalle más que reportó The Hacker News tras revisar el registro por su cuenta: typo-crypto seguía publicado e instalable el 30 de julio, con una sola versión creada y publicada con 204 milisegundos de diferencia el 31 de marzo de 2025, una cuenta publicadora que no coincide con el autor declarado y una descripción copiada de otra librería. Ese expediente se parece menos a un mantenedor comprometido y más a un paquete nacido para suplantar a otro desde el primer día, que es justo lo contrario de como Amazon describe las tres campañas.
npm cerró una puerta en julio, pero no la que usaron aquí
Para cualquier equipo de desarrollo, en México, España o cualquier otro país, lo accionable está en el registro, no en la atribución. El 8 de julio de 2026 npm liberó su versión 12, con los scripts de ciclo de vida de las dependencias desactivados por defecto, lo que elimina la vía automática que aprovechó el caso axios. El 28 de julio empezó a escanear en busca de malware los paquetes recién publicados antes de que queden instalables, aunque esa revisión aplica a publicaciones nuevas y no a lo que ya está en el registro.
Ninguna de las dos medidas toca el punto por donde entraron los cuatro casos.
"Ni el bloqueo de scripts de instalación ni OIDC cierran esa vía de entrada", escribió Sarah Gooding, de Socket, al revisar la nueva versión de npm.
Amazon dedica además media investigación a explicar por qué la detección tradicional está perdiendo terreno. Los paquetes maliciosos solían delatarse solos: inglés roto, documentación pobre, funciones copiadas de un caso a otro. La IA generativa borró esas señales y permite fabricar historiales de commits e identidades de mantenedor que se sostienen bajo revisión. Aparecen también dos vías nuevas. El slopsquatting es una técnica que consiste en registrar nombres de paquetes que no existen y que un asistente de IA inventó al recomendar dependencias, para que el siguiente que siga esa recomendación se lleve malware sin haber escrito mal nada.
La segunda apunta directo a las herramientas de defensa. Amazon anticipa que los paquetes maliciosos llevarán instrucciones escondidas en comentarios, archivos README o pruebas, redactadas para convencer a un revisor automático de que marque como seguro lo que no lo es. Es la misma técnica que FomoEra revisó cuando la investigación empezó a usarla del lado defensivo.
Alejandro Castillo Leone
Ese riesgo crece justo cuando más equipos delegan la instalación de dependencias a agentes que revisan poco, un terreno donde ya hubo movimiento: en junio, Microsoft deshabilitó 73 repositorios de GitHub por malware dirigido a agentes de IA. Amazon dice estar ampliando la cobertura de Amazon Inspector, compartiendo indicadores con GuardDuty y trabajando con la Open Source Security Foundation, y recuerda que en 2026 se sumó junto con la Linux Foundation y otras empresas a Akrites, una iniciativa para defender software abierto crítico de ataques potenciados por IA, con 12.5 millones de dólares aportados en conjunto.
Los cuatro casos comparten un detalle que ninguna herramienta resuelve todavía: nadie necesitó una falla en el código. Bastó con convencer a la persona que tiene permiso de publicar. Mientras esa vía siga abierta, el eslabón más frágil del software que sostiene medio internet seguirá siendo una videollamada con un error inventado.
