Loader em C++ consulta contratos inteligentes públicos para recuperar comandos criptografados, reduzindo dependência de domínios e servidores tradicionais de comando e controle.
| Componente | Aeternum C2, um loader nativo em C++ com compilações x32 e x64, operado por painel web e contratos inteligentes na blockchain Polygon. |
| Vetor | Operadores registram comandos criptografados em contratos inteligentes e os bots consultam endpoints públicos RPC da Polygon para recuperar instruções confirmadas. |
| Impacto | A infraestrutura de comando e controle fica menos dependente de servidores e domínios removíveis, permitindo distribuição de cargas como clipper, stealer, RAT ou miner quando configuradas pelo operador. |
| Prioridade | Monitorar endpoints que consultam RPCs públicos da Polygon sem justificativa de negócio, correlacionar essas consultas com execução de binários desconhecidos e bloquear cargas baixadas a partir de URLs configuradas no painel. |
| Artefatos | Painel implementado como aplicação Next.js, contratos inteligentes selecionados pelo operador, comandos criptografados retornados por função consultada pelo malware e builds verificados contra detecção por antivírus via Kleenscan. |
| Mitigação | Restringir tráfego blockchain não autorizado em estáções de trabalho, revisar execução de binários C++ desconhecidos, conter hosts com consultas RPC suspeitas e validar políticas de controle de aplicação. |
Aeternum C2 é um loader de botnet que troca a arquitetura tradicional de comando e controle por uma camada baseada na blockchain Polygon. Em vez de depender de um domínio, servidor VPS ou painel exposto diretamente para entregar instruções aos sistemas comprometidos, o operador escreve comandos criptografados em contratos inteligentes. Os bots instalados nos endpoints consultam endpoints públicos de RPC da Polygon, recuperam o conteúdo retornado pelo contrato, decodificam a instrução e executam a ação definida para aquela infecção ou para todo o conjunto de máquinas sob controle.
O desenho aumenta a resiliência operacional porque a transação confirmada passa a existir em uma rede pública amplamente usada por aplicações descentralizadas. A remoção de um domínio ou de um servidor não elimina o comando já registrado no contrato, e a defesa precisa tratar o problema como uma combinação de execução local de malware, abuso de infraestrutura blockchain legítima e download posterior de cargas configuradas pelo operador. O material analisado indica que a operação é comercializada como crimeware: um pagamento de 200 dólares daria acesso a um painel e a uma build configurada, enquanto uma oferta separada prometia a base C++ completa e atualizações por 4.000 dólares. Posteriormente, o ator associado ao nome LenAI tentou vender o conjunto por 10.000 dólares, alegando falta de tempo para suporte e envolvimento em outro projeto.
O fluxo começa no painel web, descrito como uma aplicação Next.js, a partir do qual o operador seleciona um contrato inteligente, define o tipo de comando, informa uma URL de carga e atualiza a instrução. O comando pode ser direcionado a todos os endpoints ou a um dispositivo específico. Depois que a transação é confirmada na Polygon, os hosts comprometidos que estão realizando polling da rede passam a conseguir recuperar a instrução. O contrato contém uma função que retorna o comando criptografado quando é chamada pelo malware por meio de RPC; a amostra local decodifica o valor e aciona o comportamento correspondente na máquina vítima.
A escolha por contratos inteligentes altera o ponto de contenção. Em C2 convencional, a derrubada do domínio, o bloqueio de IP ou a apreensão de um servidor podem interromper a comunicação. Nesse modelo, o operador precisa manter principalmente uma carteira e uma cópia local do painel, enquanto a rede pública armazena a instrução confirmada. O custo operacional também é baixo no contexto relatado: 1 dólar em MATIC seria suficiente para aproximadamente 100 a 150 transações de comando. Isso não torna a infecção invisível, mas desloca a detecção para sinais de endpoint e rede, como processos sem relação com criptoativos consultando RPCs da Polygon, execução subsequente de cargas externas e presença de binários nativos que implementam lógica de polling.
O malware também incorpora recursos anti análise. Foram descritas verificações para identificar ambientes virtualizados, além da oferta aos clientes de varrer builds por meio do Kleenscan para avaliar se seriam marcadas por produtos antivírus. A finalidade desses controles é prolongar o tempo de vida das infecções e reduzir a exposição de amostras durante análise automatizada. As capacidades distribuídas pelos contratos podem variar conforme o contrato e a carga configurada: o contexto cita uso potencial para clipper, stealer, RAT ou miner. Esses termos devem ser tratados como classes funcionais de payload, não como confirmação de uma família adicional específica instalada em todos os casos.
A superfície principal está em estáções e servidores Windows capazes de executar builds nativas C++ x32 ou x64 do loader. O risco aumenta em ambientes onde usuários conseguem executar binários baixados, onde não há controle de aplicação e onde tráfego HTTPS ou RPC para serviços públicos de blockchain não é filtrado ou acompanhado por telemetria. Como o painel permite definir uma URL de carga, a infecção inicial não precisa conter todas as funcionalidades finais; ela pode funcionar como uma ponte para buscar módulos adicionais após receber a instrução registrada no contrato.
O abuso da Polygon também complica bloqueios amplos. Organizações que utilizam aplicações descentralizadas de forma legítima podem ter tráfego para endpoints RPC públicos, e uma política de bloqueio total pode gerar impacto operacional. A resposta mais precisa é distinguir processos, usuários e destinos esperados de consultas iniciadas por binários desconhecidos. A presença de tráfego blockchain em uma estáção administrativa, em um servidor sem função relacionada a criptoativos ou imediatamente antes de criação de processos suspeitos deve ser tratada como sinal de alta prioridade.
- Endpoints Windows executando binários C++ desconhecidos em arquitetura x32 ou x64.
- Hosts que consultam endpoints públicos RPC da Polygon sem justificativa de negócio documentada.
- Ambientes com permissão ampla para execução de arquivos baixados e ausência de lista de aplicações permitidas.
- Sistemas em que downloads de cargas externas não são correlacionados com o processo originador e com a consulta anterior ao contrato inteligente.
A caça deve começar pela correlação entre rede e processo. Consultas recorrentes a RPCs públicos da Polygon, quando originadas por executáveis fora de navegadores, carteiras, ferramentas de desenvolvimento blockchain ou aplicações corporativas aprovadas, merecem investigação. O sinal se torna mais forte quando a mesma árvore de processos executa um binário recém-criado, grava arquivos em diretórios temporários ou inicia conexões posteriores para buscar uma carga configurada pelo operador. Como o conteúdo do comando é criptografado, a inspeção do payload da requisição pode ser menos útil do que o vínculo temporal entre chamada RPC, decodificação local e execução subsequente.
Em endpoint, equipes devem procurar executáveis C++ sem reputação, compilações para 32 e 64 bits distribuídas fora de canais conhecidos, comportamento anti virtualização e tentativas de reduzir exposição a sandbox. O uso de serviços de verificação contra antivírus antes da distribuição sugere que hashes isolados podem envelhecer rapidamente; por isso, a detecção deve combinar reputação, comportamento, caminho de execução, assinatura, prevalência interna e anomalias de rede. Em proxy, EDR e DNS, a ausência de domínio C2 clássico não deve encerrar a investigação: nesse caso, a dependência visível pode aparecer como tráfego para infraestrutura legítima de blockchain, seguido por download de carga em outro destino.
- Processos não aprovados realizando chamadas RPC para a rede Polygon em intervalos regulares.
- Execução de binários desconhecidos logo após consultas blockchain e antes de conexões para URLs de carga.
- Sinais de anti análise, como encerramento ou mudança de comportamento em máquinas virtuais e sandboxes.
- Downloads externos iniciados por processos sem histórico corporativo ou por diretórios temporários do usuário.
- Eventos de criação de processo compatíveis com loader, seguidos por persistência ou execução de módulos como miner, RAT, stealer ou clipper quando houver evidência local.
A resposta deve priorizar contenção de hosts com comportamento compatível com polling de C2 via blockchain. O primeiro passo defensivo é isolar máquinas suspeitas, preservar artefatos voláteis e coletar árvore de processos, conexões de rede, arquivos recentes e eventos de execução. Em seguida, é necessário bloquear ou controlar tráfego para endpoints RPC da Polygon quando não houver necessidade corporativa. Onde o bloqueio total não for viável, a regra deve ser aplicada por perfil de ativo, permitindo somente aplicações aprovadas e registrando qualquer exceção com dono técnico e justificativa.
A mitigação local depende de controle de aplicação, EDR configurado para bloquear executáveis sem reputação e inspeção de downloads de cargas posteriores. Como o operador pode usar múltiplos contratos inteligentes para funções diferentes, a remoção de uma amostra não deve ser considerada suficiente sem validar persistência, tarefas agendadas, chaves de inicialização, serviços e diretórios de usuário. A equipe também deve revisar políticas de proxy e firewall para registrar chamadas a serviços blockchain públicos, além de criar detecções comportamentais que combinem chamada RPC, execução de binário e download subsequente. Em paralelo, contas usadas nos hosts afetados devem ter sessões revisadas, especialmente quando houver indício de carga com capacidade de roubo de informações ou controle remoto.
O ecossistema associado ao ator amplia o risco operacional. O mesmo nome LenAI aparece vinculado a ErrTraffic, solução voltada a automatizar ataques ClickFix por meio de falsas falhas em sites comprometidos para induzir usuários a seguir instruções maliciosas. O contexto também descreve um serviço separado, DSLRoot, que usa laptops dedicados em residências dos Estados Unidos para formar uma rede de proxy residencial, com software Delphi chamado DSLPylon capaz de enumerar modems suportados e controlar equipamentos residenciais e dispositivos Android via integração ADB. Esses elementos não provam uso conjunto em uma única campanha, mas mostram uma tendência de reduzir pontos fáceis de derrubada, abusar de infraestrutura residencial ou descentralizada e vender acesso operacional como serviço.
- Isolar hosts com consultas RPC suspeitas e preservar eventos de processo, rede e arquivos recentes.
- Restringir RPCs públicos da Polygon por perfil de ativo, mantendo exceções documentadas e monitoradas.
- Aplicar controle de aplicação para impedir execução de builds C++ desconhecidas em diretórios de usuário e temporários.
- Correlacionar chamadas blockchain com downloads posteriores e criação de processos filhos.
- Revisar persistência, credenciais expostas no host e sinais de cargas adicionais antes de devolver a máquina ao uso.
0 Comentários