Bitget affirme que des identifiants volés ont transformé une faille d’un outil de sécurité en une brèche de 388 millions de dollars dans ses portefeuilles

La plateforme d’échange de cryptomonnaies Bitget affirme qu’un pirate a exploité une vulnérabilité zero-day dans un produit de sécurité tiers dont le nom n’a pas été révélé. Il aurait ainsi obtenu des accès privilégiés aux systèmes internes et dérobé environ 388 millions de dollars.

Selon les premiers éléments de l’enquête menée par la plateforme, l’intrusion ne repose pas sur le vol de clés privées de portefeuilles. Le pirate aurait plutôt obtenu des identifiants internes de haut niveau, puis détourné les procédures administratives légitimes de Bitget pour soumettre de fausses demandes de retrait.

Des fonds ont été dérobés dans une partie de l’infrastructure de portefeuilles chauds et tièdes de la plateforme. Les portefeuilles froids hors ligne n’ont pas été touchés.

Des identifiants volés ont permis d’accéder aux services de portefeuille

Gracy Chen, PDG de Bitget, a qualifié la vulnérabilité du produit tiers de zero-day : au moment de son exploitation, aucun correctif fourni par l’éditeur n’était disponible. Bitget n’a révélé ni le nom du produit, ni celui de son éditeur, ni les versions concernées.

En l’absence de ces informations, plusieurs questions techniques restent sans réponse. On ignore quel type de vulnérabilité a été exploité, si l’authentification a été contournée et comment la faille a permis d’accéder aux identifiants privilégiés de Bitget.

Aucun identifiant CVE n’a été annoncé. Par conséquent, rien ne permet non plus de confirmer si la vulnérabilité figure dans le catalogue Known Exploited Vulnerabilities de la Cybersecurity and Infrastructure Security Agency des États-Unis.

L’exploitation aurait donné accès à un système de gestion interne et à des identifiants de haut niveau. Ceux-ci ont ensuite permis à l’intrus d’accéder aux services backend liés aux transactions des portefeuilles.

Bitget avait déjà indiqué qu’un composant critique de son backend de portefeuille avait été compromis et manipulé pour générer de fausses données de transaction et déclencher des approbations. Les dernières informations précisent le point d’entrée initial : une vulnérabilité dans un logiciel fourni par un prestataire externe spécialisé dans la sécurité.

L’attaquant devait toutefois encore suivre le processus de transaction de Bitget. Les transferts devaient être approuvés avant leur signature ; l’accès à un seul composant de portefeuille ne suffisait donc pas nécessairement à déplacer les fonds.

De petits transferts de test ont précédé le vol principal

Les faux retraits ont commencé le 24 septembre. Au lieu de tenter immédiatement un transfert important, le pirate a d’abord testé la procédure au moyen de deux petites transactions, à 18 h 31 UTC.

Les deux transferts sont restés sous le seuil des contrôles de risque de Bitget et n’ont déclenché aucune alerte. Les retraits plus importants ont commencé environ 30 minutes plus tard.

L’utilisation d’identifiants internes valides a joué un rôle central dans l’attaque. Le backend lié aux portefeuilles a accepté les demandes de retrait comme légitimes et les a soumises au processus d’approbation habituel. Selon Chen, l’activité était conçue pour ressembler à des opérations administratives ordinaires, réduisant ainsi le risque que les contrôles automatisés ou les employés la repèrent comme malveillante.

L’attaquant aurait également tenté d’effacer les traces de l’opération. On ignore jusqu’où il est allé dans cette tentative et si les enquêteurs ont pu récupérer les éléments supprimés.

Ce mode opératoire aide à comprendre pourquoi les protections des portefeuilles n’ont pas bloqué les transferts. L’assaillant n’a pas eu besoin de falsifier une connexion externe ni de dérober directement des clés cryptographiques. Il a plutôt agi au moyen d’identités internes de confiance et soumis des commandes dans un format attendu par les systèmes de Bitget.

Les contrôles reposant principalement sur le montant des transactions, la validité des identifiants ou un comportement administratif en apparence normal peuvent être mis en difficulté dans ce type de scénario. Les deux premiers transferts ont permis de vérifier si ces contrôles interviendraient avant que l’attaquant ne tente de déplacer des sommes plus importantes.

Les portefeuilles chauds et tièdes ont subi les pertes

Les actifs dérobés provenaient d’une partie des portefeuilles chauds et tièdes de Bitget. Ceux-ci sont plus accessibles que les portefeuilles hors ligne, car ils servent à assurer la liquidité opérationnelle et les retraits.

Bitget affirme que ses portefeuilles froids n’ont pas été touchés. La société indique également n’avoir trouvé aucun élément suggérant que des clés privées de portefeuille ont été compromises, même si l’enquête se poursuit.

Cette distinction est importante pour évaluer la portée de l’incident. Une clé privée volée pourrait permettre à un attaquant de signer des transactions sans passer par les systèmes internes de la plateforme. Dans le cas présent, l’attaque décrite reposait sur l’accès à l’infrastructure backend de Bitget et à ses mécanismes d’approbation.

