Voltar

2026/11/11

A ferramenta de segurança que você baixou é o malware: repositórios falsos no GitHub infectam mais de 2.000 PCs Windows

A Doctor Web encontrou ferramentas de segurança falsas no GitHub que executam malware na compilação. Como a armadilha funciona e o que verificar antes de compilar.

Você encontra no GitHub um pequeno utilitário que organiza a saída de um scanner de rede. Ele tem README, um projeto do Visual Studio e instruções de compilação. Você clona o repositório e clica em Build. Nada parece errado, mas quando o compilador começa a trabalhar, um comando oculto já foi executado na sua estação de trabalho.

Essa é a armadilha descrita pela Doctor Web em 5 de novembro de 2026. Seus pesquisadores encontraram repositórios no GitHub que se passavam por ferramentas de automação de varreduras, testes de segurança e análise de logs, e contaram mais de 2.000 PCs Windows infectados no momento da pesquisa. Este artigo explica como a armadilha funciona, por que ela engana até engenheiros experientes e o que verificar antes de compilar um código que você acabou de clonar.

Principais pontos

  • Os repositórios se passam por ferramentas de segurança, e o comando malicioso é executado durante a compilação ou ao iniciar um script, sem nenhum programa separado para abrir.
  • O código se esconde em arquivos de projeto do Visual Studio, em arquivos .suo e atrás de longas sequências de espaços em branco em códigos-fonte Python e Go.
  • As cargas finais são dois backdoors AsyncRAT, um sequestrador de área de transferência para endereços de carteiras de criptomoedas e um infostealer que rouba dados do navegador, configurações de VPN e FTP e tokens do Discord.
  • Leia os arquivos de build antes de compilar e compile código desconhecido em uma máquina virtual descartável, sem nenhuma credencial.
  • Se você já compilou um desses projetos, trate a estação de trabalho como comprometida e troque, a partir de um dispositivo limpo, todas as credenciais que ela continha.

O que a Doctor Web encontrou

Segundo o relatório da Doctor Web, os primeiros repositórios infectados surgiram há cerca de dois anos. Na época, o alvo eram usuários de carteiras de criptomoedas, e os projetos eram apresentados como jogos de blockchain, bots de jogos e cheats. Agora, os operadores passaram a mirar profissionais de segurança da informação. Um dos repositórios falsos continha um script para analisar, limpar e formatar a saída do scanner de rede Fscan.

Não se trata de uma vulnerabilidade de software, e não há CVE a corrigir. É uma campanha de cadeia de suprimentos e engenharia social: os atacantes publicam um projeto que parece útil e esperam que alguém o compile. O resumo do BleepingComputer sobre a pesquisa chama o truque dos espaços em branco de técnica antiga que continua eficaz.

Como a armadilha funciona

A Doctor Web encontrou o código malicioso em três tipos de arquivo. Nenhum deles é o arquivo que um revisor costuma abrir primeiro.

Onde se escondeO que acontecePor que passa despercebido
Arquivo de projeto .csprojUm PreBuildEvent executa um comando antes de o projeto ser compiladoOs revisores leem o código-fonte, não o arquivo de projeto
Arquivo .suoO arquivo contém um comando PowerShellÉ um arquivo binário de configurações que o Visual Studio normalmente guarda em uma pasta oculta
Arquivos-fonte Python e GoO código malicioso fica atrás de uma grande quantidade de caracteres de espaço em brancoA linha parece vazia, a menos que você role muito para a direita ou ative a quebra automática de linha

A partir daí, a cadeia é a mesma. Um script PowerShell (o relatório cita C:\Users\Public\Pictures\t.ps1 e L.ps1 como exemplos) solicita uma string criptografada aos servidores dos atacantes ou a serviços legítimos como YouTube, Telegram, Google Docs, GitCode e Pastebin. Descriptografada, a string é um link de download de um arquivo compactado que é extraído em C:\ProgramData\Windows.Microsoft.Photos.

