C2Looper explicado: o backdoor para Windows que migrou do HTTP para o GitHub

Como funcionam as duas versões observadas

Versão antiga: comando e controle por HTTP direto

As primeiras amostras se comunicam com um servidor controlado pelo invasor usando HTTP sem criptografia e tarefas no formato JSON. Os relatos descrevem consultas muito frequentes, com intervalos de aproximadamente um segundo — um comportamento que pode gerar um sinal bastante característico no endpoint ou na rede.

O beacon do implante identifica a vítima com informações como nome de usuário do Windows, hostname DNS, ID do processo em execução do C2Looper e um identificador de bot derivado do hostname e do nome de usuário. O beacon é enviado ao caminho /api/beacon, enquanto os resultados dos comandos são reportados por /api/result/.

O conjunto de comandos oferece controle prático sobre o sistema infectado, incluindo:

• Execução de comandos arbitrários do shell ou do sistema;
• Reconhecimento do host;
• Download de arquivos;
• Atualização do implante e implantação de cargas adicionais.

Um mecanismo de atualização particularmente relevante usa o comando upload para baixar um executável portátil de uma URL fornecida pelo operador e salvá-lo como DLL no diretório local do OneDrive do usuário. Em seguida, o malware pode encerrar o processo do OneDrive e usar um executável legítimo do serviço para carregar a biblioteca inserida por meio de DLL sideloading. Amostras analisadas usaram o arquivo wtsapi32.dll em %LocalAppData%\\Microsoft\\OneDrive.

A técnica coloca o código malicioso ao lado de um executável confiável e explora o comportamento normal de carregamento de bibliotecas desse programa. Para os defensores, o alerta não é simplesmente a presença do OneDrive, mas o fato de um binário legítimo do serviço carregar uma DLL inesperada a partir de um diretório incomum ou gravável pelo usuário.

Técnicas de evasão nas amostras antigas

O C2Looper usa descriptografia de strings em tempo de execução por XOR, aparentemente com uma chave de oito bytes reutilizada. Também resolve dinamicamente APIs do Windows por meio de LoadLibrary e GetProcAddress. Essas técnicas podem reduzir a eficácia de uma análise estática simples e aumentam a importância da telemetria comportamental coletada por ferramentas de detecção e resposta em endpoints (EDR).

Versão mais recente: GitHub como infraestrutura de C2

Uma compilação mais nova substitui o servidor de C2 convencional por repositórios do GitHub. Segundo os relatos, os repositórios são usados para distribuir tarefas, registrar beacons, receber resultados de comandos e armazenar dados relacionados a cargas adicionais.

Cada computador infectado recebe um diretório próprio dentro do repositório. O implante lê as instruções em cmd.json, executa a ação solicitada e grava a saída em result.json, no mesmo diretório. Isso oferece ao operador um fluxo simples, baseado em arquivos, para emitir comandos e coletar respostas sem depender de um servidor de C2 dedicado.

O uso do GitHub pode dificultar estratégias baseadas apenas no bloqueio de domínios, já que a plataforma também é uma infraestrutura legítima para desenvolvedores e empresas. A resposta defensiva precisa ser comportamental: investigar acessos periódicos a repositórios ou APIs do GitHub originados de endpoints que normalmente não precisam desse serviço e diferenciar a atividade suspeita por host do uso autorizado em desenvolvimento ou CI/CD.

A migração para o GitHub, combinada a capacidades adicionais de execução de cargas relatadas nas amostras recentes, indica que o C2Looper continua em desenvolvimento ativo.

Possível entrega por engenharia social do tipo ClickFix

A ThreatLabz avalia, com confiança baixa a moderada, que o C2Looper possa ser entregue por uma cadeia de infecção ClickFix em múltiplas etapas. Nessas campanhas, a vítima encontra uma falsa solicitação de verificação, um erro do navegador, um CAPTCHA ou uma mensagem de correção do sistema e é convencida a copiar e executar um comando no PowerShell, na janela Executar do Windows ou em outra interface de comandos.

Esse modelo torna a interação humana um ponto importante de prevenção e detecção. Uma página da web ou mensagem do navegador não deve exigir que o usuário cole comandos no PowerShell, no Terminal ou na janela Executar para concluir uma verificação ou corrigir um suposto problema.

Relatos relacionados também abordam vishing por meio do Teams e abuso do Quick Assist no ecossistema mais amplo de engenharia social. No entanto, as evidências fornecidas não comprovam que todas essas campanhas tenham distribuído o C2Looper. Essas sobreposições devem ser tratadas como contexto plausível, não como atribuição confirmada.

O que as equipes devem monitorar

As organizações podem se concentrar em alguns comportamentos de alto valor, em vez de tentar bloquear toda ferramenta ou serviço associado ao malware:

• Beaconing frequente por HTTP sem criptografia: investigue tráfego POST JSON com intervalos incomumente regulares, especialmente requisições semelhantes a /api/beacon e /api/result/, quando associadas a um processo novo ou suspeito.
• Atividade suspeita no GitHub: procure acessos a repositórios ou APIs do GitHub que sigam um padrão periódico ou envolvam diretórios por host contendo cmd.json e result.json. Não bloqueie o GitHub indiscriminadamente; considere os fluxos legítimos de desenvolvimento e automação.
• DLL sideloading no OneDrive: gere alertas quando um executável legítimo do OneDrive for iniciado a partir de um caminho incomum no perfil do usuário, carregar uma DLL de um diretório adjacente e gravável ou criar processos-filhos inesperados.
• Execução de comandos e reconhecimento: use a telemetria do EDR para identificar PowerShell, cmd.exe, atividade da janela Executar, descoberta do sistema, downloads em etapas e execução de shell por binários recém-observados.
• Comportamento de implante em Rust: analise em conjunto a resolução dinâmica de APIs, strings criptografadas, consultas de rede e implantação de cargas, em vez de depender de uma única característica do arquivo.

Prioridades de prevenção

Os controles técnicos devem ser combinados com medidas contra engenharia social. Restrinja ou administre o uso do PowerShell iniciado pelo usuário, de hosts de scripts, de binários não assinados e da execução a partir de diretórios graváveis pelo usuário, sempre que os requisitos do negócio permitirem. O allowlisting de aplicações também pode reduzir a capacidade de execução de uma carga baixada.

As equipes de segurança e suporte devem orientar funcionários a nunca colar comandos fornecidos por um site, CAPTCHA, página de erro do navegador ou contato de suporte não solicitado. Ferramentas de suporte remoto devem operar por fluxos aprovados, com canais verificados, autenticação forte, registro das sessões e revisão rápida de atividades incomuns.

Segmentação de rede, acesso com menor privilégio, autenticação multifator, correção rápida de sistemas expostos à internet e backups offline ou imutáveis testados podem limitar o impacto de um comprometimento. Se um endpoint apresentar beaconing suspeito, atividade de shell ou DLL sideloading, isole-o rapidamente e preserve os registros do endpoint, dados de rede e, quando apropriado, a memória para investigação.

Em resumo

A importância do C2Looper está na evolução de um backdoor HTTP relativamente direto para um implante mais flexível, capaz de usar repositórios do GitHub como infraestrutura operacional. Seus recursos de shell remoto, reconhecimento, download e atualização fazem dele um ponto de apoio plausível para intrusões relacionadas a ransomware, mas as evidências disponíveis recomendam cautela, e não uma atribuição definitiva. A defesa mais eficaz combina fluxos de trabalho resistentes ao ClickFix com caça comportamental a execuções incomuns de comandos, DLL sideloading no OneDrive, consultas HTTP muito frequentes e atividade inexplicada em repositórios do GitHub.