Shai hulud - paquetes npm - ataque á cadea de subministración

Shai-Hulud: Explicación do verme de paquetes npm

TL, RD

O 14 de setembro de 2025, os investigadores identificaron Shai Hulud, un verme autorreplicante agochado no interior paquetes npm, convertendo unha actualización de dependencias rutineira nunha actualización a grande escala ataque á cadea de subministraciónVisto por primeira vez no @ctrl/colormini paquete de Daniel dos Santos Pereira, Shai-Hulud recolle segredos, exfíltraos a través de repositorios e fluxos de traballo de GitHub e republicase no rexistro usando credenciais roubadas. En cuestión de días, o número de paquetes infectados pasou de ducias a centos, o que confirma que Shaihulud non é só outro troiano, senón un verme deseñado para propagarse automaticamente polo ecosistema npm.

Impacto: Calquera desenvolvedor ou executante de CI que instale paquetes npm públicos está en risco.

Accións inmediatas: bloquear versións coñecidas, cambiar a instalacións só de ficheiros de bloqueo, rotar tokens de npm e GitHub, auditar fluxos de traballo e monitorizar os indicadores de compromiso (IoC).

Que pasa?

o Ataque de Shai-Hulud á cadea de subministración en paquetes npm é un dos incidentes máis perturbadores da memoria recente. A diferenza dos troianos illados, este verme mestura roubo de credenciais, exfiltración automatizada e autorreplicaciónEn consecuencia, o prazo de infección reduciuse de semanas a só unhas horas.

Para os equipos de DevOps, a lección é clara: se cada instalación pode executar código, entón cada actualización de dependencia é un posible punto de violación.

Posible vector inicial e credenciais dirixidas

Análise inicial indica que o ataque probablemente comezou con credenciais roubadasPor exemplo, as campañas de phishing que suplantan a identidade de npm login ou as solicitudes de MFA poden ter capturado tokens de desenvolvedor. Unha vez que os atacantes acadaron ese primeiro punto de apoio, o verme propagouse incrustándose en paquetes npm e roubando máis segredos de:

  • ficheiros de configuración de npm como .npmrc, que a miúdo conteñen tokens de publicación.
  • Variables de ambiente e configuracións con PATs de GitHub e CI/CD segredos.
  • Puntos finais de metadatos na nube (AWS, GCP, Azure) que producen credenciais de curta duración para o movemento lateral.

Polo tanto, o roubo de credenciais converteuse na plataforma de lanzamento. Con tokens npm válidos e segredos de GitHub, Shai-Hulud podía autorreplicarse en múltiples paquetes e repositorios sen esforzo humano adicional.

Impacto executivo do ataque á cadea de subministración de Shai-Hulud

Shai-Hulud aínda está activo hoxe en día. Este verme acelera a liña temporal do impacto. O que antes tardaba semanas cun troiano agora desenvólvese en horas. Como resultado, a propagación é máis rápida e máis difícil de conter. Avanza por:

  • Roubar tokens de publicación de npm e segredos de GitHub.
  • Republicándose noutros paquetes npm.
  • Engadindo fluxos de traballo de accións de GitHub maliciosos para a persistencia.

Quen está afectado:

Calquera equipo que instale paquetes públicos npm está exposto. Ademais, os desenvolvedores con tokens npm ou GitHub almacenados en caché corren un alto risco. Os executores de CI que usan segredos de amplo alcance tamén son vulnerables.

Risco empresarial

O impacto empresarial medra rapidamente. Os tokens roubados poden levar á apropiación de contas, ao secuestro de paquetes e mesmo ao mal uso da nube. Ademais, a persistencia nos fluxos de traballo de GitHub dificulta a súa limpeza. Polo tanto,, os equipos deben tratar Shai-Hulud como un incidente en curso, non como un incidente pechado.

Como funciona o ataque á cadea de subministración Shai-Hulud nos paquetes npm

Obxectivos e motivos do atacante

A campaña optimízase para tres cousas:

  • O primeiro obxectivo é roubar credenciais a escala desde portátiles de desenvolvedores e executores de CI. Isto inclúe tokens de publicación npm, tokens de GitHub e credenciais na nube. De feito, varias análises confirman a recollida sistemática de segredos, como a execución de TruffleHog e a consulta de puntos finais de metadatos na nube.
  • O segundo obxectivo é propagar automaticamente abusando dos dereitos de publicación dos mantedores comprometidos. Como resultado, un punto de apoio expándese rapidamente a moitos, xa que aparecen novas versións infectadas doutros paquetes sen esforzo humano adicional.
  • O terceiro obxectivo é persisten e exfiltran de forma fiable a través da infraestrutura de GitHub. Os atacantes crean un repositorio público chamado "Shai-Hulud" cunha dobre base64 datos.jsone, ademais, implantan un fluxo de traballo que serializa ${{ toJSON(segredos) }} e publícao nun webhook estático.

