Mini Shai-Hulud compromete pacotes npm do ecossistema AntV por conta de mantenedor

Versões adulteradas de centenas de pacotes npm coletam credenciais de nuvem, GitHub, npm, SSH, Kubernetes e bancos de dados, com propagação automática por tokens roubados.

Componente	Pacotes npm ligados ao ecossistema @antv e ao mantenedor atool, incluindo echarts-for-react, @antv/g2, @antv/g6, @antv/x6, @antv/l7, @antv/s2, @antv/f2, @antv/g, @antv/g2plot, @antv/graphin, @antv/data-set, timeago.js, size-sensor e canvas-nest.js.
Vetor	Conta de mantenedor comprometida usada para publicar versões trojanizadas no npm, com execução por gancho preinstall e comando bun run index.js; parte das versões também inclui optionalDependencies apontando para commits impostores.
Impacto	Roubo de mais de 20 tipos de credenciais, incluindo AWS, Google Cloud, Microsoft Azure, GitHub, npm, SSH, Kubernetes, Vault, Stripe e strings de conexão de bancos de dados, além de tentativa de escape de contêiner Docker via socket do host.
Prioridade	Identificar instalações das versões envenenadas, bloquear o domínio t.m-kosche[.]com, caçar repositórios com o marcador niagA oG eW ereH :duluH-iahS, rotacionar segredos expostos e fixar dependências em versões limpas.
Versões	A campanha publicou 639 versões maliciosas em 323 pacotes únicos; dentro do namespace @antv, foram 558 versões em 279 pacotes. Outra análise descreveu um surto de publicação em 22 minutos envolvendo 317 pacotes e 637 versões.
Artefatos	Gancho preinstall, comando bun run index.js, uso de optionalDependencies, criação de repositórios públicos no GitHub com arquivo JSON contendo dados exfiltrados e descrição niagA oG eW ereH :duluH-iahS.
IoCs	Domínio de exfiltração t.m-kosche[.]com:443 e repositórios GitHub criados por tokens roubados com a descrição reversa associada a Shai-Hulud: Here We Go Again.
Mitigação	Revogar tokens npm e GitHub, rotacionar chaves de nuvem e credenciais de serviço, auditar ambientes de CI/CD, habilitar autenticação multifator, revisar lockfiles e impedir atualização automática para versões recém-publicadas sem verificação.

Resumo técnico

Uma nova onda da campanha Mini Shai-Hulud atingiu a cadeia de suprimentos do npm ao usar uma conta de mantenedor comprometida para distribuir versões adulteradas de pacotes associados ao ecossistema AntV e a projetos relacionados. O conjunto afetado inclui bibliotecas de visualização de dados, gráficos, mapas, componentes React e utilitários consumidos por aplicações web e pipelines de build. Entre os pacotes citados está echarts-for-react, um wrapper React para Apache ECharts com cerca de 1,1 milhão de downloads semanais, além de pacotes @antv como @antv/g2, @antv/g6, @antv/x6, @antv/l7, @antv/s2, @antv/f2, @antv/g, @antv/g2plot, @antv/graphin e @antv/data-set. Também foram citados pacotes fora do namespace @antv, como timeago.js, size-sensor e canvas-nest.js.

O ataque não depende de exploração de uma vulnerabilidade em tempo de execução da aplicação final. A condição crítica é a instalação de versões publicadas pelo mantenedor comprometido, especialmente em ambientes que aceitam atualizações automáticas ou que não prendem versões por lockfile confiável. Durante a instalação, o pacote adulterado aciona código por meio de preinstall, executando bun run index.js e iniciando coleta de credenciais no ambiente local ou no runner de CI/CD. O payload é voltado a segredos operacionais: tokens de GitHub e npm, chaves de provedores de nuvem, credenciais SSH, dados de Kubernetes, Vault, Stripe e strings de conexão de bancos de dados. A presença desses pacotes em projetos de frontend não limita o impacto ao navegador; o ponto de execução é a máquina ou pipeline que instala dependências.

A escala informada indica automação agressiva. Foram registradas 639 versões maliciosas distribuídas por 323 pacotes únicos, com 558 versões em 279 pacotes @antv. Outra medição descreveu um intervalo de 22 minutos no qual centenas de versões foram publicadas com payload obfuscado semelhante. Esse padrão aponta para uso de token roubado e republicação em massa, não para alteração manual de poucos projetos. Para organizações, o risco principal está na combinação entre popularidade dos pacotes, permissões amplas de tokens presentes em CI/CD e confiança automática em atualizações de dependências obtidas diretamente do registro npm.

Fluxo técnico

