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.
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.
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:
tokyoSkytreeakihabaraLightsasakusaTempleginzaLuxuryshibuyaCrossing
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.
Cada uma dessas funções do contrato inteligente retorna um payload que é decodificado e executado dinamicamente pela função **teaCeremony**:
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
akihabaraLights — Determinar o navegador
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.
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**:
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:
- Abrir o terminal do macOS
- Colar e executar um comando codificado em Base64 que é recuperado dinamicamente da função
**jadeCode()**on-chain
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.