A probable recompensa inclúe acceso a longo prazo aos rexistros e ao código fonte, movemento lateral rápido cara ás contas na nube e a opción de armar aínda máis a cadea de subministración. Os informes públicos mostran que os repositorios privados se converteron en público cun "-migración" sufixo, que aumenta a exposición e o impulso dos datos

Dentro da carga útil de Shai-Hulud: paquete.js en paquetes npm

Shai-Hulud envíase como un grandes, agrupados en Webpack e fortemente minificados Ficheiro JavaScript (paquete.js, uns 3–3.7 MB) que se executa desde un postinstalación enganchar paquete.jsonEn consecuencia, Cada instalación activa a carga útil automaticamente. Este deseño oculta os identificadores, comprime o fluxo de control e empurra toda a lóxica nun único artefacto que se executa durante a instalación. Os analistas confirman sistematicamente a agrupación de Webpack, o tamaño de ficheiro inusual e a execución no momento da instalación.

Trazos de ofuscación e antianálise que verás nas mostras:

  • Gráfico de módulos minimizado con IDs de módulo numéricos, comentarios dispersos e fluxo de control aplanado. Ademais, Esta estrutura fai que a revisión manual sexa extremadamente difícil.
  • Ocultación de cadeas mediante capas base64 e axudantes de construción. Por exemplo, A codificación e descodificación base64 repetidas adoitan aparecer arredor das rutinas de exfiltración.
  • Envío dinámico a través evalpatróns de estilo e corpos de función xerados, o que permite que o código cambie de comportamento en tempo de execución.
  • Filtrado do sistema operativo preferir a execución de Linux e macOS, especialmente en executadores de CI e portátiles de desenvolvedores.

Desde un punto de vista funcional, o conxunto é modular. As descricións describen módulos para o descubrimento de sistemas operativos, análises de segredos de git e do sistema de ficheiros, acceso ao SDK na nube, operacións da API de GitHub e un motor de propagación que edita outros paquetes que posúe o responsable do mantemento. De feito, StepSecurity e ReversingLabs destacan unha función que actualiza automaticamente os paquetes co hook malicioso.

Execución en tempo de instalación en Shai-Hulud: como os paquetes npm activan o verme

O ataque comeza cando nó de execucións posteriores á instalación paquete.js. Neste punto, o script inicializa e desempaqueta o estado de traballo na memoria, preparando o escenario para o funcionamento completo do verme.

Descubrimento e colleita

  • A carga útil descarga process.env e analiza os ficheiros locais en busca de segredos de alta entropía e prefixos de tokens. Ademais, amplía a cobertura executando TruffleHog.
  • Consulta os puntos finais de metadatos da nube para recoller credenciais de curta duración. Por exemplo, a chamadas a 169.254.169.254 en AWS ou metadata.google.internal en GCP aparecen a miúdo en hóspedes infectados.
  • En consecuencia, Calquera credencial atopada pódese usar inmediatamente para publicar novos paquetes npm ou enviar fluxos de traballo de GitHub.

Exfiltración

  • O verme crea un novo repositorio de GitHub chamado Shai Hulud e escribe unha codificación dobre en base64 data.json con detalles da plataforma, volcados do entorno e segredos. Como se pode ver, este comportamento ruidoso é doado de detectar se os defensores saben onde buscar.
  • Tamén planta un fluxo de traballo de Accións de GitHub, a miúdo nunha rama chamada shai-hulud, que serializa ${{ toJSON(secrets) }} e publica os datos nun webhook estático. Ademais, este fluxo de traballo persiste ata que alguén o elimina activamente.

Propagación

  • Con calquera token npm descuberto, a carga útil enumera todos os paquetes propiedade do responsable do mantemento comprometido. Despois, obtén cada tarball, inxecta bundle.js e unha entrada de postinstalación e volve publicar o paquete.
  • Como resultado, poden aparecer ducias de paquetes infectados en cuestión de horas, multiplicando o radio da explosión en todo o ecosistema.

Persistencia e exposición

  • O verme mantén vivos os fluxos de traballo maliciosos e, en varios casos, converte os repositorios privados en públicos cun "-migración" sufixo. En conxunto, isto garante que o atacante manteña un punto de apoio e maximice a fuga de datos.

