exploit
Bitget : SlowMist trace le hack à 388 M$ à une intrusion du 31 août, 24 jours avant les retraits
Post-mortem : faille zero-day dans un produit de sécurité tiers le 31 août, extraction d'un mot de passe de base, 24 jours de latence avant les retraits frauduleux.
Le cabinet SlowMist fait remonter le vol de 387,5 millions de dollars sur les hot wallets de Bitget au 31 août 2026, soit 24 jours avant les retraits frauduleux détectés le 24 septembre. Le point d'entrée : une faille zero-day dans un produit de sécurité tiers déployé sur l'infrastructure de l'exchange. La chronologie est confirmée par le rapport de Mandiant cité par Crypto Times et Bitcoin.com News.
Ce que dit le post-mortem
- 31 août 2026 : première activité malveillante loggée. Un service d'un produit de sécurité tiers, tournant sur un nœud interne, est compromis via une vulnérabilité zero-day — non patchée à ce moment.
- Extraction d'un secret : l'attaquant fait tourner un script caché qui lit une variable d'environnement contenant le mot de passe d'une base de données de gestion des portefeuilles.
- Persistance latérale : des scripts cachés similaires sont détectés a posteriori sur deux autres nœuds, le 23 septembre et le 25 septembre.
- 24 septembre : l'attaquant obtient un accès privilégié aux appliances de sécurité tierces A et B, dépose un web shell sur l'appliance B, ouvre un canal C2 (Command-and-Control), et bascule latéralement vers le serveur du job wallet en production.
- Retraits frauduleux : un outil sur mesure fabrique des requêtes de retrait valides pour les contrôles internes de Bitget. Les transferts sortent comme s'ils étaient légitimes.
Ce qui n'a pas été volé
Point important, souligné par SlowMist : aucune clé privée n'a été extraite. L'attaquant n'a pas eu besoin de signer directement les transactions — il a soumis des ordres de retrait falsifiés que la couche de validation de Bitget a acceptés comme valides. C'est la même famille d'attaques que celles qui ont visé les exchanges centralisés depuis 2024 (DMM Bitcoin, Phemex, WazirX) : compromettre le pipeline de retrait, pas la clé.
Attribution — prudente
- Bitget CEO Gracy Chen évoque « des adresses IP et un modèle qui correspondent à des hackers nord-coréens ».
- Elliptic qualifie le lien avec la RPDC de « hautement probable ».
- SlowMist ne se prononce pas dans son rapport sur l'identité de l'acteur, s'en tenant aux TTP techniques.
- Aucun gouvernement n'a formellement désigné l'auteur à ce jour. Ni FBI IC3 ni OFAC n'ont publié d'avis.
Nous rapportons les attributions telles que revendiquées par les firmes nommées, sans les traiter comme des faits établis.
Impact et trésorerie
Bitget avait constitué avant l'attaque un fonds de protection annoncé à 300 millions de dollars ; son encours réel juste avant le sinistre était de ~464 M$, selon SlowMist. Le vol représente ~83 % de ce fonds si l'exchange décide de couvrir intégralement les pertes utilisateurs. Aucun communiqué formel de Bitget n'a détaillé la répartition du remboursement à l'heure de publication.
Sur la trace on-chain, l'attaquant a déplacé les fonds sur Zcash, Chainflip et CoW Protocol dans les jours qui ont suivi. L'enquêteur ZachXBT signale sur X une bascule progressive vers la pool Ironwood de Zcash — environ 2 700 ZEC (~3,8 M$) shieldés le 30 septembre — après que Near Intents a bloqué 50 M$ de swaps grâce à son système anti-blanchiment SHIELD.
À surveiller
- Nom du produit de sécurité tiers. SlowMist et Mandiant n'ont pas encore publié le vendor. Le CVE éventuel, une fois attribué, sera l'élément critique pour les autres exchanges qui utilisent le même produit.
- Publication d'IOC. Si les IP C2 et les hashes des scripts cachés sortent, les autres plateformes pourront chasser dans leurs propres logs à partir du 31 août.
- Discipline des routeurs cross-chain. Chainflip et CoW Protocol ont routé une partie des fonds. Leur position publique sur le filtrage des flux Bitget est le prochain signal.
Précédent
Plusieurs post-mortem d'exchange majeurs des derniers dix-huit mois — DMM Bitcoin, Phemex, WazirX — documentent la même famille d'attaques : compromission de la couche qui autorise les retraits, pas de la clé privée elle-même. Le pattern devient reconnaissable : accès initial via un composant tiers, patience opérationnelle (24 jours pour Bitget), retrait via un outil qui fabrique des ordres légitimes du point de vue de l'exchange. La question posée par cette série n'est plus « comment sécuriser les clés privées », mais « comment durcir le pipeline qui autorise les retraits », alors même que les clés restent inviolées.