Ferramentas falsas no GitHub escondem malware e miram profissionais de segurança

Ferramentas que prometem facilitar testes de segurança, varreduras de rede e análise de logs estão sendo usadas como isca para instalar backdoors e programas de roubo de informações. A investigação da Doctor Web identificou mais de 2 mil computadores Windows infectados e expôs um problema especialmente delicado: em determinados projetos, o ataque começa antes mesmo de o programa ser executado.

O cenário é familiar a desenvolvedores e analistas de segurança. Durante uma investigação ou avaliação técnica, alguém procura um utilitário no GitHub, examina sua descrição, baixa os arquivos e abre o projeto para compilá-lo ou adaptá-lo. Em geral, esse procedimento faz parte da rotina de trabalho. Nos repositórios analisados pela Doctor Web, porém, instruções maliciosas foram inseridas justamente nos componentes que preparam a execução do software, aproveitando a confiança depositada no processo de desenvolvimento.

Divulgada em 5 de novembro, a pesquisa descreve uma operação que teria começado cerca de dois anos antes, inicialmente com projetos relacionados a jogos e carteiras de criptomoedas, e que passou a incluir ferramentas direcionadas a profissionais de segurança da informação. A mudança de público aumenta a preocupação porque esses profissionais frequentemente trabalham em computadores com acesso a ambientes corporativos, configurações de VPN, credenciais temporárias e informações de clientes. O relatório contabiliza mais de 2 mil máquinas comprometidas, mas não apresenta uma distribuição geográfica que permita quantificar vítimas no Brasil.

Arquivos de projeto transformados em ponto de entrada

Um dos aspectos mais relevantes da campanha está na forma como os invasores escondem a primeira etapa da infecção. A Doctor Web encontrou comandos em arquivos .csproj e .suo associados ao Visual Studio, além de trechos maliciosos em arquivos Python e Go, disfarçados após longas sequências de espaços em branco. Em projetos do Visual Studio, por exemplo, um PreBuildEvent permite executar instruções antes da compilação. O mecanismo tem usos legítimos, mas, quando adulterado, pode transformar uma operação rotineira em uma porta de entrada para malware.

Segundo os pesquisadores, o código inicial aciona o PowerShell e recupera uma referência criptografada para baixar um arquivo compactado. O conteúdo instala um carregador modular desenvolvido com Electron e apresentado como Microsoft.exe, nome escolhido para parecer um componente confiável do sistema operacional. A partir daí, a operação procura estabelecer persistência, elevar privilégios, dificultar a atuação de ferramentas defensivas e executar outras cargas maliciosas em processos legítimos.

A análise identificou técnicas de evasão que incluem falsificação do processo pai, alterações relacionadas ao Smart App Control, tentativas de remover hooks da biblioteca ntdll.dll, uso de chamadas diretas ao sistema e interferência em mecanismos de monitoramento como ETW e AMSI. Há também uma rota alternativa que tenta criar exclusões no Microsoft Defender e injetar código em RegAsm.exe. Essas capacidades mostram o esforço dos operadores para manter o acesso, embora sua presença no código não signifique que todas as etapas tenham funcionado em cada computador infectado.

Entre os componentes distribuídos estão o AsyncRAT, um backdoor que permite controle remoto; um programa que substitui endereços de carteiras de criptomoedas copiados para a área de transferência; e um infostealer voltado à coleta de dados. A lista de alvos inclui informações de navegadores, configurações de VPN, clientes FTP, MobaXterm e tokens do Discord. Parte dos dados obtidos pode ser enviada aos operadores por meio de um bot do Telegram. O malware ainda apresenta mecanismos para prejudicar atualizações de soluções de segurança e recursos de recuperação do Windows.

Esse conjunto de funcionalidades explica por que a campanha não deve ser tratada apenas como mais uma distribuição de software malicioso. Uma credencial retirada de um navegador pode abrir acesso a um serviço corporativo; um perfil de VPN comprometido pode exigir revogação e investigação; e um arquivo de configuração obtido em uma estação técnica pode revelar detalhes úteis para novas tentativas de intrusão. Não há, no relatório público, confirmação de que essas consequências tenham ocorrido em empresas brasileiras específicas, mas os riscos são coerentes com os recursos observados nas amostras.

O risco para empresas vai além do computador infectado

Para consultorias que realizam testes de invasão, a exposição merece atenção particular. É comum que profissionais recebam acessos temporários a sistemas de clientes, utilizem ferramentas de varredura e mantenham evidências técnicas durante a execução dos trabalhos. Se a estação usada nessas atividades for comprometida, a investigação do incidente pode precisar alcançar credenciais, sessões, conexões remotas e dados de terceiros. A confiança estabelecida entre contratante e prestador de serviços torna a proteção desse ambiente parte essencial da própria entrega de segurança.

O caso também ilustra uma fragilidade recorrente da cadeia de suprimentos de software: a reputação de uma plataforma não equivale à validação de cada projeto nela hospedado. O GitHub é um ambiente legítimo de colaboração, mas repositórios podem ser criados por agentes maliciosos ou conter arquivos adulterados. Avaliar somente o código principal, ignorando scripts de instalação, dependências e eventos de compilação, deixa de fora justamente os pontos explorados nesta campanha.

Na prática, equipes de desenvolvimento e segurança devem submeter ferramentas desconhecidas a uma verificação inicial de procedência e comportamento antes de executá-las em equipamentos de produção. Isso inclui inspecionar arquivos de projeto e comandos de pré-compilação, comparar versões com fontes oficiais, revisar dependências e, quando necessário, realizar testes em ambientes isolados, sem credenciais reais nem acesso irrestrito a redes corporativas. A adoção de controles de execução e de privilégios mínimos reduz a possibilidade de que um utilitário aparentemente simples alcance recursos sensíveis.

O monitoramento também precisa considerar sinais que normalmente não seriam esperados durante a abertura ou compilação de uma ferramenta: processos do ambiente de desenvolvimento iniciando PowerShell, novas exclusões no antivírus, mecanismos de persistência e conexões externas sem justificativa operacional. Indicadores técnicos publicados pelos pesquisadores podem ajudar na busca retrospectiva, mas não devem ser a única referência, pois arquivos e infraestrutura podem mudar entre campanhas.

Se houver suspeita de execução de um projeto comprometido, remover os arquivos baixados não basta. A resposta deve contemplar isolamento do equipamento, preservação de evidências, investigação de persistência e possível exfiltração, além da revisão de tokens, sessões, chaves e acessos de VPN que possam ter sido expostos. Em consultorias, a avaliação deve incluir os acessos temporários concedidos por clientes, com comunicação proporcional aos indícios identificados.

O que torna a investigação especialmente relevante é a escolha do alvo. Em vez de depender apenas de mensagens fraudulentas ou de uma vulnerabilidade explorada remotamente, os operadores incorporaram o ataque ao fluxo de trabalho de profissionais acostumados a procurar falhas. A lição para as empresas não é abandonar ferramentas abertas, mas reconhecer que a verificação de origem, integridade e comportamento precisa começar antes da primeira compilação.