La plateforme affirme que les soldes des comptes clients restent intacts. Son Protection Fund, une réserve destinée à couvrir les pertes liées à des incidents de sécurité, prendra en charge les actifs manquants.

Les utilisateurs n’ont pas à réinitialiser leurs identifiants, à transférer leurs fonds ni à prendre d’autres mesures correctives. Rien n’indique pour l’instant que des comptes clients individuels aient servi de point d’entrée.

Les retraits de Bitcoin ont repris lundi. Ceux des autres actifs doivent être rétablis progressivement d’ici le 2 octobre.

Systèmes isolés pendant que l’éditeur travaille sur la faille

Bitget a prévenu l’éditeur du produit, dont le nom n’a pas été révélé, et désactivé la fonctionnalité concernée. La plateforme n’a pas précisé si le fournisseur avait publié un correctif ou une autre solution définitive.

Faute de connaître le nom du produit, les versions concernées ou l’identifiant de la vulnérabilité, les autres organisations ne peuvent pas déterminer si elles utilisent la même technologie vulnérable. Elles ne peuvent pas non plus vérifier de manière indépendante si une mise à jour est disponible.

Bitget a isolé les systèmes concernés par l’incident, révoqué les identifiants internes et les a remplacés. La plateforme a également restreint les accès internes, instauré des vérifications indépendantes pour les retraits et renforcé la surveillance des activités anormales.

La plateforme prévoit de réévaluer la manière dont elle sélectionne, évalue et déploie les produits de sécurité tiers. L’incident met en évidence un risque complexe lié à la chaîne d’approvisionnement : un logiciel installé pour protéger une infrastructure sensible peut lui-même devenir une porte d’entrée vers cet environnement.

Une validation indépendante des retraits pourrait réduire le risque lié à la compromission d’une couche de gestion, en particulier si le second contrôle s’appuie sur des identifiants, des données de télémétrie et des frontières de confiance distincts. Bitget n’a pas dévoilé l’architecture de ses nouveaux contrôles.

Mandiant et SlowMist participent à l’enquête. Bitget prévoit de publier un rapport officiel sur l’incident cette semaine. Celui-ci pourrait préciser quel composant a été exploité, comment les identifiants ont été obtenus et dans quel ordre les approbations ont eu lieu.

L’attribution à la Corée du Nord reste à confirmer

Bitget avait précédemment indiqué que des pirates nord-coréens étaient probablement responsables de l’attaque. Chen a déclaré à The Hacker News que la plateforme continue de soupçonner le même acteur, mais qu’elle ne souhaitait pas nommer de groupe en particulier avant la publication du rapport sur l’incident.

TRM Labs a relevé des recoupements entre les actifs volés et des portefeuilles utilisés auparavant pour blanchir des fonds issus de vols attribués à la Corée du Nord. La société d’analyse de la blockchain a estimé que l’activité pointait vers TraderTraitor, sans toutefois établir d’attribution définitive.

Le simple recoupement de transactions ne permet pas d’établir qui a mené l’intrusion. L’utilisation d’infrastructures de blanchiment, de services intermédiaires et d’adresses communes peut étayer une évaluation, mais ne prouve pas nécessairement que les mêmes opérateurs ont réalisé la compromission initiale.

Le transit des fonds par des bridges et des services d’échange inter-chaînes complique encore le traçage. Ces services peuvent modifier le réseau et l’actif concernés, ce qui rend insuffisante une simple surveillance des transferts directs.

Adresses de réception et expositions indirectes à surveiller

Bitget a publié les adresses de réception le 25 septembre, ainsi qu’un tableau de suivi en temps réel et un portail de récupération. La plateforme a demandé aux plateformes d’échange, aux dépositaires, aux émetteurs de stablecoins, aux bridges et aux autres opérateurs d’infrastructure de signaler toute activité liée.

Les adresses communiquées sont les suivantes :

• Réseaux Ethereum et EVM : 0x770b10b273fc44fe9197d6bf20f145c2e98463ee
• XRP : rwNhefsz1UQEusxhCvHip3RANinWi4CTck
• Zcash : t1WgMdtND8NF7NDUuYmq8MpMj1NTCXkMDVG
• TRON : TBWNguTTgezw9dVorX441C6nDrZpRxYwKD

TRM recommande aux acteurs du secteur des cryptomonnaies de ne pas limiter leurs contrôles aux dépôts envoyés directement depuis ces adresses. Les enquêteurs s’attendent à ce que les fonds volés transitent par plusieurs portefeuilles intermédiaires après avoir circulé d’un réseau à l’autre.

Les équipes de conformité devraient donc surveiller les adresses liées en aval et les expositions indirectes, en particulier après le passage par un bridge ou un service d’échange inter-chaînes. Un dépôt séparé du vol initial par plusieurs transactions est plus probable qu’un transfert direct depuis une adresse de réception rendue publique.

Pour les autres organisations susceptibles d’utiliser le produit de sécurité vulnérable, aucune mesure propre à ce produit n’est disponible pour le moment. L’identité de l’éditeur, les versions concernées, l’état d’avancement d’un correctif et les indicateurs techniques n’ont pas été communiqués.