Dentro dele há um loader baseado em Electron chamado Microsoft.exe, que a Doctor Web detecta como Trojan.Loader.3261. O loader envia detalhes do sistema por meio de um bot do Telegram, tenta obter privilégios mais altos e desativa o Windows Defender, o Controle de Conta de Usuário, as notificações, a Restauração do Sistema e as cópias de sombra de volume. Ele também tenta remover produtos da ESET, McAfee e Malwarebytes e altera o arquivo hosts para bloquear domínios de fabricantes de antivírus.

Para passar despercebido, no modo padrão o loader faz com que explorer.exe pareça ser seu processo pai, altera o valor de registro VerifiedAndReputablePolicyState para contornar o Smart App Control, restaura o código original de ntdll.dll para remover os hooks que os produtos de segurança colocam ali, faz chamadas de sistema diretas e modifica as funções do Windows usadas para rastreamento de eventos e varredura de scripts. Em seguida, injeta suas cargas em processos legítimos do Windows, como RegAsm.exe.

Depois vêm três cargas:

  • Dois backdoors AsyncRAT. Os arquivos são idênticos, mas usam portas de rede diferentes, o que, segundo a Doctor Web, pode permitir que dois operadores controlem o mesmo dispositivo ao mesmo tempo.
  • Um clipper. Ele substitui endereços de carteiras de criptomoedas na área de transferência e envia capturas de tela, o título da janela ativa, o login do usuário e o endereço IP a um bot do Telegram.
  • Um infostealer (JS.Stealer.191). Ele verifica a presença de sandboxes e máquinas virtuais e depois coleta dados do navegador, arquivos de conexão do FileZilla, MobaXterm e Total Commander, configurações de VPN, arquivos de mensageiros, dados de contas de jogos e tokens do Discord, enviando tudo por um bot do Telegram.

A Doctor Web também encontrou um componente inacabado que instalaria um serviço do Windows e baixaria o loader novamente caso ele fosse excluído. Isso sugere que os operadores ainda estão desenvolvendo o conjunto de ferramentas.

Por que funciona com profissionais

A campanha foi construída em torno de hábitos que normalmente são considerados boas práticas.

  • Compilar a partir do código-fonte parece mais seguro do que executar um download. Muitos engenheiros se recusam a executar um binário desconhecido, mas compilam um projeto sem hesitar, porque podem ler o código. Aqui, o código que eles leem está limpo, e o comando fica na configuração de build.
  • Não existe o momento de “executar este programa”. O comando é iniciado como parte de uma compilação comum, então a pausa habitual antes de abrir um programa desconhecido nunca acontece.
  • O GitHub é um lugar confiável. Um repositório com README organizado e instruções de instalação parece igual a milhares de projetos honestos. A Doctor Web observa que os atacantes chegaram a fornecer instruções para instalar o Visual Studio e clonar o repositório.
  • A estação de trabalho de um engenheiro guarda as chaves. Sessões salvas no navegador, perfis de VPN e arquivos de conexão a servidores são exatamente o que o infostealer coleta, e muitas vezes abrem caminho para sistemas de produção e ambientes de clientes.

O que verificar antes de compilar

Estas verificações levam poucos minutos e servem para qualquer projeto recém-clonado, no Windows, Linux ou macOS. Execute-as na pasta do repositório antes de abrir o projeto em um IDE.

# 1. Build hooks and command execution in project files
grep -rniE 'PreBuildEvent|PostBuildEvent|<Exec |powershell|cmd\.exe' \
  --include='*.csproj' --include='*.vbproj' --include='*.vcxproj' \
  --include='*.props' --include='*.targets' .
# 2. Visual Studio user-option files that should not be in a repository
find . -name '*.suo'
# 3. Files with very long runs of spaces or tabs on one line
grep -rlE '[[:space:]]{200,}' .

