Amazon ha puesto el foco en un patrón inquietante dentro del ecosistema de software abierto: ataques a npm que, según sus investigaciones, terminaron conectándose con un actor vinculado a Corea del Norte. No se trata de un único incidente aislado, sino de una serie de compromisos que afectaron paquetes muy utilizados y que, en conjunto, muestran una estrategia cada vez más sofisticada.
La conclusión de Amazon combina señales técnicas observadas en la campaña, la infraestructura de mando y control (C2) y similitudes operativas. Aunque la atribución no se considera definitiva, la empresa afirma que la evidencia tiene confianza media y encaja con las tácticas empleadas.
Qué ataques a npm vinculó Amazon
Amazon relaciona la intrusión de varios paquetes con el actor de amenazas conocido como Sapphire Sleet (también referido con nombres alternativos como BlueNoroff y Stardust Chollima). En el análisis, la empresa destaca los compromisos de bibliotecas de gran visibilidad dentro de Node Package Manager (npm), incluyendo typo-crypto, debug, chalk y axios.
El desarrollo de la campaña, según lo descrito, siguió una progresión: comenzó con un paquete menos obvio y fue escalando hacia librerías ampliamente adoptadas en entornos cloud.
De un “paquete de prueba” al impacto masivo
De acuerdo con Amazon, la actividad inicial se remonta a marzo de 2025, cuando el paquete typo-crypto fue modificado para introducir código malicioso. La empresa sugiere que ese paquete pudo haber funcionado como un terreno de prueba: un modo de validar el enfoque antes de ampliar el alcance.
Posteriormente, en septiembre de 2025, el ataque se intensificó al comprometer debug y chalk, dos librerías muy comunes. Amazon estima que el impacto pudo alcanzar aproximadamente el 10% de los entornos cloud en un lapso de dos horas. Este tipo de ventana corta es especialmente peligroso: limita el tiempo para detectar anomalías antes de que el daño se propague.
El salto a axios
En marzo de 2026, el foco se movió hacia axios, una de las bibliotecas más populares de npm, con más de 100 millones de descargas semanales. Amazon sostiene que este incidente encaja con la misma línea de actividad, aunque recuerda que el caso de axios ya había sido atribuido públicamente a actores vinculados a la DPRK.
La novedad, en la lectura de Amazon, no está solo en el “quién”, sino en el “cómo encajan las piezas”: la empresa conecta axios con los compromisos previos de paquetes anteriores, construyendo una narrativa más completa de la campaña.
Cómo entraron: ingeniería social y actualizaciones maliciosas
Amazon indica que el atacante obtuvo acceso mediante ingeniería social dirigida a mantenedores de paquetes. Una vez dentro, publicó actualizaciones maliciosas que se distribuían automáticamente a usuarios desprevenidos.
Este mecanismo es particularmente dañino porque el consumo de dependencias es automático en muchos flujos de desarrollo. Cuando un paquete confiable cambia su comportamiento, la aplicación que lo utiliza puede incorporar el riesgo sin que el equipo lo note.
Por qué Amazon dice que la atribución tiene confianza media
La atribución a Sapphire Sleet se apoya en varios elementos que, combinados, fortalecen el vínculo: tácticas, técnicas y procedimientos (TTPs) compartidos, coincidencias en la infraestructura C2 y similitudes operativas en la ejecución de la campaña.
Amazon describe estas correspondencias como un conjunto de indicadores, no como una única “prueba” determinista. Por eso el nivel de confianza se ubica en un punto intermedio.
Motivación financiera: atacar popularidad para ampliar la víctima
Además del componente geopolítico, Amazon apunta a una motivación de tipo financiero. El razonamiento es claro: en vez de comprometer objetivos uno a uno, el atacante elige paquetes muy utilizados para acceder indirectamente a un gran conjunto de víctimas “aguas abajo” de forma simultánea.
En este enfoque, cada descarga potencial es una oportunidad. Y cuanto mayor sea la adopción del paquete, mayor el efecto acumulado.
Tendencias que muestran los ataques modernos a la cadena de suministro
Amazon subraya que los incidentes recientes reflejan cambios en la forma en que se diseñan los compromisos. Varias tendencias se repiten y, juntas, dificultan la detección tradicional.
1) Funcionalidad maliciosa repartida entre paquetes
Una estrategia clave es dividir la funcionalidad maliciosa entre distintos paquetes que, por separado, parecen benignos. Así, la señal se diluye: los equipos pueden inspeccionar un componente y no ver el conjunto completo del comportamiento dañino.
2) Construir confianza antes del ataque
Amazon advierte que los atacantes pueden dedicar meses a generar reputación. Mantener proyectos legítimos, contribuir de manera visible o aparecer como colaborador “normal” reduce las probabilidades de bloqueo temprano cuando se introduce el código malicioso.
3) Separar el contenido del comportamiento
Otra evolución es la desacoplación entre lo que contiene el paquete y lo que realmente hace. El comportamiento puede depender de scripts externos, archivos de configuración o servidores remotos que se activan después. Ese diseño complica el análisis estático, porque el “plan completo” no siempre está presente en el artefacto inicial.
4) Cifrado más fuerte y cargas en varias etapas
En algunos casos, el malware usa cifrado más robusto y payloads por etapas. Además, se mencionan claves recuperadas en tiempo de ejecución o de forma remota, lo que dificulta el análisis estático porque el contenido puede quedar protegido hasta el momento de ejecución.
5) Comportamiento consciente del entorno
Amazon también describe técnicas donde la ejecución se retrasa o se condiciona. El malware puede intentar identificar si está en un entorno real de desarrollo o producción, evitando activarse en sandboxes o entornos de análisis. Con ello se reduce la probabilidad de que el equipo de seguridad vea el comportamiento malicioso durante las pruebas automatizadas.
6) Slopsquatting con nombres generados por IA
Finalmente, se menciona un riesgo emergente: el slopsquatting. Consiste en registrar nombres de paquetes que parecen “inventados” por asistentes de código con soporte de IA, con la esperanza de que desarrolladores humanos o agentes autónomos instalen esos paquetes sin darse cuenta.
Esto amplía el vector de ataque hacia el proceso de generación de código, donde los nombres pueden aparecer como sugerencias “razonables” pero peligrosas.
El papel de la IA en la eficacia de los atacantes
Amazon explica que muchas de estas técnicas se benefician de la IA. Al automatizar y acelerar la generación, el atacante puede producir código, documentación e identidades de mantenedores de forma más eficiente. El resultado es una operación más rápida y creíble, lo que aumenta la probabilidad de que el paquete pase desapercibido antes de introducir el código dañino.
Respuesta: reportar, colaborar y proteger el software abierto
Amazon presenta una respuesta multi-capa. Por un lado, reporta los hallazgos y comparte inteligencia con la comunidad para mejorar el conocimiento colectivo. Además, colabora con iniciativas del sector, como OpenSSF y otros socios.
También menciona una inversión de 12,5 millones de dólares en la iniciativa Akrites, orientada a reforzar la seguridad de software abierto frente a ataques habilitados por IA.
Una recomendación práctica: probar cada capa antes que el atacante
Los ataques de cadena de suministro son difíciles de vigilar porque parte del recorrido ocurre dentro del ecosistema de dependencias. Amazon cita una idea clave sobre la visibilidad: los equipos pueden registrar una fracción de los ataques exitosos y alertar en otra mucho menor, lo que implica que el resto puede moverse sin ser detectado.
En ese contexto, la lección es clara: la seguridad no debería limitarse a “reaccionar” cuando algo ya ocurrió. Es mejor evaluar controles, reglas y capacidades para que las amenazas no se cuelen por los huecos entre herramientas, registros y detección.
Conclusión
Los ataques a npm descritos por Amazon reflejan cómo un adversario puede combinar ingeniería social, compromisos de paquetes populares y técnicas modernas para reducir la detección. Al vincular varios incidentes entre bibliotecas como debug, chalk, axios y typo-crypto, la empresa ofrece una visión más conectada de la campaña y de por qué el riesgo es estructural: se apoya en confianza y automatización.
Para equipos de desarrollo y seguridad, el mensaje central es doble: fortalecer la verificación de dependencias y mejorar la detección a través de pruebas reales de los controles. Así, cuando aparezcan variaciones de estas tácticas, habrá menos margen para que el ataque pase inadvertido.
