Piratage : 64 000 mineurs Bitcoin détournés vers OCEAN, 13 EH/s redirigés

Environ 64 000 machines de minage Bitcoin ont vu leur paramétrage de pool modifié sans autorisation à partir de 20 h heure centrale américaine le 14 novembre, redirigeant quelque 13 EH/s de puissance de calcul vers le pool OCEAN et pointant les récompenses vers une adresse Bitcoin contrôlée par l'attaquant. Aucun bloc n'a été trouvé pendant la fenêtre d'attaque : le pirate n'a rien touché, et les opérateurs victimes n'encaissent pas le temps de hashage détourné. L'hébergeur CoreX Hosting a publiquement signalé l'incident, qu'il dit terminé le 15 novembre, le hashrate détourné étant tombé à environ 100 PH/s, soit plus de 99 % de recul. Le point d'entrée présumé, non confirmé, est le logiciel de gestion de flotte Luxor Commander.

Ce qui s'est passé

CoreX Hosting, prestataire d'hébergement de mineurs, indique que les machines de ses clients se sont mises à miner sur un autre pool et avec une autre adresse de paiement, sans que les opérateurs y aient consenti. L'alerte publique de l'hébergeur a été reprise par Cointribune, Crypto Briefing et Blockonomi, avec la même échelle : environ 64 000 ASIC, autour de 13 EH/s. Wu Blockchain a diffusé le même chiffre dans la journée sur X.

Le tableau de bord public d'OCEAN a reflété l'arrivée en temps réel : le hashrate affiché a bondi jusqu'à environ 50 EH/s au pic, avant de retomber vers 40 EH/s puis au niveau antérieur à mesure que les machines étaient récupérées ou mises hors ligne. OCEAN n'a pas publié de communiqué liant ce pic à l'incident. Le pool est ici la destination du détournement, pas sa cause.

L'adresse de paiement contrôlée par l'attaquant n'a reçu aucun BTC, parce qu'aucun bloc n'a été trouvé pendant la période. La perte est entièrement en manque à gagner pour les opérateurs : le temps de hashage pendant lequel leurs machines ont miné pour le pirate n'a pas été facturé sur leur propre pool.

Mécanique

L'attaque ne vise ni les ASIC eux-mêmes ni le protocole OCEAN. Elle modifie les champs URL du pool et adresse de récompense dans la configuration des machines — des paramètres que la couche de supervision de flotte peut écrire légitimement. Plusieurs opérateurs touchés mettent en cause le logiciel Commander de Luxor, utilisé pour gérer des parcs d'ASIC à distance. Un opérateur dit que l'ensemble de son installation a basculé d'un coup. Luxor n'a pas confirmé de faille et aucun identifiant CVE n'est diffusé.

Si cette hypothèse se confirme, le périmètre compromis est la plateforme de gestion, pas la chaîne Bitcoin ni les machines. Un accès valide au plan de contrôle suffit à reconfigurer la flotte, car ce plan dispose déjà des droits d'écriture. Des signalements d'opérateurs décrivent des changements de pool non autorisés dans les jours précédents, cohérents avec une intrusion progressive de ce type.

Impact

Perte financière directe du pirate : 0 BTC. Perte des opérateurs victimes : du temps de hashage, non récupérable. À hashrate réseau d'environ 1,0 ZH/s et avec une subvention de bloc de 3,125 BTC plus frais, 13 EH/s représente environ 1,3 % de la puissance mondiale. Sur une fenêtre d'une dizaine d'heures à cette part, l'espérance mathématique est inférieure à un bloc : à l'échelle de chaque flotte victime, l'ordre de grandeur de la perte est le nombre de blocs attendus ramené à la part individuelle, non un montant à sept chiffres.

Pour OCEAN, le dommage est de réputation. Le pic affiché sur son tableau de bord ressemblait à une croissance soudaine. C'était, en réalité, l'afflux non consenti de mineurs appartenant à des tiers.

Chiffres

• Machines piratées : environ 64 000
• Hashrate détourné : environ 13 EH/s
• Pic sur le tableau de bord OCEAN : environ 50 EH/s (contre 25–30 EH/s en temps normal)
• Début de l'attaque : vers 20 h, heure centrale US, 14 novembre 2026
• Fin signalée (CoreX) : hashrate détourné ramené à environ 100 PH/s le 15 novembre, soit > 99 % de recul
• Blocs trouvés par l'adresse pirate : 0
• Récompense versée à l'adresse pirate : 0 BTC

Que faire côté opérateur

1. Vérifier, machine par machine, les champs URL du pool et adresse de paiement dans la configuration embarquée, sans faire confiance à l'affichage du tableau de bord de gestion.
2. Faire tourner les identifiants et sessions actives du logiciel de gestion (en particulier Luxor Commander), exiger un MFA frais.
3. Isoler le plan de contrôle sur un réseau d'administration (VPN ou liste blanche d'IP) et fermer ses ports exposés sur Internet.
4. Ajouter des alertes de dérive de configuration : toute modification d'URL de pool ou d'adresse de paiement doit déclencher une notification.
5. Reconcilier hashrate attendu / hashrate délivré sur votre pool pour la fenêtre du 14 au 15 novembre : l'écart quantifie précisément les revenus à documenter si votre contrat d'hébergement couvre ce risque.

Contexte

Les détournements de flotte de mineurs à l'échelle d'exahashs sont rares. Les affaires habituelles de sécurité minière concernent du malware firmware sur des ASIC infectés ou des Ponzi de cloud mining, pas une reconfiguration coordonnée de dizaines de milliers de machines réelles. L'épisode dont ce incident se rapproche le plus est la vague de 2022 contre des parcs Antpool et viabtc, menée par credential stuffing sur les tableaux de bord de supervision. Ce qui est nouveau en 2026, si l'hypothèse Luxor Commander se confirme, c'est qu'un seul produit de gestion se trouve entre l'attaquant et quelques points de pourcentage du hashrate mondial, derrière une seule authentification.

OCEAN a par ailleurs connu, autour du soft fork BIP-110 d'août 2026, un incident de routage de hashrate lié à sa propre configuration, que le pool a reconnu et indemnisé à hauteur d'environ 0,3 BTC par mineur affecté. C'était une affaire interne au pool, distincte de ce détournement externe. Les deux, lus ensemble, rappellent que la pile fine entre mineur et chaîne — logiciel de pool, SaaS de gestion de flotte, API d'hébergement — est une surface d'attaque au moins aussi exposée que les ASIC.