Um pacote malicioso foi instalado: contenha a execução antes de substituir credenciais

Objetivo

Situação em 25 de outubro de 2026. Conter a execução de pacotes maliciosos e recuperar as identidades e os artefatos que ela possa ter afetado. Este protocolo proposto usa a documentação de resposta do GitHub e do npm, o aviso do Tensorlake publicado em 8 de outubro e o registro do LiteLLM no OSV modificado em 21 de outubro, às 22:01:01 UTC. Consulte novamente os alertas específicos do pacote e os indicadores revisados antes de agir.

Pré-requisitos

Uma máquina limpa para administração; autoridade para isolar os sistemas afetados e suspender lançamentos; acesso aos controles do registro de pacotes, dos repositórios e dos emissores de credenciais; e armazenamento protegido para evidências. Designe um responsável pelo incidente e registre as ações em UTC. Use ferramentas confiáveis para examinar arquivos suspeitos sem executar seus hooks de instalação, o código de inicialização do interpretador ou as tarefas do projeto.

Passos

1. Contenha a execução e a distribuição. Isole as estações de trabalho e os runners afetados, cancele os jobs envolvidos e suspenda a publicação. Antes da limpeza, preserve os logs disponíveis, os metadados dos pacotes, os arquivos de lock, os digests dos artefatos e as evidências relevantes do sistema de arquivos. Use controles administrativos externos ao ambiente suspeito. Não coloque credenciais substitutas em uma máquina que ainda esteja sob investigação.
2. Verifique imediatamente se há persistência destrutiva. O Tensorlake 0.5.144 exige desativar gh-token-monitor antes de revogar tokens do GitHub. A instrução para Linux começa com systemctl --user disable --now gh-token-monitor.service, executado na sessão do usuário afetado; conclua a limpeza específica da plataforma descrita no aviso. Se não for possível assegurar a contenção, desligue a máquina afetada e examine seu armazenamento offline antes de prosseguir. No LiteLLM 1.107.0, a inicialização do Python pode executar os arquivos maliciosos: não inicie Python nem pip para investigar esse ambiente.
3. Revogue as credenciais expostas a partir da máquina limpa. Priorize o acesso de publicação e de escrita em repositórios e depois trate todos os demais segredos e sessões acessíveis junto ao emissor correspondente. Para npm, execute npm token list, identifique o ID do token afetado e use npm token delete TOKEN_ID, substituindo o marcador por esse ID. Liste os tokens novamente. A documentação do npm informa que a revogação pode demorar, portanto mantenha a contenção enquanto verifica o estado junto ao emissor. Emita substitutos apenas para consumidores já recuperados.
4. Mapeie toda a exposição. Registre cada máquina afetada, o horário da instalação, as identidades acessíveis e os artefatos produzidos depois. O guia de resposta do GitHub recomenda inventariar workflows e credenciais afetados e reavaliar a contenção quando surgirem novas evidências. Examine os caches de CI e do registro de pacotes como possíveis fontes de reinstalações posteriores.
5. Examine o acesso e a persistência. Revise alterações em workflows, aprovações de lançamentos, novos runners e executáveis desconhecidos. As orientações do GitHub para contas também recomendam revisar chaves de implantação, chaves SSH, autorizações de aplicações, webhooks, colaboradores e commits recentes. Compare os resultados com o estado aprovado antes do incidente. Revise as publicações feitas com identidades de publicação expostas e coordene com o registro a retirada de artefatos confirmados como maliciosos.
6. Recrie e verifique. Substitua os ambientes afetados usando imagens confiáveis, código-fonte revisado e um conjunto aprovado de dependências; não reutilize caches ou executáveis suspeitos. Registre as identidades dos artefatos substitutos e teste a aplicação. Confirme a revogação das credenciais e os acessos autorizados e então retome o serviço por etapas, acompanhando os logs de repositório, publicação, acesso à nuvem e endpoints.

Resultado esperado

O registro do incidente associa cada identidade exposta e cada artefato afetado a uma ação de contenção e a uma verificação de recuperação. A publicação é retomada a partir de um ambiente aprovado, com credenciais de escopo limitado. Um responsável continua encarregado de analisar atividades suspeitas posteriores e qualquer exposição ainda não resolvida.

Limites e base de verificação

Esta é uma proposta de resposta baseada em fontes, não um exercício de recuperação testado. A ausência de indicadores não comprova que não houve roubo ou execução secundária. A remoção do pacote, por si só, não restabelece a confiança. As precauções contra persistência destrutiva são específicas de cada incidente; siga as instruções atuais do fornecedor enquanto mantém a contenção urgente por meio de controles administrativos em ambientes limpos.