Nota de detección clave
Este uso inusual de ${{ toJSON(secrets) }} nos fluxos de traballo de Accións é pouco frecuente. Polo tanto, Os equipos deberían tratalo como un indicador de sinal alto durante as cacerías.

Patrón de fluxo de traballo saneado que debes buscar

Este uso inusual de a JSON(segredos) en Accións é un indicador de sinal alto neste incidente.

Pseudocódigo de propagación de alto nivel (seguro, descritivo)

Os analistas observaron este bucle a escala, o que explica o rápido salto de ducias a centos de paquetes infectados.

Por que isto é un verme nun ecosistema de paquetes

Un verme é un software malicioso que se propaga por si só sen requirir pasos manuais do operador en cada etapa. Nos sistemas operativos, os vermes adoitan aproveitar as vulnerabilidades da rede para moverse dunha máquina a outra. Pola contra, Shai-Hulud opera dentro do rexistro npm. A súa ruta eficiente é a través de reutilización de credenciais.

O verme aproveita os tokens de publicación npm roubados. En canto obtén credenciais válidas, volve publicar as versións infectadas noutros paquetes propiedade do mesmo responsable do mantemento. Posteriormente, eses paquetes son instalados por desenvolvedores ou executantes de CI desprevenidos, e o ciclo repítese.

Por este motivo, os analistas de seguridade, incluídos Lectura escura, clasifican a Shai-Hulud como unha verme autorreplicante en lugar dun simple troiano ou un incidente de typosquatting. A diferenza é importante: un troiano normalmente compromete un hóspede, pero un verme amplifica o seu impacto automaticamente en todo un ecosistema.

Folla informativa "Como funciona"

Para resumir o ciclo de vida de Shai-Hulud, aquí tes unha desvantaxe.cisdesglose dos seus pasos principais:

  • Un paquete con postinstalación está instalado, e bundle.js executa.
  • A carga útil descarga variables de ambiente, analiza ficheiros e o historial de git, execútase TruffleHoge consulta os servizos de metadatos na nube. En consecuencia, calquera segredo atopado vólvese inmediatamente útil.
  • A afiltración ocorre de dúas maneiras: primeiro, creando un repositorio público chamado Shai Hulud cunha dobre codificación base64 data.json; segundo, plantando un fluxo de traballo de Accións de GitHub que publique ${{ toJSON(secrets) }} a un webhook.
  • Usando calquera token npm roubado, o verme republica todos os demais paquetes propiedade do responsable do mantemento comprometido co mesmo gancho malicioso. Deste xeito, a infección multiplícase rapidamente.
  • Finalmente, o atacante ten máis segredos, máis paquetes para espallar e persistencia dentro de contas e repositorios de GitHub.

Como evitar este tipo de ataque, na práctica

Shai-Hulud é unha chamada de atención. Un verme que rouba tokens e se republica a si mesmo non é un risco futuro, está vivo no ecosistema de paquetes npm hoxe. Para evitar este tipo de ataque á cadea de subministración, os equipos precisan controis que sexan programables, automatizados e aplicados directamente CI/CD pipelines. Estas son as mesmas defensas que xa podes implementar con Xíxeno.

Detén os artefactos malos na porta

Deberías analizar os paquetes e os ficheiros tar de npm antes de que cheguen aos desenvolvedores ou ás tarefas de CI. bundle.js ficheiros, posinstalación sospeitosa hookse os marcadores de ofuscación serven como sinais de alerta temperás. Ademais, aplicar períodos de reflexión e versións fixadas en pipelines impide que se consuman automaticamente versións recentes e non verificadas.

Harden CI/CD por defecto

Guardrails in CI/CD son esenciais. Rexeitan as fusións ou instalacións que introducen novos scripts ou binarios. Ao mesmo tempo, bloquean os fluxos de traballo que serializan segredos ou tentan publicacións externas. Os equipos tamén deberían esixir instalacións só de ficheiro de bloqueo (npm ci) en todo pipelinepara que os conxuntos de dependencias sexan reproducibles e seguros.

Reducir o radio da explosión da ficha

Os segredos non deben converterse en puntos únicos de fallo. Analice continuamente o código, as configuracións e pipeline saída para credenciais expostasOs tokens deberían ter un ámbito estrito, dadas as súas duracións curtas, e rotarse automaticamente cando se detecta a exposición. Como regra xeral, calquera token usado nun host que executou unha posinstalación sospeitosa debe tratarse como comprometido.

Observar o comportamento dos vermes cedo

