Projetos no GitHub: prove o limite entre abrir e executar
Um projeto de código pode carregar instruções fora dos arquivos que a equipe costuma revisar. A análise da pesquisa da Doctor Web propõe evidências para separar aquisição, abertura e execução autorizada.
Read in EnglishPor Pentesty
A pesquisa descreve caminhos de ativação diferentes
Em pesquisa publicada em 5 de novembro, a Doctor Web descreveu projetos maliciosos no GitHub voltados a usuários de criptomoedas e profissionais de segurança. A análise encontrou conteúdo em arquivos .suo e .csproj de projetos Visual Studio, além de código Python e Go com instruções ocultadas entre espaços. O relato identifica uma rotina PreBuildEvent que executava código antes da compilação e conteúdo PowerShell em arquivos .suo.
Esses achados não demonstram que clonar qualquer repositório ou abrir qualquer solução executa a mesma cadeia. A ativação depende do projeto, da ação realizada e do comportamento do IDE ou da configuração usada. A Doctor Web também descreve um carregador Electron com funções de acesso remoto, alteração de endereços de carteiras e roubo de dados. São achados atribuídos ao fornecedor, não uma nova vulnerabilidade universal do GitHub.
Defina o que cada etapa pode fazer
Antes de aceitar um projeto externo, separe obter arquivos, inspecionar conteúdo, abrir no IDE, restaurar dependências, compilar e depurar. Para cada etapa, registre quem autoriza processos adicionais, acesso à rede e uso de credenciais. Uma escolha de confiança na interface precisa corresponder a uma política conhecida, em vez de servir como autorização implícita para todas as tarefas futuras.
Inclua arquivos de configuração, tarefas de compilação e ações oferecidas por extensões no escopo da revisão. Registre a origem e a revisão exata recebida, junto da versão do IDE e das políticas aplicadas. Isso permite discutir uma sequência observada sem atribuir a todos os desenvolvedores o comportamento de uma configuração específica.
Construa uma prova inofensiva para cada transição
Em uma máquina de laboratório isolada, use um projeto criado pela própria equipe, sem código das amostras maliciosas. Uma tarefa benigna pode apenas produzir um marcador local previamente combinado. Compare inspeção, abertura e compilação nas configurações aprovadas. Registre se o marcador apareceu, qual processo o produziu e qual ação imediatamente anterior foi observada, sem tratar coincidência de horário como prova suficiente.
Defina casos permitidos e recusados antes do teste. A evidência deve relacionar revisão do projeto, identidade sintética, configuração de confiança, tarefa e processo iniciado. Se uma etapa solicitar consentimento, guarde a decisão e o efeito real. Uma tela sem aviso não comprova ausência de execução; a conclusão precisa considerar os registros disponíveis e declarar as lacunas.
Investigue mudanças além do arquivo baixado
Se houver suspeita de execução, interrompa o uso da estação conforme o plano de resposta e preserve evidências antes de promover alterações adicionais. A pesquisa da Doctor Web descreve interferência em proteções e mecanismos de recuperação. Por isso, a avaliação deve comparar políticas, acessos e estado da máquina com uma referência confiável, sem concluir que remover o projeto encerrou o incidente.
Inventarie as credenciais que poderiam estar disponíveis durante o intervalo investigado e atribua responsáveis pela contenção e recuperação. Diferencie acesso possível, leitura observada e uso comprovado. A análise de permissões e arquivos do Claude Code complementa a revisão de cópias locais de segredos, sem substituir a investigação de processos e sessões.
Aceite o fluxo com um limite verificável
A aprovação deve identificar quais operações um projeto externo pode executar, qual autoridade recebe e quem decide exceções. Preserve os casos benignos, resultados, versões e lacunas para repetir a avaliação após mudanças de IDE, extensão ou política. O objetivo é tornar a transição entre ler e executar demonstrável no ambiente da empresa, com escopo definido e evidência que outro responsável consiga revisar.
Inclua nessa aprovação um caso de exceção: um especialista temporariamente autorizado a compilar uma ferramenta externa. Registre qual identidade concede a permissão, quando ela termina e se uma revisão posterior do projeto precisa passar por nova análise antes que a tarefa volte a executar.
Perguntas frequentes
Clonar um repositório comprova que o malware executou?
Não. É preciso identificar a ação de ativação e os processos observados. A pesquisa descreve projetos e caminhos específicos, não execução universal em todo clone.
Arquivos .suo e .csproj são sempre maliciosos?
Não. O relato encontrou conteúdo malicioso em projetos específicos. A análise deve considerar origem, conteúdo, tarefas e comportamento na configuração avaliada.
O laboratório precisa usar as amostras descritas?
Não. Os testes propostos usam um projeto próprio com marcadores inofensivos e identidades sintéticas, sem reproduzir a cadeia maliciosa.
Apagar o repositório encerra a recuperação?
Isso não demonstra o estado da estação, das sessões ou das políticas. A decisão depende do que executou, da autoridade disponível e das evidências de recuperação.
Fontes e referências
Análise original da Pentesty, publicada em 9 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.