O fluxo começa com o controle de uma identidade de publicação npm vinculada ao mantenedor atool. Com essa permissão, o operador consegue publicar novas versões sob nomes legítimos, preservando a aparência normal do pacote no registro. O artefato malicioso adiciona um gancho preinstall, mecanismo executado antes da instalação efetiva da dependência. Esse ponto é particularmente sensível porque roda no contexto do usuário, da estáção de desenvolvimento, do contêiner de build ou do runner de CI/CD que chama npm install, npm ci ou fluxo equivalente. Quando o gancho dispara bun run index.js, o pacote executa o stealer sem exigir que a aplicação importadora chame explicitamente a biblioteca comprometida.

Além do caminho principal via preinstall, 630 de 637 versões analisadas também adicionaram uma entrada optionalDependencies para entregar uma segunda cópia do payload por commits impostores relacionados ao repositório legítimo antvis/G2. Esse desenho aumenta a chance de execução e dificulta uma leitura superficial do pacote, porque parte da cadeia fica escondida em dependências opcionais. A presença de um segundo caminho de entrega também complica a remoção incompleta: eliminar apenas um arquivo ou bloquear apenas o script principal pode deixar outro artefato disponível para execução durante instalação ou resolução de dependências.

Depois de ativo, o malware enumera material sensível no ambiente. A coleta abrange mais de 20 classes de credenciais e configurações, incluindo AWS, Google Cloud, Microsoft Azure, GitHub, npm, SSH, Kubernetes, Vault, Stripe e strings de conexão de bancos de dados. O payload também tenta usar o socket Docker do host para escape de contêiner, uma técnica relevante em runners que montam /var/run/docker.sock para builds, publicação de imagens ou testes. Quando esse socket está acessível, um processo dentro do contêiner pode interagir com o daemon Docker do host e ampliar o alcance para volumes, imagens, contêineres e segredos que não deveriam ser visíveis ao pacote npm.

Os dados coletados são serializados, comprimidos, criptografados e enviados para t.m-kosche[.]com:443. Caso a comunicação direta falhe ou como mecanismo complementar, o payload usa tokens GitHub roubados para criar repositórios públicos na conta da vítima e gravar um arquivo JSON com os dados exfiltrados. Esses repositórios recebem a descrição niagA oG eW ereH :duluH-iahS, que, invertida, corresponde ao marcador operacional da campanha. A existência de mais de 2.500 repositórios com esse marcador indica que muitos ambientes tiveram tokens válidos abusados ao menos para criação de repositório, o que deve ser tratado como evidência de exposição de credenciais e não como simples ruído de automação.

A campanha também incorpora propagação por npm. Quando encontra tokens npm, o código valida o token pela API do registro, enumera pacotes mantidos pelo proprietário, baixa tarballs, injeta o payload, adiciona preinstall, incrementa a versão e republica o pacote com a identidade comprometida. Esse comportamento cria um efeito de multiplicação: um ambiente de build infectado pode expor um token de mantenedor, e esse token permite envenenar outros pacotes confiados por terceiros. A campanha ainda introduz uso de atestação Sigstore em ambientes de CI com OIDC, emitindo certificados legítimos associados ao runner que executou o build. A atestação prova o local técnico de construção do artefato, mas não prova que a publicação foi autorizada pelo mantenedor.

Superfície afetada

A superfície exposta inclui projetos que instalaram versões maliciosas de pacotes @antv e de pacotes correlatos publicados pela conta comprometida. Ambientes com lockfiles ausentes, ranges permissivos em package.json, uso automático de versões mais recentes e pipelines que executam instalação com tokens de publicação ou acesso a provedores de nuvem concentram o maior risco. A exposição não fica restrita a aplicações que usam gráficos ou visualização no frontend; qualquer máquina que resolva e instale a dependência pode executar o gancho de instalação e revelar segredos do ambiente.

Runners de CI/CD merecem atenção especial porque costumam concentrar tokens de GitHub, npm, chaves de nuvem, credenciais de registro de contêiner, acesso a Kubernetes e permissões para publicar artefatos. Em GitHub Actions, GitLab CI, Jenkins, runners autohospedados e pipelines similares, a execução de npm ci dentro de jobs com segredos disponíveis pode transformar uma instalação de dependência em vazamento de credenciais. O risco cresce quando o mesmo job usa credenciais duradouras, permissões amplas de repositório, tokens npm com capacidade de publicação e acesso ao Docker do host.