Detección de anomalías é fundamental. Por exemplo, os picos repentinos nos eventos de publicación de npm, os novos fluxos de traballo que aparecen sen motivo ou os repositorios públicos recentes cheos de ficheiros codificados estraños poden indicar a actividade dos vermes. Polo tanto, os equipos deben activar alertas rapidamente e illar a calquera persoa que realice mantemento ou execute que mostre estes sinais de advertencia.

Corrixir rapidamente sen romper as compilacións

Velocidade e seguridade deben ir xuntas. Automatizado pull requests pode substituír os paquetes npm comprometidos por versións verificadas. Ademais, accesibilidade explotabilidade A análise garante que as actualizacións sexan mínimas e estables. Finalmente, reconstruír os executantes de CI afectados a partir de imaxes limpas unha vez confirmada a exposición, evitando que o ataque se propague aínda máis.

Indicadores de Compromiso (IOC)

Ao analizar Shai-Hulud, os equipos deben ter en conta ambos IoC estáticos en ficheiros e IoCs de comportamento in pipelines. Conxuntamente, estes sinais axudan a detectar infeccións cedo e a responder antes de que o verme se propague máis.

IoC estáticos

Observáronse as seguintes coincidencias de resumos SHA-256 bundle.js mostras:

  • 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
  • 81d2a004a1bca6ef87a1caf7d0e0b355ad1764238e40ff6d1b1cb77ad4f595c3
  • dc67467a39b70d1cd4c1f7f7a459b35058163592f4a9e8fb4dffcbba98ef210c

Ademais, observe estes patróns recorrentes:

  • A bundle.js na raíz do paquete.
  • "postinstall": "node bundle.js" dentro package.json.
  • Repositorios nomeados Shai Hulud.
  • Fluxos de traballo de GitHub que conteñen ${{ toJSON(secrets) }}.

IoCs de comportamento

Máis alá das sinaturas de ficheiros, a actividade dos vermes revélase a través do comportamento. Por exemplo:

  • Ráfagas repentinas de eventos de publicación de npm por parte dun responsable de mantemento.
  • Novos fluxos de traballo que envían datos a puntos finais externos.
  • Solicitudes POST de saída activadas por ejecutores de CI.
  • Repositorios públicos creados recentemente con blobs codificados.

Caza rápida

Conclusión: Leccións de Shai-Hulud

o Ataque á cadea de subministración de Shai-Hulud nos paquetes npm móstrase o fráxil que se volveu a cadea de subministración de software actual. Este verme fixo algo máis que engadir código malicioso. Roubou tokens, enviou datos e logo volveu publicarse automaticamente. Debido a isto, o ataque estendeuse en horas en lugar de semanas.

Para os desenvolvedores e os equipos de DevOps, as leccións son claras:

  • Cada instalación executa código. Mesmo un paquete npm común pode ocultar un verme de postinstalación.
  • Cada token ten un alto valor. Unha vez roubado, pódese usar para propagar aínda máis software malicioso.
  • cada pipeline precisa cheques. Sen guardrails en dependencias, fluxos de traballo e segredos, un compromiso pode afectar rapidamente á produción.

Polo tanto, deter ataques como o de Shai-Hulud require controis automáticos e fáciles de aplicar. Os equipos deberían analizar os paquetes npm antes das instalacións, usar compilacións de ficheiros de bloqueo, detectar actividades de publicación estrañas e manter os tokens de curta duración. Estes pasos xa non son opcionais. En cambio, son a base da resiliencia nos sistemas modernos. pipelines.

En Xygeni, vemos o ataque á cadea de subministración de Shai-Hulud como un aviso para todo o ecosistema de código aberto. O camiño sostible a seguir é incorporar a seguridade da cadea de subministración directamente ao proceso de desenvolvemento, no punto no que o código, os paquetes npm e... pipelineconectarse.

A continuación móstrase a lista completa de paquetes e versións de npm que Shai-Hulud informou de que están comprometidas. Úsaa para comprobar os teus ficheiros de bloqueo, rexistros e CI. pipelines para a exposición.

Lista de paquetes comprometidos

📦 Vista previa dos paquetes npm comprometidos

