Campanha entrega instaladores MSI maliciosos que imitam ferramentas administrativas do Windows, baixa Node.js em tempo de execução e resolve o C2 por contratos inteligentes na rede Ethereum.
| Componente | EtherRAT distribuído por instaladores MSI que se passam por ferramentas administrativas como PsExec, AzCopy, Sysmon, LAPS e Kusto Explorer. |
| Vetor | Envenenamento de resultados de busca leva usuários a repositórios GitHub de fachada, cujo README redireciona para um segundo repositório que hospeda o MSI malicioso. |
| Impacto | Execução de JavaScript remoto no processo Node.js, persistência por chave Run, acesso ao sistema de arquivos, execução de comandos do sistema operacional e capacidade de exfiltração de dados. |
| Prioridade | Bloquear a instalação de MSI obtidos por repositórios não verificados, caçar downloads de Node.js iniciados por instaladores administrativos e investigar consultas recorrentes a serviços públicos de Ethereum RPC. |
| Artefatos | Cadeia observada com .msi, arquivo .cmd inicial, cargas criptografadas como tQqoxkAJFhqWtg5.xml e 0cZeeDPZMsxWtaK.cfg, payload em claro como 4S3HKjraAP.cfg e log em %APPDATA%\\svchost.log. |
| Infraestrutura | O RAT consulta contratos inteligentes Ethereum para obter o endereço de C2; um contrato citado é 0xc12c8d8f9706244eca0acf04e880f10ff4e52522, financiado pela carteira 0x37ef6e88425613564b2cf8adc496acff4b6481a9. |
A campanha EtherRAT combina engenharia social voltada a profissionais de infraestrutura com uma cadeia de entrega desenhada para resistir a remoções pontuais. O operador não distribui o malware por uma página aleatória ou por anexo simples: ele cria repositórios GitHub que aparentam hospedar utilitários administrativos, trabalha a visibilidade desses repositórios em mecanismos de busca e usa uma segunda camada de distribuição para manter o instalador malicioso separado da fachada indexada. O alvo operacional é claro: administradores corporativos, engenheiros DevOps, analistas de segurança e usuários que normalmente têm permissões elevadas em estáções, servidores, ambientes de nuvem ou ferramentas de investigação.
O malware é entregue como instalador MSI que imita softwares usados em administração e diagnóstico, incluindo PsExec, AzCopy, Sysmon, LAPS e Kusto Explorer. Essa escolha funciona como filtragem de vítimas: quem procura essas ferramentas tende a operar ativos sensíveis, consultar telemetria, administrar identidade, mover dados ou executar tarefas privilegiadas. Depois da execução, a cadeia usa scripts em lote, cargas JavaScript criptografadas, download do Node.js em tempo de execução, persistência no Registro e resolução de C2 por Ethereum. O resultado é um RAT em JavaScript com execução de código remoto, renovação periódica da própria carga e comunicação disfarçada como requisições a arquivos estáticos.
A infecção começa fora do endpoint, no caminho de descoberta da ferramenta. Resultados manipulados em Bing, Yahoo, DuckDuckGo e Yandex colocam repositórios de fachada em posição visível para termos ligados a utilitários de administração. O primeiro repositório não precisa conter malware para cumprir sua função: ele apresenta um README profissional, simula legitimidade e preserva o ranqueamento de busca. O link de download aponta para um segundo repositório, menos exposto, que hospeda o MSI malicioso. Essa divisão reduz o custo de recuperação do operador, porque uma remoção do repositório de payload pode ser contornada pela troca do link no README da fachada, enquanto a página indexada continua parecendo limpa.
Entre o início de dezembro de 2025 e 1 de abril de 2026, foram observadas 44 fachadas GitHub associadas à campanha, cada uma imitando uma ferramenta administrativa ou de desenvolvimento. O volume indica uma operação contínua para capturar diferentes perfis técnicos, em vez de uma tentativa isolada contra um único produto. O uso de MSI também reduz a aparência de risco para o usuário administrativo, já que instaladores desse tipo são comuns em ambientes Windows corporativos. Na variante mais recente descrita, o pacote extrai quatro arquivos e aciona uma ação customizada que executa um .cmd, dando início à implantação do RAT.
O arquivo .cmd inicial, exemplificado como VW80IqXy.cmd, é executado com privilégio SYSTEM pela CustomAction do MSI após a extração. Ele esconde nomes de comandos como curl, tar, copy, start e cmd por meio de variáveis SET concatenadas em tempo de execução, o que enfraquece detecções baseadas em strings. Em seguida, relança a si mesmo em janela minimizada, cria um diretório de estágio sob %LOCALAPPDATA%, baixa o Node.js do endpoint oficial de distribuição, extrai o runtime para uma subpasta específica da compilação e remove o arquivo compactado temporário. O script então executa o primeiro estágio JavaScript com o node.exe recém-instalado.
O primeiro estágio é um script Node.js pequeno, legível e não persistido em disco. Sua função é ler um arquivo que contém o segundo estágio, como tQqoxkAJFhqWtg5.xml, descriptografá-lo com chave e vetor de inicialização embutidos e executá-lo em memória por module._compile(). O segundo estágio descriptografa uma carga ofuscada, observada como 0cZeeDPZMsxWtaK.cfg, grava o resultado em um novo arquivo, exemplificado por 4S3HKjraAP.cfg, e o executa via node.exe envolvido por conhost.exe --headless. Essa escolha camufla a execução sob um processo legítimo do Windows e, ao mesmo tempo, cria persistência por chave Run no Registro.
O terceiro estágio é o payload principal do EtherRAT. Ele roda em segundo plano a cada inicialização, usa nome de arquivo e extensão não descritivos e mantém strings internas criptografadas, incluindo nomes de API e endereços operacionais. Ao iniciar, o RAT procura um identificador de bot em arquivo oculto ou cria um novo identificador persistente, que passa a acompanhar as comunicações futuras. Ele também calcula um diretório de trabalho derivado do nome de usuário e do nome do computador, fazendo com que o caminho varie por vítima. A partir desse ponto, o malware resolve o C2, inicia beacons, recebe comandos JavaScript e os executa dentro do processo Node.js.
A resolução de C2 é a parte mais resiliente da arquitetura. Em vez de carregar domínio ou IP fixo, o RAT consulta um contrato inteligente Ethereum cujo endereço está embutido na amostra. A variante descrita consulta nove serviços públicos de Ethereum RPC em paralelo e usa a resposta majoritária para determinar o endereço ativo do C2. Uma tarefa em segundo plano repete essa resolução a cada cinco minutos. Se o operador alterar o valor armazenado no contrato por uma transação, as instalações já comprometidas passam a usar o novo backend no próximo ciclo, sem novo MSI, sem atualização local e sem dependência de DNS tradicional.
A superfície mais exposta é formada por estáções Windows usadas por administradores, engenheiros de sistemas, operadores de segurança e profissionais que baixam utilitários diretamente pela web. A campanha não depende de uma vulnerabilidade em uma ferramenta legítima; ela depende da confiança no fluxo de busca, no nome do projeto GitHub e no formato MSI. Ambientes onde usuários privilegiados têm permissão para instalar software sem validação de origem ficam mais expostos, principalmente quando o download é feito fora de repositórios internos, catálogos corporativos ou páginas oficiais já conhecidas.
O risco é ampliado porque as ferramentas imitadas fazem parte do trabalho diário de contas com alto privilégio. Kusto Explorer aponta para usuários que consultam Azure Data Explorer por KQL; AzCopy sugere movimentação de dados em ambientes Microsoft; Sysmon, Process Explorer e TCPView podem atrair analistas investigando eventos de segurança; PsExec e LAPS indicam administração Windows e identidade local. Uma execução bem-sucedida nessas máquinas não confirma, por si só, movimentação lateral ou comprometimento de dados, mas fornece ao operador um ponto de execução com contexto privilegiado, acesso a arquivos locais e possibilidade de executar comandos adicionais.
A existência de versões anteriores com menos estágios e com um IP de C2 de fallback, citado como hxxp[://]135[.]125[.]255[.]55, indica evolução da cadeia. A arquitetura mais recente reduz indicadores fixos e aumenta a variabilidade de arquivos, nomes, extensões, diretórios, chaves e artefatos. Por isso, a defesa não deve depender apenas de um nome de arquivo específico. O comportamento é mais importante: MSI que executa .cmd como ação customizada, download de Node.js durante a instalação, criação de carga JavaScript sob diretórios de usuário, execução por conhost.exe --headless, persistência em Run e consultas frequentes a serviços Ethereum RPC.
- Estáções Windows usadas por administradores, DevOps, engenheiros de sistemas e analistas de segurança que baixam utilitários via busca pública.
- Fluxos de instalação MSI em que uma
CustomActionaciona um arquivo.cmde prepara runtime Node.js sob%LOCALAPPDATA%. - Repositórios GitHub que funcionam como fachada limpa e redirecionam para um segundo repositório com o instalador malicioso.
A busca defensiva deve começar pelo encadeamento de processos, porque a campanha deixa uma sequência operacional incomum para instaladores administrativos legítimos. Um MSI que dispara cmd.exe, cria processo minimizado, baixa Node.js por curl, extrai runtime com tar e em seguida executa JavaScript por node.exe merece investigação. A presença de conhost.exe --headless associado a node.exe e a arquivos .cfg, .xml ou extensões sem relação com JavaScript é outro ponto de atenção. O fato de os nomes variarem exige regras comportamentais, correlação temporal e análise de árvore de processos.
No host, o arquivo %APPDATA%\\svchost.log é um artefato relevante, pois a operação descrita registra inicialização, resolução por blockchain, reofuscação, requisições de polling, recebimento de tarefas, execução, erros e atualizações de URL. Esse log não deve ser tratado como log legítimo do Windows apenas pelo nome svchost. A persistência por chave Run também precisa ser revisada, especialmente quando aponta para node.exe, conhost.exe, arquivos JavaScript, arquivos .cfg ou diretórios aleatórios sob o perfil do usuário. A investigação deve coletar o MSI, o .cmd, os arquivos criptografados e a carga em claro antes de remover os artefatos, quando possível.
Na rede, a telemetria deve procurar estáções que consultam serviços públicos de Ethereum RPC sem justificativa de negócio e que fazem isso em ciclos regulares próximos de cinco minutos. Depois da resolução, os beacons do RAT tentam parecer requisições comuns de navegador para ativos estáticos, com caminhos contendo segmentos hexadecimais aleatórios, extensões como .png, .jpg, .gif, .css, .ico ou .webp e nomes variados de parâmetros de consulta. Essa aleatoriedade dificulta indicadores estáticos, mas a combinação de periodicidade, origem em processo Node.js instalado recentemente e destino derivado de resolução por contrato Ethereum é um sinal forte.
Em repositórios e proxies corporativos, vale revisar downloads de MSI originados de GitHub quando o nome do projeto se aproxima de ferramentas administrativas. A cadeia em duas etapas também permite caça por README que redireciona para outro repositório, principalmente quando o primeiro repositório não contém código funcional compatível com a ferramenta anunciada. Para ambientes com EDR, consultas devem relacionar navegador, download do MSI, execução do instalador, criação de diretório sob %LOCALAPPDATA%, download de Node.js, criação de chave Run e tráfego Ethereum RPC no mesmo intervalo.
- MSI criando processo
.cmdporCustomActione executando comandos ofuscados por variáveisSETconcatenadas. node.exebaixado durante a instalação e executando payloads locais com nomes aleatórios ou extensões como.cfge.xml.conhost.exe --headlessassociado a execução de JavaScript e persistência por chaveRun.- Consultas periódicas a serviços públicos de Ethereum RPC para obter endereço de C2 a partir de contrato inteligente.
- Criação ou atualização de
%APPDATA%\\svchost.logcontendo eventos operacionais do RAT.
A resposta deve priorizar contenção de instalação e validação de origem. Organizações que permitem instalação livre de ferramentas administrativas devem restringir MSI não aprovados, exigir distribuição por catálogo interno e bloquear execuções iniciadas a partir de diretórios de download quando o binário não tiver procedência validada. Para ferramentas como PsExec, AzCopy, Sysmon, LAPS e Kusto Explorer, a equipe deve publicar fontes oficiais internas, hashes aprovados quando disponíveis no processo corporativo e orientação clara para que administradores não usem resultados de busca como fonte primária de download.
Em endpoints suspeitos, a contenção deve isolar a máquina antes de remover a persistência, porque o RAT pode receber comandos JavaScript arbitrários durante o polling. A coleta inicial deve incluir árvore de processos, conteúdo da chave Run, diretórios recém-criados sob %LOCALAPPDATA%, arquivos com nomes aleatórios associados ao Node.js, o log %APPDATA%\\svchost.log, histórico de download do navegador e eventos de instalação MSI. Como o malware reofusca a própria carga a cada execução, capturar os artefatos no estado atual é importante para comparar amostras e reconstruir a linha do tempo.
No controle de rede, bloquear genericamente Ethereum pode não ser viável em todos os ambientes, mas estáções administrativas raramente precisam consultar múltiplos serviços públicos de RPC sem aplicação aprovada. Regras de proxy podem exigir justificativa, autenticação e inspeção para tráfego Ethereum RPC. Detecções devem alertar quando um host recém-executou MSI e, em seguida, passou a consultar APIs Ethereum, sobretudo quando o processo responsável for node.exe instalado no perfil do usuário. Para C2 posterior, filtros baseados somente em extensão de URL não bastam, pois o RAT varia caminhos e usa extensões de ativos estáticos para camuflagem.
Após erradicação, a revisão de credenciais deve ser proporcional ao privilégio do usuário afetado. O contexto confirma capacidade de executar comandos, acessar sistema de arquivos e exfiltrar dados, então contas administrativas usadas na estáção devem ter sessões revogadas, senhas ou segredos rotacionados quando houver exposição local plausível e tokens armazenados em ferramentas de linha de comando revisados. Também é necessário verificar se houve execução de comandos adicionais pelo RAT, usando o log local, EDR, eventos Windows, histórico de shell e telemetria de rede. A ausência de um indicador fixo não encerra a investigação, porque a infraestrutura de C2 pode ser alterada por uma única transação no contrato inteligente.
- Restringir instalação de MSI não aprovados e distribuir ferramentas administrativas por repositório corporativo controlado.
- Criar detecções para MSI que aciona
.cmd, baixa Node.js e executanode.execom cargas não assinadas sob diretórios de usuário. - Monitorar e controlar consultas a serviços públicos de Ethereum RPC a partir de estáções administrativas.
- Remover persistência em chave
Runsomente depois de coletar artefatos, logs e árvore de processos para análise. - Rotacionar credenciais e tokens acessíveis ao usuário afetado quando houver execução confirmada do EtherRAT em estáção privilegiada.
0 Comentários