No Windows sem um shell no estilo Unix, o PowerShell faz o mesmo trabalho na verificação de espaços em branco:

Get-ChildItem -Recurse -File |
  Select-String -Pattern '\s{200,}' -List |
  Select-Object -ExpandProperty Path

Um resultado não é prova de malware. Muitos projetos honestos usam eventos de build, e arquivos minificados contêm linhas longas. É um motivo para abrir o arquivo e ler o que o comando faz antes que qualquer coisa seja executada.

  1. Leia primeiro os arquivos de build. Arquivos de projeto, Makefiles, setup.py, scripts de instalação de pacotes e arquivos de CI podem executar comandos. Leia-os com o mesmo cuidado que o código-fonte.
  2. Exclua arquivos .suo e pastas .vs que venham com um repositório. São configurações por usuário, e o projeto não precisa delas para compilar.
  3. Ative a quebra automática de linha ou a exibição de espaços em branco no seu editor ao revisar código desconhecido.
  4. Examine o histórico do repositório. Uma conta nova, um único commit grande, poucas issues ou colaboradores reais e uma ferramenta que duplica um projeto conhecido são motivos para mais cautela. Estrelas e forks sozinhos provam pouco, porque podem ser falsificados.
  5. Compile código desconhecido em um ambiente descartável. Use uma máquina virtual ou um contêiner descartável, sem senhas salvas, sem perfil de VPN e sem chaves SSH, e exclua-o depois.

Dica: Mantenha um snapshot limpo de máquina virtual para testar ferramentas. Clone, compile e teste ali, depois volte ao snapshot. Se uma ferramenta se mostrar útil, revise-a com cuidado antes que ela chegue perto da sua estação de trabalho do dia a dia.

Se você já compilou um deles

A Doctor Web publicou hashes de arquivos, domínios, endereços e exemplos de nomes de repositórios em sua lista de indicadores de comprometimento. Entre os sinais descritos no relatório estão:

  • uma pasta C:\ProgramData\Windows.Microsoft.Photos ou um programa chamado Microsoft.exe;
  • t.ps1 ou L.ps1 em C:\Users\Public\Pictures;
  • exclusões do Windows Defender para regasm.exe ou dwm.exe que você não adicionou;
  • domínios de fabricantes de antivírus no arquivo hosts, ou Restauração do Sistema e cópias de sombra desativadas;
  • software de segurança que desapareceu ou parou de se atualizar.

Se encontrar algum desses sinais, ou se souber que compilou um projeto da lista, aja como se tudo naquela máquina tivesse sido lido:

  1. Desconecte a estação de trabalho da rede e avise sua equipe de segurança.
  2. A partir de outro dispositivo limpo, troque as senhas salvas no navegador e encerre as sessões ativas, para que os cookies de sessão roubados deixem de funcionar.
  3. Substitua os perfis de VPN e as senhas ou chaves armazenadas em clientes FTP e de terminal, e revise os servidores que eles podiam acessar.
  4. Redefina as sessões do Discord e de outros mensageiros e transfira os criptoativos para uma carteira criada em um dispositivo limpo.
  5. Reinstale o sistema operacional em vez de limpá-lo. O loader desativa recursos de segurança e recuperação e instala dois backdoors, então é difícil confiar em um sistema apenas limpo.

Dica: Verifique nos logs de servidores e de VPN os acessos da conta afetada após a data em que o projeto foi compilado. Os arquivos de conexão roubados são usados a partir dos sistemas dos atacantes, não da estação de trabalho infectada.

Como a LOGIQ pode ajudar

A LOGIQ ajuda organizações a usar software open source com segurança, do Linux corporativo e do OpenJDK até os pipelines de build e implantação ao redor deles. Se quiser uma segunda opinião sobre como suas equipes trazem código externo para o ambiente, ou precisar de ajuda para separar os sistemas de build das credenciais que importam, fale conosco.