A Ameaça de Envenenamento SEO e C2 em Blockchain que Apunha a Administradores com MSI Falsos

Um esquema sofisticado descoberto pela equipe de pesquisa de ameaças de Atos em março de 2026 demonstra como atores maliciosos estão passando à ofensiva contra contas de alto privilégio mediante uma combinação de técnicas clássicas e recursos de resiliência modernos: envenenamento SEO, uma arquitetura de distribuição em duas fases no GitHub e uma resolução de comando e controle (C2) ancorada na cadeia de blocos pública. O objetivo não é o usuário médio: buscam deliberadamente administradores, engenheiros DevOps e analistas de segurança através de instaladores MSI que se fazem passar por utilitários administrativos legítimos.

A campanha explora a confiança implícita nos resultados de busca. Mediante SEO poisoning, os atacantes conseguem que repositórios de fachada no GitHub —limpios, com README profissionais e bem indexados — apareçam nos primeiros lugares para buscas de ferramentas especializadas. Esses repositórios atuam como escaparates e redirigen discretamente ao usuário a um segundo repositório oculto que aloja o instalador real. Separar a visibilidade pública da entrega do payload permite rodar a infraestrutura de distribuição sem perder posicionamento em buscadores, o que dificulta as ações de mitigação baseadas apenas em fechamentos de contas ou eliminação de repositórios.

Tecnicamente, os instaladores identificados são MSI que disparam um programa por lotes ofuscado, descarregam o runtime de Node.js do seu canal oficial e exibem uma cadeia multinível de cargas úteis JavaScript cifradas com AES-256-CBC. A persistência é obtida através de chaves Run do registro com nomes aleatórios, e o processo malicioso corre dentro de processos legítimos (por exemplo, conhost.exe com parâmetros que tentam esconder). O comportamento final é o de um RAT em memória capaz de reescrever-se a si mesmo e executar código remoto de forma dinâmica, o que complica a detecção por assinaturas estáticas.

O componente que dá verdadeiro valor estratégico a esta operação é a resolução de C2 mediante contratos inteligentes no Ethereum: o malware consulta publicamente vários endpoints RPC do Ethereum para ler o valor armazenado em um contrato e assim obter o URL do servidor de comando. Ao atualizar esse único dado na cadeia, o adversário redirige todas as infecções sem tocar os binários implantados. Isso converte a blockchain em um dead-drop público, altamente disponível e resistente a bloqueios por domínio ou IP. Para entender o mecanismo técnico subjacente, você pode consultar a documentação sobre nós e clientes do Ethereum em ethereum.org.

As implicações operacionais são graves: ao apontar ferramentas que só usam usuários com permissões elevadas, cada infecção tem uma probabilidade elevada de se tornar “chaves do reino” dentro de uma organização. Além disso, a campanha prioriza a paciência e o sigilo –post-explotação manual, reconhecimento silencioso e movimentos laterais medidos – o que aumenta o risco de acessos prolongados e exfiltração direcionada.

Detectar esta ameaça exige olhar para além de indicadores estáticos. Telemetrias úteis incluem o aparecimento de processos node.exe que executam comandos do sistema, comhost.exe lançado com argumentos invulgares como "--headless", escrituras periódicas em arquivos de traço local (por exemplo, svchost.log em %APPDATA%), e tráfego saliente para serviços RPC públicos do Ethereum. Rever histórias de egress e registros DNS/HTTP para gateways RPC públicos é crítico para descobrir infecções passadas.

Quanto à mitigação prática, convém aplicar controles de egress para bloquear ou inspeccionar o acesso aos gateways RPC públicos usados para consultar Ethereum, implementar políticas de allowlisting para downloads de software em estações administrativas, e centralizar as fontes de software em catálogos internos ou portais de fornecedor verificados. A transferência dinâmica de Node.js do seu site oficial pelo instalador malicioso sublinha a necessidade de restringir quais sistemas podem acessar livremente a internet para recuperar runtimes externos; por exemplo, o site oficial de Node.js é nodejs.org, mas seu uso deve estar sujeito a controle e monitoramento dentro do perímetro corporativo.

Também é recomendável endurecer o acesso administrativo com segmentação de rede, contas com privilégios mínimos, autenticação multifator sólida e rotação frequente de credenciais. Desde a detecção, as regras do EDR devem procurar padrões como execuções repetidas e periódicas (cada ~5 minutos) para endpoints incomuns, parent-child anomalies onde node.exe invoca shells, e a presença de chaves Run com nomes gerados aleatoriamente. Não desligue a verificação de ferramentas críticas a um simples resultado de busca: fomente o uso de repositórios internos assinados e verificados.

No plano de resposta e coordenação, os equipamentos defensivos devem combinar ações técnicas com fornecedores e plataformas (por exemplo, solicitar a retirada de repositórios maliciosos no GitHub) e trabalhar com CSIRTs e autoridades para perseguir a infraestrutura na medida do possível. No entanto, é preciso reconhecer que a natureza descentralizada do vetor C2 limita a eficácia das contramedidas tradicionais e obriga a medidas defensivas em camadas.

Sobre atribuição, há relatos de sobreposições técnicas entre este módulo "EtherHiding" e trabalhos prévios vinculados por diferentes equipes a atores estatais. No entanto, reutilização de código e técnicas entre grupos é comum; a evidência técnica por si só não deve levar a conclusões apressadas de atribuição sem um conjunto amplo de corroborações.

Finalmente, a comunidade defensiva deve considerar este caso como um lembrete de que a cadeia de abastecimento humana começa nos motores de busca e termina na máquina com privilégios. Adoptar controlos de telemetria, restringir egress para infra-estruturas descentralizadas não supervisionadas e treinar o pessoal administrativo para verificar a proveniência do software são ações urgentes. Para entender melhor as medidas de segurança na cadeia de fornecimento de software e colaborar em mitigações, o guia do GitHub sobre segurança da cadeia de fornecimento é um bom ponto de partida: Guia de segurança da cadeia de abastecimento (GitHub). Em ambientes onde existam dúvidas sobre comunicações históricas, uma análise forense dos logs e a colaboração com equipamentos como CSIRT e fornecedores de segurança geridas serão chaves para conter e erradicar esta ameaça.