Shai-Hulud resucita tras 111 días

Hola, Internet,

¿Te acuerdas de la Ataque de Shai-Hulud ese golpe @AntV ¿El 19 de mayo de 2026? Lo sé, en el mundo de la cadena de suministro ya parece que haya pasado toda una vida. Una cuenta de administrador comprometida publicó 639 versiones maliciosas de paquetes de @antv en npm en tan solo una hora. Nosotros, junto con la mayor parte de la comunidad de seguridad de npm, desmantelamos esa carga maliciosa en cuestión de horas. No fue nada nuevo, desde el punto de vista técnico. Fue simplemente otro día en el que nos despertamos y nos encontramos con un ataque a la cadena de suministro. Lo de siempre.

Desde entonces, npm ha incorporado un análisis de malware en el momento de la publicación. Así que podéis imaginaros mi sorpresa cuando, esta mañana, mientras revisaba nuestra cola de triaje, vi lo que reconocí de inmediato como un «wormy boy». Tenía el mismo hash que el @AntV wave. La misma carga útil:

e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6. Se trata del mismo archivo del que npm, nosotros y la mitad de los proveedores de esta lista ya habíamos obtenido la huella digital hace meses.

Son 111 días de silencio total en ese hash. Por lo que sabemos, es el periodo más largo entre el estado de inactividad y la reactivación que hemos visto en una carga útil de Shai-Hulud, y por un amplio margen. Llamémoslo por su nombre: un «zombi» que ha reaparecido cuatro meses después de que todo el mundo diera por hecho que estaba muerto.

Los cuatro paquetes que lo recuperaron, todos ellos publicados en el mismo espacio de una hora el 7 de septiembre desde la misma cuenta de npm:

• feishu-docx-mcp@0.3.2
• bmc-i18n-extract-cli@1.1.1
• blueai-cli@0.7.0
• bmc-translate-utils@1.1.1

Las cifras

Hemos consultado nuestro historial de detección para este hash de archivo concreto en todas las versiones de paquetes que hemos analizado. Esta es la cronología real:

Según nuestros registros, hay 319 versiones de paquetes con este hash, y todas y cada una de ellas aparecieron por primera vez el 19 de mayo de 2026, el día del @AntV una oleada y ni un día antes ni después. Después, nada. Cero nuevas visitas a este hash entre el 20 de mayo y el 6 de septiembre. Luego, a partir de hoy (7 de septiembre), han aparecido en npm otras cuatro versiones del paquete con exactamente el mismo contenido. Eso supone un intervalo de 111 días: la última vez se vio el 19 de mayo y la siguiente, el 7 de septiembre.

Cuatro paquetes es una cifra insignificante si se compara con un hecho más relevante: una carga útil con un hash conocido, publicado e indexado permaneció sin ser detectada en la cadena de herramientas de nadie durante más de tres meses y, posteriormente, se volvió a publicar en un registro que, desde este año, analiza explícitamente todos los paquetes antes de su publicación.

El caso sencillo

En julio, npm puso en marcha un sistema de análisis de malware en el momento de la publicación: cada paquete queda en espera entre 5 y 15 minutos mientras un sistema automatizado lo comprueba antes de que pueda instalarse. Según el propio registro de cambios de npm, el objetivo es detectar «el malware que podamos detectar» antes de que llegue a la fase de instalación de npm.

La coincidencia del hash de un archivo es una simple consulta, no un problema complejo. No requiere ningún tipo de « análisis de comportamiento », ni «sandboxing», ni tampoco hay que deducir la intención del código ofuscado. Y esta carga útil no era nueva, ni se había reempaquetado, ni siquiera se había modificado ligeramente para eludir la coincidencia de firmas. Se trataba de los mismos 64 caracteres hexadecimales que figuraban en el archivo desde mayo.

No estamos diciendo que el escáner deba detectar todo. Problemas como los cargadores en varias etapas, la confusión de dependencias y las cargas útiles activadas en tiempo de ejecución son realmente difíciles de resolver. Sin embargo, una coincidencia exacta del hash con un gusano que fue noticia internacional en materia de seguridad hace cuatro meses no lo es. Ese es el mínimo que se supone que debe detectar un análisis en el momento de la publicación, y se pasó por alto. Esta muestra concreta debería estar en el corpus de pruebas de cualquiera que realice análisis de la cadena de suministro.

La conclusión

Una carga útil de un gusano con un hash público, amplios informes de los proveedores y meses de cobertura de detección permaneció inactiva durante 111 días, para luego volver a aparecer en npm sin ningún tipo de obstáculo, en un registro que ahora se promociona por analizar cada publicación. Esa brecha entre lo que el análisis a nivel de registro afirma hacer y lo que una reactivación con un hash idéntico demuestra que realmente detectó es lo realmente relevante aquí. La comparación de firmas con artefactos maliciosos conocidos es el listón más fácil de superar en este sector, y es el listón cuyo fallo debería alarmarnos más a todos. Si esto es lo que se cuela en el caso más sencillo, cabe preguntarse qué habría pasado con una carga útil que se hubiera tomado la molestia de cambiar un solo byte.

Indicadores de Compromiso

Red:

• t[.]m-kosche[.]com (C2, de la tanda original de mayo)

Archivo:

• SHA256: e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6
• Nivel raíz index.js carga útil
• Ejecución del script de preinstalación bun run index.js

Perseverancia:

• .vscode/tasks.json
• .claude/settings.json

Comportamentales:

• Llamadas de validación salientes al registro de npm utilizando tokens robados
• Descarga del archivo tar, inyección de carga útil, aumento de la versión, ciclo de reedición
• Creación masiva de repositorios de GitHub con nombres inspirados en Dune y cadenas de texto «Shai-Hulud» invertidas en las descripciones