La atribución como trampa: un ataque a npm y la fragilidad de la cadena de suministro de software

La reciente reelaboración de la autoría del secuestro de paquetes npm —que ahora Amazon Threat Intelligence asocia con Corea del Norte— vuelve a poner sobre la mesa una lección conocida pero insuficientemente resuelta: las atribuciones tardías y fragmentarias complican la defensa y la remediación en la cadena de suministro de software.

En septiembre de 2025 se detectó un ataque que comprometió paquetes muy populares como debug y chalk, y que se mostró al público inicialmente como un fraude criptográfico: un mantenedor fue víctima de un phishing en un dominio que imitaba npm y una actualización maliciosa incluía código para reescribir direcciones de billeteras en el navegador. Desde entonces se identificaron otras piezas potencialmente relacionadas —como una implantación en axios en marzo de 2026 y un paquete pequeño llamado typo-crypto en marzo de 2025— y Amazon sostiene que las tres campañas comparten grupo autoral y patrón táctico. Sin embargo, la evidencia que Amazon publica es parcial: describe coincidencias en el tradecraft, reutilización de código, ganchos post-instalación y algunos indicadores de mando y control, pero no traza públicamente una cadena clara que vincule cada incidente con esos mismos indicadores.

Ese vacío importa. Para debug y chalk se documentó código que operaba exclusivamente en el lado del navegador, interceptando fetch, XMLHttpRequest y APIs de billeteras para reescribir direcciones antes de firmar transacciones; ese código no persistía en disco y no dependía de hooks post-install como sí lo hacía el payload de axios. En typo-crypto, el comportamiento observado —un trigger en espera y un segundo estadio descargado desde un C2— sugiere una prueba de concepto pequeña con pocos descargas, no una campaña masiva desde el primer día. Además, en el caso de typo-crypto hay inconsistencias en los metadatos del registro: una única versión publicada de inmediato por una cuenta que no coincide con el autor declarado y archivos que aparentan impersonar a librerías legítimas, lo que plantea la posibilidad de que fuera publicada maliciosamente desde el inicio, no hijackeada mediante actualización. Amazon también aporta hashes y nombres de archivo que, según el análisis público, no emparejan exactamente con el contenido disponible en el tarball del registro, lo que vuelve aún más difícil verificar públicamente la relación entre los artefactos descritos y los paquetes señalados.

La atribución técnica y la atribución política no son lo mismo. Mientras Google y Microsoft atribuyeron rápidamente el compromiso de axios a actores que sus firmas rastrean como UNC1069 / WAVESHAPER y Sapphire Sleet (con la terminología variando entre proveedores), Amazon extiende esa lectura a campañas más antiguas y menos claras. La diferencia en tiempos —atribuciones casi inmediatas para axios frente a reatribuciones a los diez o dieciséis meses para debug, chalk y typo-crypto— resalta por qué las organizaciones deben exigir transparencia en la evidencia y conservar telemetría para permitir reconstrucciones forenses posteriores.

Del lado defensivo, algunas medidas recientes de npm ayudan, pero no eliminan el riesgo de comprometer un paquete vía ingeniería social. La versión v12, lanzada en julio, vino con los scripts de ciclo de vida desactivados por defecto, lo que reduce la vía de explotación basada en post-install scripts que explotó axios. Además, npm comenzó a escanear paquetes nuevos en el momento de la publicación. Son pasos en la dirección correcta, pero no cierran la puerta a ataques que aprovechan la confianza del mantenedor, cuentas mal gestionadas, o paquetes publicados maliciosamente desde cero.

Para desarrolladores y equipos responsables de dependencias, hay recomendaciones inmediatas y prácticas que reducen la exposición: usar archivos de bloqueo y realizar instalaciones reproducibles con 'npm ci' en entornos controlados; revisar cuidadosamente paquetes pequeños o con pocos mantenedores antes de añadirlos; aplicar autenticación multifactor y rotación de tokens de publicación; minimizar los privilegios de las cuentas que publican y hacerlo desde CI con credenciales efímeras; auditar las dependencias transitorias y no instalar paquetes en entornos de usuario con menos restricciones. A nivel organizacional, conviene generar y mantener SBOMs, integrar escaneos automáticos en la cadena de CI/CD, adoptar mecanismos de firma de artefactos (por ejemplo, proyectos del ecosistema Sigstore) y aplicar controles de admisión que verifiquen integridad y procedencia antes de incluir una dependencia en producción. Recursos que orientan estas prácticas son útiles, por ejemplo la iniciativa SLSA (https://slsa.dev) y la asesoría de agencias como CISA sobre seguridad de la cadena de suministro (https://www.cisa.gov/supply-chain).

Para los operadores de registries y proveedores de ecosistemas la lección es doble: mejorar la detección automatizada no basta; la usabilidad y las políticas deben empujar a los mantenedores hacia prácticas seguras sin aumentar fricción operativa innecesaria. Eso implica ofrecer opciones de publicación más seguras desde CI, visibilizar cambios de propiedad de paquetes, detectar patrones anómalos de publicación o de coincidencias entre metadatos y objetos binarios, y facilitar procesos rápidos y transparentes para mitigar y retirar paquetes comprometidos cuando haya evidencia sólida.

Finalmente, el episodio subraya una realidad política: atribuir una campaña a un estado-nación tiene consecuencias amplias que van más allá del técnico. Requiere un estándar de prueba público y reproducible cuando la atribución influirá en decisiones de políticas, sanciones o respuesta internacional. Mientras tanto, quienes desarrollan y despliegan software deben operar bajo el supuesto de que el riesgo existe y aplicar principio de menor privilegio, defensa en profundidad y prácticas de higiene en la cadena de suministro para limitar el impacto de incidentes que a veces solo se comprenden semanas, meses o incluso años después.