Um worm npm familiar retornou após mais de três meses de silêncio, carregando o mesmo arquivo malicioso vinculado a um incidente anterior de cadeia de suprimentos. O reaparecimento mostra como uma ameaça conhecida pode recuperar o acesso aos ambientes de desenvolvedores quando é republicada dentro de pacotes de software comuns. A atividade mais recente envolveu quatro pacotes carregados em uma hora no dia 7 de setembro. Quando um desenvolvedor instala uma dependência envenenada, o malware pode ser executado antes que o trabalho normal comece, procurar tokens de acesso e usar os direitos de publicação da vítima para se espalhar para pacotes adicionais.
O que mudou agora
Esta é a mesma risco visto em outros relatórios de ataque à cadeia de suprimentos npm, onde uma atualização confiável se torna a porta de entrada inicial. Analistas da Aikido identificaram a carga útil retornante no trabalho de triagem e descobriram que seu valor SHA-256 era idêntico ao arquivo observado durante o ataque de 19 de maio aos pacotes @antv. A Aikido disse em um relatório compartilhado com a Cyber Security News que o resultado foi uma lacuna de 111 dias entre a última visualização conhecida e seu reaparecimento renovado.
Descoberta e escopo
A onda anterior foi substancial: uma conta de mantenedor comprometida enviou 639 versões maliciosas de pacotes @antv em uma hora. Os registros da Aikido contaram 319 versões de pacotes carregando este hash de arquivo, todos detectados pela primeira vez em 19 de maio, antes que quatro novos lançamentos surgissem em 7 de setembro. O novo incidente é menor, mas importa porque o código já havia sido amplamente identificado. Os quatro lançamentos retornantes foram publicados pela mesma conta npm. Sua característica principal não era um implante redesenhado ou componente recém-oculto, mas a reutilização de uma carga útil cuja impressão digital havia sido pública por meses, oferecendo aos atacantes um atalho para fluxos de trabalho de desenvolvimento confiáveis.
Análise técnica detalhada
A distinção é importante. A varredura de malware enfrenta casos difíceis envolvendo etapas ocultas, atividade atrasada ou código que muda por ambiente. Aqui, os analistas disseram que a amostra não foi reembalada ou levemente alterada. Era uma correspondência exata de hash de arquivo, tornando o incidente um teste de detecção de malware conhecido, em vez de um concurso com um método de evasão novel. A carga útil usa uma ação de tempo de instalação para começar a execução. Ela pode validar tokens roubados contra o registro npm, baixar arquivos de pacotes, inserir código, aumentar um número de versão e republicar o lançamento alterado.
Impacto e alcance
Este ciclo automatizado explica por que as infecções de worm em todo o npm podem rapidamente transformar uma conta de desenvolvedor comprometida em um problema mais amplo de cadeia de suprimentos. Sua atividade também se estende além da instalação. O material de origem descreve tentativas de criar arquivos de configuração de projeto que podem deixar um caminho de execução quando um repositório é aberto posteriormente. Também nota a criação em massa de repositórios do GitHub usando nomes relacionados a Dune e referências invertidas de Shai-Hulud, comportamento que pode ajudar os defensores a caçar atividades relacionadas.
Medidas de mitigação recomendadas
O npm introduziu a varredura no momento da publicação em julho, mantendo os pacotes por cerca de cinco a 15 minutos antes que se tornem disponíveis para instalação. O sistema é destinado a parar o malware detectável antes que chegue aos usuários. Este reativamento sugere que uma verificação de registro ainda pode falhar quando deveria reconhecer um artefato malicioso previamente catalogado. As equipes devem revisar se as quatro versões identificadas foram instaladas em estações de trabalho de desenvolvedores, trabalhos de integração contínua ou caches de compilação.
O que os CISOs devem fazer imediatamente
Eles devem girar npm, GitHub, nuvem e outros segredos que podem ter sido expostos, então examinar as publicações recentes de pacotes de contas afetadas. A resposta espelha lições da compromissão do pacote Keyv, onde canais de lançamento válidos amplificaram um ataque de credenciais roubadas. As organizações devem fixar versões de dependência aprovadas, inspecionar scripts de instalação e arquivos de pacote antes da promoção e limitar o escopo e a vida útil dos tokens de publicação. Bloquear scripts de instalação reduz o risco, mas não é uma salvaguarda completa quando o código malicioso usa caminhos de compilação ou configuração de projeto alternativos.
Perguntas frequentes
Por que o scanner não pegou? O hash era conhecido, mas o registro pode ter falhado na verificação de artefato catalogado. Como prevenir? Pin de dependências, inspeção de scripts e limitação de tokens. É um ataque novo? Não, é o mesmo payload de maio, reaproveitado para economizar esforço de ataque.