Desenvolvedores também podem ser afetados em estáções locais, especialmente quando usam perfis de CLI autenticados, arquivos de configuração de nuvem, chaves SSH e tokens salvos em variáveis de ambiente. Mesmo que a aplicação final não seja implantada, a simples execução da instalação em uma máquina com credenciais válidas pode fornecer material suficiente para acesso posterior a repositórios privados, buckets, clusters, registros de pacote e bancos de dados. A presença de pacote popular como echarts-for-react amplia o alcance potencial porque dependências de visualização são comuns em dashboards internos, portais administrativos e produtos SaaS.

A atribuição operacional é mais difícil porque o código-fonte do framework ofensivo foi disponibilizado e já há indícios de pacotes maliciosos copiados usando infraestrutura própria de comando e controle. Isso significa que a presença de técnicas semelhantes não deve ser usada isoladamente para atribuir todos os eventos ao mesmo operador. Para defesa, a distinção mais importante é prática: qualquer ocorrência do padrão Mini Shai-Hulud, clone ou variante deve acionar resposta de incidente centrada em segredos, publicação de pacotes, runners e repositórios criados sem autorização.

• Projetos que instalaram versões trojanizadas de pacotes @antv ou pacotes associados ao mantenedor atool.
• Pipelines que executam npm install ou npm ci com tokens GitHub, npm, nuvem, Kubernetes, Vault, Stripe ou banco de dados disponíveis no ambiente.
• Runners com socket Docker do host montado, especialmente quando /var/run/docker.sock fica acessível ao processo de instalação.
• Repositórios que usam ranges permissivos de dependência sem validação de lockfile, cache de pacote ou revisão de versão recém-publicada.
• Contas GitHub que apresentam repositórios públicos inesperados com a descrição niagA oG eW ereH :duluH-iahS.

Hunting e telemetria

A investigação deve começar pelo inventário de dependências instaladas desde a janela de publicação das versões maliciosas. Procure nos lockfiles por pacotes do ecossistema @antv e pelos pacotes relacionados citados, correlacionando número de versão, horário de resolução e origem do cache. Em ambientes Node.js, artefatos em package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml e caches de gerenciadores de pacote ajudam a confirmar se uma versão comprometida foi baixada. A presença do gancho preinstall com bun run index.js em tarballs ou diretórios de node_modules é um sinal técnico de alto valor.

Nos endpoints e runners, revise execução de processos durante instalação de dependências. Comandos bun, node, npm e shells filhos disparados a partir de scripts de lifecycle devem ser correlacionados com conexões de saída para t.m-kosche[.]com:443, criação de arquivos temporários e leitura de diretórios de configuração. Em CI/CD, logs de job podem mostrar instalação de versões recém-publicadas, execução de scripts de lifecycle e uso de variáveis secretas no mesmo contexto. Mesmo que o payload apague rastros locais, eventos de rede, auditoria de processo e logs do provedor de CI podem preservar a sequência.

No GitHub, a caça deve incluir repositórios criados recentemente por contas de usuário, bots ou tokens de automação. A descrição niagA oG eW ereH :duluH-iahS e commits contendo arquivos JSON inesperados são indicadores diretos de abuso de token. A criação desses repositórios deve ser tratada como evidência de que o token possuía permissão de escrita e foi utilizado por código não autorizado. Também é necessário revisar eventos de API, criação de repositório, pushes, alterações de workflow, emissão de tokens OIDC e permissões de GITHUB_TOKEN em workflows executados durante a janela de risco.

Em nuvem e infraestrutura, a telemetria deve buscar uso anômalo de credenciais logo após instalações de dependência. Para AWS, Google Cloud e Azure, revise chamadas de API feitas por chaves de automação, mudanças em IAM, enumeração de recursos, criação de novos segredos, acesso a storage e tentativas de persistência. Em Kubernetes, investigue leituras de secrets, criação de service accounts, execuções em pods e uso de contextos kubeconfig fora do padrão. Em Vault, Stripe e bancos de dados, correlacione acessos por credenciais de pipeline com horários de build e endereços de origem incomuns.

A verificação de Sigstore e SLSA exige cuidado. Um certificado válido associado a um runner de CI não é prova suficiente de autorização legítima da publicação. Em pacotes afetados por essa campanha, a cadeia pode conter atestação tecnicamente válida porque o próprio ambiente de CI foi usado para emitir OIDC e assinar artefatos. A análise precisa cruzar identidade do runner, origem do workflow, evento que disparou o build, revisão do pacote, diffs no tarball publicado e autorização do mantenedor para aquela versão.

