A campanha de malware FakeGit voltou a operar no início de outubro, criando mais de 17 mil repositórios falsos na plataforma GitHub. Cada um desses repositórios contém o carregador SmartLoader, responsável por baixar e instalar o infostealer StealC em sistemas vulneráveis. A reativação da campanha tem gerado preocupação entre desenvolvedores e equipes de segurança, que precisam revisar a procedência dos projetos antes de incluí‑los em seus ambientes.
Contexto
Historicamente, grupos de cibercrime têm explorado repositórios de código aberto para disseminar malware, aproveitando a confiança que a comunidade deposita em projetos hospedados em serviços como o GitHub. A primeira onda da campanha FakeGit foi identificada em 2022, quando pesquisadores observaram repositórios que simulavam bibliotecas populares, mas que continham scripts maliciosos. Após um período de aparente inatividade, a campanha foi retomada no início deste mês, indicando que os operadores ainda veem valor estratégico em comprometer a cadeia de suprimentos de software.
Impacto
A escala da operação, com 17.610 repositórios, amplia significativamente o risco de infecção para desenvolvedores que clonam ou dependem desses projetos. Usuários finais podem ser afetados indiretamente quando softwares comprometidos são distribuídos por meio de atualizações automáticas. Embora ainda não haja números oficiais de vítimas, a natureza do StealC, um infostealer que coleta credenciais, cookies e informações de pagamento, sugere que o impacto pode se estender a ambientes corporativos, especialmente aqueles que adotam práticas de integração contínua sem validação rigorosa de origem.
Detalhes técnicos
Do ponto de vista técnico, o SmartLoader funciona como um script de inicialização que verifica a presença de um arquivo de configuração remoto. Caso o arquivo exista, o script baixa um binário adicional, que corresponde ao StealC, e o executa com privilégios do usuário que realizou o clone. O vetor de ataque baseia‑se na confiança implícita que desenvolvedores têm ao usar dependências de repositórios públicos. Em resposta a isso, a campanha utiliza nomes de projetos que imitam bibliotecas legítimas, além de descrições e readmes bem elaborados para enganar revisões superficiais. Não há vulnerabilidades específicas de software apontadas, mas a técnica depende da falta de verificação de assinatura ou hash dos pacotes.
Encerramento
Até o momento, o GitHub não divulgou medidas específicas para remover os repositórios identificados, mas a plataforma costuma agir rapidamente quando alertas são enviados por pesquisadores. Organizações são aconselhadas a reforçar políticas de verificação de dependências, adotando ferramentas de análise de integridade de código e restringindo a execução de scripts de inicialização não assinados. A fonte original da informação foi o site BleepingComputer, que acompanhou a reativação da campanha e destacou a necessidade de vigilância contínua no ecossistema de código aberto.