A campanha usa hooks postinstall, tokens npm roubados e infraestrutura em webhook HTTPS e ICP canister para transformar ambientes de desenvolvimento comprometidos em novos pontos de publicação maliciosa.
| Componente | Pacotes npm comprometidos, lógica de propagação para PyPI, ambientes de desenvolvimento com tokens de publicação e segredos locais. |
| Vetor | Execução durante instalação por hook postinstall, seguida de roubo de tokens npm e publicação de novas versões envenenadas no registro. |
| Impacto | Coleta de credenciais, segredos, dados de navegadores Chromium, artefatos de extensões de carteira de criptomoedas e possível ampliação automática para novos pacotes quando tokens válidos são encontrados. |
| Prioridade | Revogar tokens de publicação expostos, auditar versões recentes de pacotes instalados, bloquear destinos de exfiltração conhecidos e revisar pipelines que instalam dependências com scripts habilitados. |
| Artefatos | Webhook telemetry.api-monitor[.]com, ICP canister cjn37-uyaaa-aaaac-qgnva-cai.raw.icp0[.]io, hooks postinstall, payload Python baseado em .pth e uso condicionado de Twine quando credenciais estão presentes. |
| Pacotes relacionados | kube-health-tools, kube-node-health, xinference nas versões 2.6.0, 2.6.1 e 2.6.2, além de pacotes npm associados a um exercício interno de red team da Asurion. |
Uma campanha de cadeia de suprimentos contra o ecossistema npm foi observada usando um worm autopropagável voltado a ambientes de desenvolvimento. O malware é acionado no momento da instalação por meio de um hook postinstall, ponto de execução sensível porque roda no contexto do usuário ou do processo de build que está instalando a dependência. A partir desse ponto, a cadeia tenta coletar credenciais e segredos locais, incluindo tokens npm capazes de publicar novas versões de pacotes. Quando um token válido é encontrado, a operação deixa de ser apenas roubo de credenciais e passa a ter capacidade de propagação: o operador ou a automação pode empurrar versões envenenadas para o registro, adicionando um novo hook malicioso e ampliando a superfície de vítimas para quem instalar a versão comprometida depois disso.
A atividade foi rastreada como CanisterSprawl por causa do uso de um ICP canister como um dos canais de exfiltração. O desenho lembra técnicas já observadas em campanhas que procuram tornar a infraestrutura mais resistente a remoções, distribuindo a coleta de dados entre um webhook HTTPS e um recurso hospedado na rede ICP. Os destinos mencionados no contexto são telemetry.api-monitor[.]com e cjn37-uyaaa-aaaac-qgnva-cai.raw.icp0[.]io. A presença de mais de um canal de saída aumenta a importância de correlacionar eventos de instalação de pacotes, criação de processos e conexões de rede incomuns em estáções de desenvolvedores, runners de CI/CD e hosts usados para publicação de bibliotecas.
O mesmo conjunto de descobertas descreve uma expansão de foco para PyPI. A lógica de propagação em Python gera um payload baseado em .pth, mecanismo que pode fazer código ser executado quando o interpretador Python inicia, e prepara pacotes maliciosos para upload com Twine se credenciais compatíveis estiverem disponíveis. Esse ponto é relevante para equipes que tratam npm e PyPI como riscos separados: um único ambiente de desenvolvimento com múltiplos tokens pode servir como ponte entre registros, linguagens e pipelines distintos. A campanha, portanto, deve ser analisada como comprometimento de identidade de publicação e não apenas como dependência maliciosa isolada.
O fluxo começa quando uma dependência comprometida é instalada em um ambiente onde scripts de instalação são permitidos. O hook postinstall executa a lógica maliciosa sem exigir que o pacote seja importado pela aplicação final, o que torna está etapa especialmente perigosa em máquinas de desenvolvimento, jobs automatizados e ambientes que constroem artefatos a partir de manifests atualizados. Depois da execução inicial, o código tenta localizar tokens npm e outros segredos úteis para publicação, automação e acesso a serviços. O objetivo operacional é transformar a máquina comprometida em uma fonte de novos pacotes envenenados, explorando a confiança atribuída ao mantenedor ou ao pipeline que possui permissão de publicação.
Além de tokens de registro, a cadeia tenta acessar credenciais em navegadores baseados em Chromium e dados associados a extensões de carteiras de criptomoedas. O contexto não estabelece todos os tipos de artefato extraídos, mas confirma a busca por credenciais, segredos e dados de extensões. A exfiltração usa um webhook HTTPS defangado como telemetry.api-monitor[.]com e um ICP canister defangado como cjn37-uyaaa-aaaac-qgnva-cai.raw.icp0[.]io. Para defesa, a presença desses destinos deve ser tratada como indicador de comprometimento quando correlacionada com execução de scripts de pacote, alterações em diretórios de cache de dependências, instalação recente de versões suspeitas ou publicação inesperada de pacote a partir de contas legítimas.
A lógica descrita para PyPI amplia o risco porque usa um mecanismo de inicialização do Python, por meio de arquivo .pth, para obter execução em momentos posteriores. A preparação e o envio de pacotes com Twine dependem da presença de credenciais, portanto esse estágio é condicionado ao ambiente infectado possuir material de autenticação válido. O impacto defensivo é claro: tokens de publicação armazenados em estáções locais, variáveis de ambiente persistentes, arquivos de configuração de registries e segredos disponíveis em runners passam a ser ativos de alto risco. A simples remoção do pacote comprometido não é suficiente se o token já foi usado para publicar uma versão maliciosa ou se segredos foram copiados para fora do ambiente.
A superfície principal envolve projetos JavaScript que instalam pacotes npm com scripts habilitados e ambientes em que o usuário ou o pipeline tem permissão para publicar pacotes. Isso inclui máquinas de mantenedores, runners de integração contínua, pipelines de release, workstations com múltiplos registries configurados e repositórios que automatizam versionamento e publicação. O risco aumenta quando tokens npm de longa duração ficam acessíveis em variáveis de ambiente, arquivos de configuração locais ou sistemas de CI/CD que executam dependências de terceiros antes de isolar o estágio de publicação.
O contexto também registra outros incidentes próximos no ecossistema de código aberto. Versões 2.6.0, 2.6.1 e 2.6.2 do pacote Python legítimo xinference foram descritas como comprometidas com payload codificado que busca um coletor de segunda etapa para credenciais e segredos. O payload decodificado continha o marcador # hacked by teampcp, mas a atribuição é limitada porque houve contestação pública associando o caso a um imitador. Essa distinção importa para inteligência de ameaças: o marcador é um artefato técnico observável, não uma confirmação suficiente de autoria.
Também foram citados pacotes kube-health-tools no npm e kube-node-health no PyPI, apresentados como utilitários de Kubernetes, mas com instalação silenciosa de um binário Go que estabelece proxy SOCKS5, proxy reverso, servidor SFTP e um proxy de modelo de linguagem compatível com APIs do tipo OpenAI. Esse componente de LLM fica em uma fronteira de confiança sensível, pois as requisições passam pelo roteador em texto claro. O risco defensivo inclui exposição de chaves de API, credenciais de nuvem, tokens de GitHub, chaves privadas de Ethereum e prompts de sistema quando esse roteador é colocado entre clientes e APIs de modelo.
Outro caso relatado envolveu pacotes npm com nomes ligados à Asurion e subsidiárias, publicados entre 1º e 8 de abril de 2026, com um coletor de credenciais em múltiplos estágios. A resposta posterior da empresa informou que aqueles pacotes faziam parte de um exercício interno controlado de red team e que não houve comprometimento ou impacto a sistemas ou clientes. Esse ponto deve ser tratado separadamente dos pacotes maliciosos confirmados, porque o próprio contexto limita o caso a uma atividade autorizada e não a uma campanha criminosa.
- Ambientes npm que permitem execução automática de hooks
postinstalldurante instalação de dependências. - Contas de mantenedores ou pipelines com tokens npm válidos para publicação de novas versões.
- Ambientes Python com credenciais PyPI e uso de
Twine, quando expostos ao payload baseado em.pth. - Estáções com navegadores Chromium, extensões de carteira de criptomoedas e segredos de nuvem ou repositórios acessíveis ao usuário.
A investigação deve partir da linha do tempo de instalação de dependências e publicação de pacotes. Em npm, eventos relevantes incluem instalação de versões recém-publicadas, execução de scripts postinstall, processos filhos criados durante instalação, leitura de arquivos de configuração de registries e conexões de saída logo após a resolução de dependências. Em CI/CD, a telemetria deve separar jobs que apenas constroem e testam de jobs que têm credenciais de publicação. Qualquer execução de dependência de terceiros em estágio com token de release aumenta a possibilidade de propagação caso o pacote esteja comprometido.
Na camada de rede, os destinos defangados telemetry.api-monitor[.]com e cjn37-uyaaa-aaaac-qgnva-cai.raw.icp0[.]io devem ser procurados em logs de proxy, DNS, EDR e firewall, sempre correlacionados com eventos de instalação ou build. A ausência desses domínios não encerra a investigação, porque a infraestrutura pode variar ou ser obfuscada em novas versões. Para endpoints de desenvolvedores, sinais adicionais incluem acesso incomum a perfis Chromium, diretórios de extensões de carteira, arquivos de configuração de npm e PyPI, variáveis de ambiente com segredos e ferramentas de publicação chamadas fora dos fluxos normais.
Para PyPI, a caça deve observar criação ou modificação inesperada de arquivos .pth, execução do Python logo após instalação de pacotes, presença de artefatos de empacotamento não planejados e uso de Twine em máquinas que não deveriam publicar bibliotecas. Em organizações com múltiplas linguagens, a análise precisa atravessar fronteiras de ecossistema: um projeto JavaScript comprometido pode expor credenciais Python se ambas estiverem no mesmo host. Esse padrão é especialmente importante em estáções de mantenedores que concentram tokens pessoais e em runners reutilizados entre pipelines.
O contexto também menciona exploração sistemática do gatilho pull_request_target no GitHub Actions desde 11 de março de 2026, com contas como testedbefore, beforetested-boop, 420tb, 69tf420, elzotebo e ezmtebo. O fluxo descrito envolve busca por repositórios que usam esse gatilho, fork, criação de ramo com padrão prt-scan-{12-hex-chars}, alteração de arquivo executado no CI, abertura de pull request e roubo de credenciais quando o workflow é acionado. A publicação de versão maliciosa ocorre de forma condicionada à descoberta de tokens npm. A defesa deve revisar execuções de pull_request_target, aprovações de contribuidores, exposição de segredos em workflows e publicações npm subsequentes a pull requests de contas desconhecidas.
- Execução de
postinstallseguida de conexões HTTPS para domínios raros ou ICP canisters. - Publicação npm não planejada por conta legítima logo após instalação ou build em ambiente de desenvolvimento.
- Leitura de perfis Chromium, diretórios de extensões de carteira e arquivos de configuração de registries por processos de instalação.
- Criação ou alteração inesperada de arquivos
.pthe uso deTwineem hosts sem função de release. - Workflows
pull_request_targetacionados por pull requests externos com ramos no padrãoprt-scan-{12-hex-chars}.
A resposta deve começar pela contenção de identidade. Tokens npm e PyPI presentes em máquinas ou pipelines que instalaram pacotes suspeitos devem ser revogados e recriados com escopo mínimo. Tokens de longa duração, permissões amplas e credenciais compartilhadas entre projetos aumentam o raio de impacto, portanto a revisão precisa incluir contas pessoais de mantenedores e segredos armazenados em CI/CD. Depois da rotação, é necessário auditar publicações recentes para identificar versões que possam ter sido empurradas por credenciais roubadas, remover versões comprometidas quando aplicável e comunicar consumidores que instalaram artefatos afetados.
A mitigação técnica deve reduzir a execução automática de código durante instalação sempre que o fluxo permitir. Builds que não precisam de scripts de instalação devem desabilitar essa classe de execução ou rodá-la em ambiente isolado, sem segredos de publicação e sem acesso a perfis de usuário. Pipelines de release devem separar estágios de instalação, teste e publicação, expondo tokens apenas no estágio mínimo necessário e depois que a árvore de dependências estiver validada. Em estáções de desenvolvedores, navegadores, carteiras e segredos de nuvem não devem compartilhar o mesmo contexto operacional de processos que instalam dependências não verificadas.
Para GitHub Actions, workflows que usam pull_request_target precisam de revisão específica. Esse gatilho executa em um contexto privilegiado quando mal configurado, e o contexto descreve uma campanha que o explorou em escala para tentar acessar segredos de desenvolvedores. Regras de aprovação de contribuidores, restrição de permissões do GITHUB_TOKEN, bloqueio de acesso a segredos em pull requests externos e revisão manual de alterações que influenciam arquivos executados pelo CI são controles centrais. Repositórios que publicam pacotes npm devem correlacionar qualquer execução desse tipo com publicações subsequentes no registro.
A validação final deve combinar inventário, telemetria e reconstrução de linha do tempo. É necessário saber quais pacotes foram instalados, quais versões foram resolvidas por lockfiles, quais caches foram usados, quais hosts executaram scripts e quais tokens estavam disponíveis naquele momento. Caches de dependências, imagens de build e artefatos temporários podem preservar versões comprometidas mesmo depois da remoção no registro. A limpeza deve incluir invalidação de caches, reconstrução de imagens, revisão de lockfiles e bloqueio de versões afetadas. Em casos com sinais de exfiltração, a organização deve tratar segredos de nuvem, tokens de repositório, chaves de API e credenciais de carteira como potencialmente expostos, com rotação conforme o escopo observado.
- Revogar e recriar tokens npm e PyPI que estiveram presentes em hosts ou pipelines expostos.
- Auditar publicações recentes feitas por contas legítimas e remover versões envenenadas quando confirmadas.
- Separar instalação de dependências e publicação de pacotes em estágios diferentes, com segredos disponíveis somente no estágio de release.
- Bloquear ou monitorar os destinos defangados associados à campanha e correlacionar alertas com instalação de pacotes.
- Revisar workflows
pull_request_target, permissões de token, exigência de aprovação de contribuidores e acesso de pull requests externos a segredos.
0 Comentários