• Entradas preinstall chamando bun run index.js em package.json de pacotes instalados ou tarballs baixados.
• Conexões de saída para t.m-kosche[.]com:443 a partir de estáções de desenvolvimento, runners ou contêineres de build.
• Repositórios GitHub públicos recém-criados com descrição niagA oG eW ereH :duluH-iahS e arquivos JSON inesperados.
• Uso de tokens npm para enumeração de pacotes, download de tarballs, incremento de versão e publicação fora do fluxo normal.
• Emissão de tokens OIDC e atestações Sigstore em jobs que não deveriam publicar pacotes.
• Acesso anômalo a AWS, Google Cloud, Azure, Kubernetes, Vault, Stripe, registros de contêiner e bancos de dados após instalação de dependências.
• Runners com /var/run/docker.sock montado e processos de instalação tentando interagir com o daemon Docker do host.

Mitigação

A resposta deve assumir comprometimento de segredos quando uma versão maliciosa tiver sido instalada em ambiente com credenciais disponíveis. A primeira ação é interromper pipelines que instalam dependências afetadas, preservar logs e artefatos de build, congelar versões por lockfile limpo e remover versões trojanizadas dos caches internos. Em seguida, revise todos os projetos que dependem direta ou transitivamente dos pacotes citados. A simples atualização para uma versão limpa reduz nova execução, mas não resolve o impacto de tokens já exfiltrados.

A rotação de credenciais precisa ser ampla e ordenada. Revogue tokens npm e GitHub usados por mantenedores, bots e pipelines; substitua chaves de AWS, Google Cloud e Azure presentes nos ambientes expostos; renove chaves SSH; invalide tokens de Kubernetes, Vault, Stripe e bancos de dados que estiveram disponíveis durante a execução. Em GitHub, remova repositórios criados sem autorização, revogue tokens pessoais, revise aplicativos OAuth e GitHub Apps, reduza permissões de GITHUB_TOKEN em workflows e force autenticação multifator para contas de publicação e manutenção.

Para reduzir repetição do incidente, aplique controles preventivos na cadeia de dependências. Desabilite scripts de lifecycle durante análise com npm install --ignore-scripts em ambientes de inspeção, use registros proxy com quarentena de versões recém-publicadas, imponha revisão para atualizações de pacotes críticos e bloqueie publicação npm por tokens duradouros quando for possível usar fluxos de curta duração. Lockfiles devem ser tratados como artefatos de segurança: mudanças inesperadas em versões, integridades e origens de pacote precisam passar por revisão antes de entrar em ramos protegidos.

Em CI/CD, separe jobs de build, teste e publicação com segredos mínimos. Instalação de dependências não deve ocorrer no mesmo contexto que possui tokens de publicação npm, acesso administrativo a nuvem ou permissão de escrita ampla em repositórios. Runners autohospedados devem evitar montagem do socket Docker do host em jobs que instalam dependências de terceiros. Quando Docker for necessário, use ambientes isolados, credenciais de curta duração e políticas que impeçam o pacote instalado de alcançar o daemon do host ou diretórios persistentes sensíveis.

A validação final deve combinar análise de dependências, auditoria de identidade e revisão de telemetria. Confirme que não restam versões maliciosas em lockfiles, caches, imagens de contêiner, artefatos de build ou ambientes de desenvolvimento. Verifique se nenhum pacote mantido internamente foi republicado por token comprometido. Reexecute pipelines somente depois de rotacionar segredos, revisar permissões e bloquear indicadores conhecidos. Como clones do worm podem usar infraestrutura diferente, a defesa não deve depender apenas do domínio t.m-kosche[.]com; o comportamento de preinstall, coleta de credenciais, criação de repositórios e republicação automatizada deve permanecer monitorado.

• Inventariar todos os projetos com @antv, echarts-for-react, timeago.js, size-sensor, canvas-nest.js e demais pacotes afetados.
• Comparar lockfiles com versões conhecidas como limpas e remover tarballs comprometidos de caches locais, proxies e imagens de build.
• Revogar e recriar tokens GitHub, npm, nuvem, SSH, Kubernetes, Vault, Stripe e bancos de dados presentes em ambientes que instalaram versões maliciosas.
• Procurar e remover repositórios GitHub criados sem autorização com o marcador niagA oG eW ereH :duluH-iahS.
• Bloquear t.m-kosche[.]com:443 e investigar qualquer tentativa de conexão histórica a esse destino.
• Reduzir permissões de GITHUB_TOKEN, tokens npm e credenciais de CI/CD ao mínimo necessário para cada job.
• Impedir que jobs de instalação de dependências tenham acesso ao socket Docker do host ou a credenciais de publicação.
• Tratar atestações Sigstore e proveniência SLSA como sinais de origem de build, não como confirmação isolada de autorização da versão.