Un conocido gusano de npm ha reaparecido tras más de tres meses de inactividad, utilizando el mismo archivo malicioso vinculado a un incidente previo de la cadena de suministro. Esta situación demuestra cómo una amenaza detectada puede volver a acceder a los entornos de desarrollo al ser republicada dentro de paquetes de software ordinarios. En la actividad más reciente, se detectaron cuatro paquetes cargados en el lapso de una hora.

Un gusano de npm ya conocido ha regresado después de más de tres meses de silencio, portando el mismo archivo malicioso vinculado a un incidente previo en la cadena de suministro.

Esta reaparición demuestra cómo una amenaza conocida puede recuperar el acceso a los entornos de desarrollo cuando se republica dentro de paquetes de software ordinarios.

La actividad más reciente involucró cuatro paquetes subidos en el lapso de una hora el 7 de septiembre. Cuando tú, como desarrollador, instalas una dependencia envenenada, el malware puede ejecutarse antes de que comiences tu trabajo normal, buscar tokens de acceso y utilizar tus derechos de publicación para propagarse a paquetes adicionales.

Este es el mismo riesgo visto en otros informes de ataques a la cadena de suministro de npm, donde una actualización confiable se convierte en la puerta de entrada inicial. Analistas de Aikido identificaron la carga útil recurrente durante un trabajo de triaje y descubrieron que su valor SHA-256 era idéntico al archivo observado durante el ataque del 19 de mayo a los paquetes @antv.

Aikido señaló en un informe que el resultado fue un intervalo de 111 días entre el último avistamiento conocido y su nueva aparición.

La oleada anterior fue sustancial: una cuenta de mantenedor comprometida lanzó 639 versiones maliciosas de paquetes @antv en una sola hora.

Los registros de Aikido contabilizaron 319 versiones de paquetes que portaban este hash de archivo, todas detectadas por primera vez el 19 de mayo, antes de que aparecieran cuatro nuevos lanzamientos el 7 de septiembre. El nuevo incidente es menor, pero es importante porque el código ya había sido ampliamente identificado.

El gusano npm Shai-Hulud reaparece

Los cuatro lanzamientos recurrentes fueron publicados por la misma cuenta de npm. Su característica principal no fue un implante rediseñado ni un componente recién oculto, sino la reutilización de una carga útil cuya huella digital había sido pública durante meses, ofreciendo a los atacantes un atajo hacia flujos de trabajo de desarrollo confiables.

Esa distinción es importante. El escaneo de malware se enfrenta a casos difíciles que involucran etapas ocultas, actividad retrasada o código que cambia según el entorno.

En este caso, los analistas dijeron que la muestra no fue empaquetada de nuevo ni alterada ligeramente. Fue una coincidencia exacta del hash del archivo, lo que convierte al incidente en una prueba de detección de malware conocido más que en una contienda con un método de evasión novedoso.

La carga útil utiliza una acción en el momento de la instalación para comenzar la ejecución. Puede validar tokens robados contra el registro de npm, descargar archivos de paquetes, insertar código, aumentar un número de versión y republicar la versión alterada.

Este ciclo automatizado explica por qué las infecciones por gusanos en npm pueden convertir rápidamente una cuenta de desarrollador comprometida en un problema más amplio de la cadena de suministro.

Su actividad también se extiende más allá de la instalación. El material de origen describe intentos de crear archivos de configuración de proyecto que pueden dejar una ruta de ejecución cuando el repositorio se abre más tarde.

También señala la creación masiva de repositorios de GitHub utilizando nombres relacionados con Dune y referencias inversas a Shai-Hulud, un comportamiento que puede ayudarte a cazar actividades relacionadas.

Qué deberías revisar si eres desarrollador

npm introdujo el escaneo al momento de la publicación en julio, reteniendo los paquetes durante aproximadamente cinco a 15 minutos antes de que estén disponibles para su instalación.

El sistema tiene como objetivo detener el malware detectable antes de que llegue a los usuarios. Esta reactivación sugiere que una verificación del registro aún puede fallar cuando debería reconocer un artefacto malicioso previamente catalogado.

Tu equipo debería revisar si las cuatro versiones identificadas fueron instaladas en estaciones de trabajo de desarrolladores, trabajos de integración continua o cachés de compilación.

Deberías rotar los secretos de npm, GitHub, nube y otros que puedan haber sido expuestos, y luego examinar las publicaciones recientes de paquetes de las cuentas afectadas. La respuesta refleja las lecciones del compromiso del paquete Keyv, donde los canales de lanzamiento válidos amplificaron un ataque de credenciales robadas.

Las organizaciones deberían fijar versiones de dependencias aprobadas, inspeccionar los scripts de instalación y los archivos de paquetes antes de la promoción, y limitar el alcance y la vida útil de los tokens de publicación.

Bloquear los scripts de instalación reduce el riesgo, pero no es una salvaguarda completa cuando el código malicioso utiliza rutas alternativas de compilación o de configuración del proyecto. La cobertura reciente del ataque a la cadena de suministro de binding.gyp ilustra cómo los atacantes pueden evitar las verificaciones que tu equipo espera que los protejan.

La preocupación no es que cada escáner pase por alto cada amenaza. Es que una carga útil con un hash público conocido y un largo historial de detección volvió a entrar en un ecosistema de paquetes importante sin cambios.

Tú y los operadores del registro deberían verificar los controles por capas, monitorear la actividad de publicación y asumir que el malware latente puede regresar sin previo aviso en cualquier momento a través de actualizaciones de paquetes que parecen familiares.