La Corea del Norte detrás de los ataques npm a debug, chalk y axios: la atribución de Amazon

Amazon atribuye al grupo norcoreano Sapphire Sleet los ataques npm a debug, chalk y axios: tres campañas que amenazan la cadena de suministro de software.

La Corea del Norte detrás de los ataques npm a debug, chalk y axios: la atribución de Amazon
APT

Imagen ilustrativa generada con IA

Introducción

El 29 de julio de 2026, Amazon Threat Intelligence atribuyó con confianza media al grupo norcoreano Sapphire Sleet (también rastreado como UNC1069 o BlueNoroff) el compromiso de algunos de los paquetes npm más populares del mundo. La investigación vincula por primera vez bajo una misma dirección tres campañas que, en el transcurso de doce meses, afectaron a debug y chalk en septiembre de 2025, a axios en marzo de 2026, y la publicación maliciosa del paquete typo‑crypto en marzo de 2025.
Análisis previos de Aikido y Wiz no habían identificado a un actor específico: ahora el panorama se completa, delineando una amenaza persistente y financieramente motivada a la cadena de suministro del software de código abierto.

Análisis técnico

Las tres campañas en comparación

Las operaciones muestran técnicas de ataque diferentes, síntoma de un adversario capaz de adaptarse a los controles de seguridad.

  • debug y chalk (septiembre de 2025): los atacantes comprometieron las cuentas de los mantenedores mediante ingeniería social y publicaron actualizaciones infectadas. El código malicioso inyectado – un script ejecutado del lado del navegador – no aprovechaba hooks de npm como postinstall, sino que se activaba directamente cuando las aplicaciones web cargaban los paquetes. Enganchándose a fetch, XMLHttpRequest y las API de billeteras de criptomonedas, el script modificaba silenciosamente las direcciones de las transacciones (wallet drainer), sin instalar persistencia alguna en el dispositivo.
  • typo‑crypto (31 de marzo de 2025): un paquete falso que imitaba crypto‑js (typosquatting), publicado como paquete original, no producto de un mantenedor comprometido. Contenía un disparador ofuscado (XOR con clave 01042025) que se activaba solo bajo condiciones específicas, probablemente un banco de pruebas para refinar las técnicas.
  • axios y Mastra (marzo de 2026): el acceso a los mantenedores permitió insertar scripts de ciclo de vida (postinstall) que distribuían una puerta trasera (WAVESHAPER.V2) para robo de credenciales y movimiento lateral en entornos de desarrollo.

Las pruebas y las discrepancias

Las evidencias públicas proporcionadas por Amazon – reutilización de código e infraestructuras C2 compartidas (npmjs[.]store, IP 216.74.123.126) – no detallan, sin embargo, el vínculo exacto entre las campañas. Surgen algunas discrepancias: el hash SHA256 indicado para core.js no coincide con ningún archivo en el repositorio de typo‑crypto y el paquete parece una operación de typosquatting original, no un mantenedor comprometido.
Google y Microsoft ya habían atribuido el ataque a axios al mismo actor, pero ningún otro proveedor ha confirmado públicamente la conexión también para debug, chalk y typo‑crypto. Aikido afirma haber vinculado los incidentes desde hace tiempo gracias a superposiciones en las C2 entre axios y Mastra.

La respuesta de la plataforma

npm v12 (lanzado el 8 de julio de 2026) deshabilita por defecto los scripts de ciclo de vida de las dependencias, eliminando el vector postinstall aprovechado por axios. Sin embargo, no protege contra ataques como el de debug y chalk, donde el código malicioso se distribuía directamente en el paquete y era ejecutado por las aplicaciones sin necesidad de hooks de instalación.

Impacto

Los paquetes involucrados totalizaban más de 2 mil millones de descargas semanales. La ganancia inmediata documentada es de solo 600 USD (fuente Socket), pero el riesgo sistémico es enorme y aún vigente.

  • Usuarios finales: el script en debug/chalk interceptaba transacciones de criptomonedas en el navegador, redirigiendo los fondos sin dejar rastros en el dispositivo.
  • Desarrolladores: la puerta trasera en axios permitía el acceso a credenciales y entornos empresariales, exponiendo redes y repositorios internos.
  • Ecosistema: el compromiso de mantenedores confiables y el uso de un paquete falso como prueba demuestran una planificación sofisticada y una amenaza concreta a la cadena de suministro, que explota la confianza depositada en los mantenedores de código abierto.

Mitigación

  • Actualizar npm a la última versión (v12) para bloquear los scripts de ciclo de vida; desafortunadamente, esto no es suficiente para ataques en el código como los vistos.
  • Proteger las cuentas de los mantenedores: imponer autenticación de dos factores (2FA), monitorizar accesos anómalos y revisar cada actualización sospechosa son contramedidas indispensables.
  • Detectar indicadores de compromiso: buscar en sus entornos el dominio npmjs[.]store, la IP 216.74.123.126 y el archivo core.js. En aplicaciones web, verificar posibles hooks anómalos en fetch, XMLHttpRequest y API de billeteras.
  • Verificar la integridad de los paquetes: comparar los hashes con los declarados y desconfiar de paquetes donde el autor difiere de la cuenta de publicación (caso typo‑crypto).
  • Eliminar dependencias no mantenidas y consultar avisos como OSV MAL‑2026‑3400 para typo‑[email protected].
  • Adoptar herramientas de análisis (p. ej., Socket) para monitorizar continuamente las dependencias.

FAQ

1. ¿Quién es Sapphire Sleet y por qué ataca npm?

Sapphire Sleet (UNC1069, BlueNoroff, STARDUST CHOLLIMA) es un grupo norcoreano especializado en ataques financieros. Ha atacado bancos y exchanges de criptomonedas; ahora ha extendido sus operaciones a la cadena de suministro del software para distribuir código malicioso a gran escala, con el objetivo de robar criptomonedas o acceder a redes empresariales. npm, con sus millones de desarrolladores, es un vector ideal.

2. ¿Cómo puedo verificar si he sido afectado?

Si tu aplicación utilizaba versiones comprometidas de debug, chalk o axios, inspecciona los bundles del lado del cliente en busca de scripts que intercepten fetch o XMLHttpRequest. Para axios, revisa los registros de red hacia los indicadores C2 (npmjs[.]store, 216.74.123.126) y verifica la integridad de los paquetes con hashes y herramientas de auditoría. La presencia del archivo core.js es una señal de alarma.

3. ¿Por qué npm v12 no es suficiente para bloquear estos ataques?

npm v12 neutraliza los scripts de ciclo de vida (p. ej., postinstall), el vector utilizado por axios. Sin embargo, los ataques a debug y chalk inyectaban código directamente en los archivos JavaScript del paquete, ejecutable sin necesidad de hooks de instalación. En consecuencia, la protección requiere prácticas de desarrollo seguro, verificaciones de integridad y monitorización continua de las dependencias, no solo actualizaciones de la plataforma.

Lee también

Fuentes

Este artículo es una reelaboración original basada en las siguientes fuentes.

Volver al inicio

Últimas noticias de ciberseguridad

Todas las noticias de ciberseguridad →