Resumo Executivo

Em 9 de setembro de 2026, alguém utilizou a conta de mantenedor de um pacote npm legítimo, @dforge-core/dforge-mcp, por 105 minutos. O invasor já tinha permissão para realizar push na ramificação principal quando a intrusão começou; como essa permissão foi obtida é a única coisa que não podemos responder definitivamente por enquanto. No entanto, suspeitamos que tenha sido um desenvolvedor infectado por uma extensão ou pacote malicioso que permitiu esse nível de acesso aos atacantes. Dentro do breve período em que o agente da ameaça teve acesso às credenciais do desenvolvedor, ele adicionou um carregador de código remoto, alterou três linhas para que qualquer push na ramificação principal iniciasse o fluxo de trabalho de lançamento, reescreveu esse fluxo de trabalho quatorze minutos depois para que pudesse ser publicado sem supervisão e enviou o carregador como versão 0.2.21. Foi o lançamento mais recente do registro por 35 minutos e 38 segundos antes que o mantenedor revertesse tudo e publicasse uma versão 0.2.22 limpa. 

Existem três observações interessantes sobre o ataque que se desenrolou. Primeiro, o lançamento comprometido possuía procedência npm válida: foi criado pelo GitHub Actions por meio de publicação confiável OIDC, e seu atestado ainda existe no log de anexação do Sigstore, nomeando o próprio commit do atacante. Nada foi falsificado e nada falhou; o atestado é um registro preciso de uma entrada desonesta, porque a procedência atesta onde um artefato foi criado, não se sua origem era honesta. Isso também explica por que nenhuma credencial npm foi necessária: sob a publicação confiável, o registro confia na identidade de CI do repositório, portanto, o acesso de push era acesso de publicação. Segundo, o payload é uma linha na posição 3320 de um arquivo de 99 KB, abrindo uma cadeia de quatro estágios cujo implante final se exclui do disco no momento em que é executado. Uma organização que executou o lançamento e depois pesquisou em suas máquinas por um arquivo malicioso não encontraria nada e poderia razoavelmente concluir que não foi afetada. Todos os estágios ainda respondiam quando testados cinco dias após a retirada.

Terceiro, e descoberto tardiamente, uma segunda família de payload no repositório de outra vítima vincula isso a uma campanha documentada: PolinRider, uma operação ligada à RPDC que a OpenSourceMalware rastreia em milhares de repositórios desde março de 2026, cuja assinatura é exatamente esta: um payload anexado silenciosamente ao final de um arquivo de configuração de projeto real. Ele não carrega nenhum endereço de comando e controle. Ele lê um endereço da blockchain Ethereum a partir de uma carteira publicada como um indicador para essa campanha. Uma correspondência exata ainda estava emitindo sinais quando este relatório foi escrito. Neste caso, a configuração é escrita nos vinte bytes de um endereço de destinatário em uma transação vazia que custa cerca de vinte centavos, o que significa que o canal não tem domínio para suspender, nenhum host para apreender e nenhuma conta para desativar. A participação na campanha é uma descoberta deste próprio relatório, estabelecida a partir da amostra. Os pesquisadores que documentaram o NullReceiver o atribuem ainda mais à Coreia do Norte; esse passo é deles, não nosso, é citado aqui em vez de afirmado, e a única verificação independente que pudemos realizar não o confirmou.

O método documentado da campanha, que consiste em coletar as credenciais git armazenadas em cache de um desenvolvedor a partir de uma máquina infectada e, em seguida, realizar o push com elas, também é a explicação mais plausível de como a conta deste mantenedor foi usada, e explica por que o mesmo nome emprestado aparece em dezenas de repositórios não relacionados. As ações imediatas são bloquear o endpoint do socket e os dois nomes de host de entrega, procurar pelos artefatos que a cadeia deixa para trás em vez de procurar pelo implante, que se exclui na inicialização, e fixar o pacote na versão 0.2.22. A população exposta é pequena, e nada aqui evidencia um comprometimento bem-sucedido de qualquer organização. O que evidencia é que a remediação que todos realizaram — retirar uma versão que removeu o componente mais barato da operação e deixou o restante acessível — foi feita sem nenhum aviso no OSV, no banco de dados do GitHub ou por parte do mantenedor para informar a qualquer pessoa que ainda estivesse usando a 0.2.21 que ela deveria verificar.

Clique aqui para baixar o relatório completo com a linha do tempo detalhada do ataque, análise de malware, infraestrutura da campanha, avaliação de atribuição, indicadores de comprometimento e recomendações defensivas.