Nome do paquete versión Data de publicación
motor de regras json simplificado0.2.12025-09-14T17:58:51.203Z
piloto aéreo0.8.82025-09-14T18:35:07.600Z
gráfico de coñecemento mcp1.2.12025-09-14T18:35:09.494Z
bufanda de aire0.3.12025-09-14T18:35:09.521Z
porta de salto0.0.22025-09-14T18:35:09.651Z
tvi-cli0.1.52025-09-14T18:35:10.996Z
@thangved/xanela-de-devolución-de-chamada1.1.42025-09-14T20:31:38.479Z
@tnf-dev/api1.0.82025-09-14T20:31:39.547Z
@tnf-dev/js1.0.82025-09-14T20:31:41.251Z
@tnf-dev/mui1.0.82025-09-14T20:31:41.259Z
@tnf-dev/core1.0.82025-09-14T20:31:42.728Z
@teselagen/react-table6.10.202025-09-14T20:37:08.597Z
@hestjs/demo0.1.22025-09-14T20:45:52.348Z
@nexe/eslint-config0.1.12025-09-14T20:45:53.625Z
@hestjs/eslint-config0.1.22025-09-14T20:45:55.044Z
@nexe/xestor-de-configuración0.1.12025-09-14T20:45:55.066Z
@nexe/rexistrador0.1.32025-09-14T20:45:55.170Z
@hestjs/rexistrador0.1.62025-09-14T20:45:55.197Z
@hestjs/validación0.1.62025-09-14T20:45:55.595Z
@hestjs/núcleo0.2.12025-09-14T20:45:55.888Z
➡️ Ver a lista completa de paquetes comprometidos
Nome do paquete versión Data de publicación
motor de regras json simplificado0.2.12025-09-14T17:58:51.203Z
piloto aéreo0.8.82025-09-14T18:35:07.600Z
gráfico de coñecemento mcp1.2.12025-09-14T18:35:09.494Z
bufanda de aire0.3.12025-09-14T18:35:09.521Z
porta de salto0.0.22025-09-14T18:35:09.651Z
tvi-cli0.1.52025-09-14T18:35:10.996Z
@thangved/xanela-de-devolución-de-chamada1.1.42025-09-14T20:31:38.479Z
@tnf-dev/api1.0.82025-09-14T20:31:39.547Z
@tnf-dev/js1.0.82025-09-14T20:31:41.251Z
@tnf-dev/mui1.0.82025-09-14T20:31:41.259Z
@tnf-dev/core1.0.82025-09-14T20:31:42.728Z
@teselagen/react-table6.10.202025-09-14T20:37:08.597Z
@hestjs/demo0.1.22025-09-14T20:45:52.348Z
@nexe/eslint-config0.1.12025-09-14T20:45:53.625Z
@hestjs/eslint-config0.1.22025-09-14T20:45:55.044Z
@nexe/xestor-de-configuración0.1.12025-09-14T20:45:55.066Z
@nexe/rexistrador0.1.32025-09-14T20:45:55.170Z
@hestjs/rexistrador0.1.62025-09-14T20:45:55.197Z
@hestjs/validación0.1.62025-09-14T20:45:55.595Z
@hestjs/núcleo0.2.12025-09-14T20:45:55.888Z
@hestjs/cqrs0.1.62025-09-14T20:45:55.966Z
@hestjs/escalar0.1.72025-09-14T20:45:56.386Z
carga-de-ficheiros-ng27.0.32025-09-15T02:44:29.555Z
xestor de notificacións de condensadores0.0.22025-09-15T04:54:48.431Z
condensador-plugin-vonage1.0.22025-09-15T04:54:48.501Z
complemento-de-condensador-aplicación-de-saúde0.0.22025-09-15T04:54:48.704Z
permisos de androide para condensadores0.0.42025-09-15T04:54:48.753Z
kit de chamadas VoIP1.0.22025-09-15T04:54:49.223Z
complemento-de-condensador-ihealth1.1.82025-09-15T04:55:08.113Z
@art-ws/común2.0.222025-09-15T05:21:15.411Z
@art-ws/config-eslint2.0.42025-09-15T05:21:17.199Z
ngx-ws1.1.52025-09-15T05:21:17.514Z
@art-ws/slf2.0.152025-09-15T05:21:17.524Z
@art-ws/servidor-http2.0.212025-09-15T05:21:17.745Z
pm2-gelf-json1.0.42025-09-15T05:21:18.413Z
@art-ws/di2.0.282025-09-15T05:21:18.488Z
@art-ws/di-node2.0.132025-09-15T05:21:18.849Z
@art-ws/config-ts2.0.72025-09-15T05:21:19.408Z
@art-ws/contexto-da-base2.0.212025-09-15T05:21:19.814Z
@art-ws/openapi0.1.92025-09-15T05:21:19.969Z
@art-ws/aplicación-web1.0.32025-09-15T05:21:20.383Z
@art-ws/ssl-info1.0.92025-09-15T05:21:20.927Z
ferramentas-sca-tools-software-ferramentas-de-análise-de-composición
Priorizar, corrixir e protexer os riscos do software
Obtén a túa conta gratuíta.
Non se precisa tarxeta de crédito.

Asegura o desenvolvemento e a entrega do teu software

con Xygeni Product Suite