Le responsable de la recherche chez Galaxy, Alex Thorn, a identifié ce qui semble être une quatrième vague organisée de vol de Bitcoin impliquant des graines générées par le firmware Coldcard affecté. Pendant la période d'environ 2,5 heures entre les blocs 960 778 et 960 792, les chercheurs ont observé 218 transactions impliquant 462 adresses de victimes présumées, 216 nouvelles destinations et 388,92748828 BTC. Des transactions similaires seraient restées dans le mempool, tandis que les transactions confirmées avaient le remplacement par frais (RBF) activé.
Cette activité suggère que la divulgation publique et les mises à jour d'urgence du firmware n'ont pas éliminé le risque lié aux graines générées précédemment. Le taux de balayage observé a atteint 13,8 par bloc, contre 0,3 pendant une fenêtre de contrôle avant l'incident, soit une augmentation d'environ 45 fois. Néanmoins, la « quatrième vague » reste une classification de recherche basée sur des modèles en chaîne. Les preuves n'identifient pas de manière concluante les attaquants ni ne prouvent que la même entité a mené chaque vague.
Points clés à retenir
- La quatrième vague présumée impliquait 218 transactions, 462 adresses de victimes présumées, 216 nouvelles destinations et 388,92748828 BTC.
- La concentration de l'activité et l'augmentation d'environ 45 fois du taux de balayage soutiennent l'interprétation d'une exploitation systématique plutôt que d'une migration de portefeuille ordinaire.
- Des transferts principalement 1:1, une réutilisation minimale des destinations et des mouvements vers des adresses de deuxième saut peuvent indiquer une stratégie de gestion des fonds plus dispersée.
- La mise à jour du firmware Coldcard ne répare pas une graine faible existante ; les utilisateurs potentiellement affectés doivent générer une nouvelle graine via un processus corrigé et migrer leurs actifs.
Que s'est-il passé pendant la quatrième vague d'attaque présumée ?
Selon la surveillance de Thorn, le dernier groupe de transactions est apparu entre les blocs Bitcoin 960 778 et 960 792. Sur environ 2,5 heures, les chercheurs ont identifié 218 transactions partageant des caractéristiques associées à l'incident Coldcard en cours. Les transactions impliquaient 462 adresses classées comme adresses de victimes présumées, 216 nouvelles adresses de destination et 388,92748828 BTC. Des transactions similaires seraient toujours en attente de confirmation dans le mempool, ce qui suggère que la fenêtre observée pourrait ne pas représenter la fin de l'activité.
Les transactions précédemment confirmées avaient également activé RBF, ce qui permet de remplacer une transaction Bitcoin non confirmée par une version avec des frais plus élevés. RBF est une fonctionnalité normale du réseau et ne démontre pas indépendamment une intention malveillante. Cependant, dans le contexte d'un balayage massif en cours, son utilisation suggère que celui qui a initié les transactions gérait activement la priorité de confirmation et pouvait augmenter les frais si des transactions concurrentes apparaissaient.
Les chiffres d'adresses et de valeurs rapportés nécessitent une interprétation prudente. Une « adresse de victime » est une adresse classée par les chercheurs en fonction de son comportement de transaction et de son lien avec la limite du firmware Coldcard concerné ; elle ne représente pas nécessairement un utilisateur individuel. Un portefeuille peut contrôler plusieurs adresses, et une transaction peut dépenser plusieurs entrées. De même, les 388,92748828 BTC observés dans cette fenêtre ne doivent pas être automatiquement ajoutés aux estimations de pertes antérieures tant que les chercheurs n'ont pas confirmé que les adresses, les entrées et les fonds transférés ne chevauchent pas les groupes précédents.
La preuve la plus importante est l'intensité et la cohérence de l'activité. Les chercheurs ont calculé 13,8 balayages par bloc pendant la période surveillée, contre 0,3 par bloc dans une fenêtre de contrôle avant l'incident. Une augmentation aussi forte est difficile à expliquer uniquement par des utilisateurs indépendants réagissant à un avertissement de sécurité. Les transactions ne contenaient également aucune entrée antérieure à la limite du firmware Coldcard concerné, renforçant l'association entre les fonds balayés et les graines créées sous un firmware affecté.
L'évaluation de Galaxy repose donc sur le poids combiné du calendrier, de la sélection des adresses, de la construction des transactions et du comportement des destinations. Aucune caractéristique n'est concluante : les utilisateurs légitimes peuvent activer RBF, générer de nouvelles adresses de réception ou migrer des fonds simultanément après un avertissement officiel. L'interprétation d'une attaque organisée devient plus convaincante lorsque ces caractéristiques apparaissent avec une régularité inhabituelle sur des centaines d'adresses liées au firmware.
Cependant, l'analyse en chaîne ne peut pas révéler directement qui contrôle les clés privées. Un attaquant pourrait changer de stratégie de transaction entre les vagues, tandis que plusieurs opérateurs pourraient exploiter indépendamment la même faiblesse après qu'elle soit devenue publique. Galaxy a par conséquent traité les groupes comme des vagues d'attaque coordonnées sans prétendre que chaque vague a été définitivement attribuée à la même entité.
Que révèle la nouvelle topologie des transactions ?
La quatrième vague présumée présentait une structure principalement 1:1 dans laquelle les fonds des adresses de victimes étaient envoyés vers de nouvelles destinations distinctes. Une seule destination aurait reçu deux balayages, et aucune adresse de regroupement centrale évidente n'est apparue pendant la période de surveillance initiale. Certains des fonds ont ensuite été déplacés vers des adresses de deuxième saut.
Cette structure diffère des empreintes digitales les plus claires observées précédemment dans l'incident. L'analyse de Galaxy a révélé que les deux premières vagues majeures utilisaient de manière répétée des frais fixes de 30 sat/vB et des schémas de regroupement similaires, ce qui soutient la possibilité d'un opérateur ou d'un outil d'attaque partagé. Une vague ultérieure a évolué vers des transferts individuels et des destinations dispersées. Sur les trois premières vagues identifiées, les rapports liés à Galaxy ont estimé le montant affecté à 1 367,05 BTC provenant de 4 585 adresses, tout en soulignant que les différences dans les empreintes digitales des transactions empêchaient une attribution définitive à un seul attaquant.
Une explication est qu'un attaquant a reconnu que les adresses de collecte centralisées rendaient les transactions précédentes plus faciles à regrouper et à surveiller, puis a adopté de nouvelles destinations et des sauts supplémentaires pour réduire la visibilité immédiate. Une autre est que la divulgation de la faiblesse a permis à des attaquants imitateurs de rechercher les graines vulnérables restantes en utilisant des outils développés indépendamment. Les deux interprétations sont cohérentes avec les schémas de transaction, mais aucune ne peut être prouvée par la seule topologie.
Les transferts de deuxième saut ne doivent pas être automatiquement décrits comme du blanchiment. Ils peuvent séparer l'extraction initiale de la garde à long terme, préparer les fonds pour une consolidation ultérieure, tester si les adresses ont été signalées, ou acheminer les actifs vers des services externes. Les enquêteurs devront déterminer si les adresses de deuxième saut convergent éventuellement ou interagissent avec des entités identifiables. À ce stade, la conclusion défendable est que les dernières transactions montrent un balayage systématique combiné à une gestion des fonds de plus en plus dispersée.
L'évolution des attaques modifie également le risque pratique pour les utilisateurs. Galaxy a identifié une première rafale au cours de laquelle 1 082,65 BTC ont été balayés de 1 196 adresses en environ 41 minutes. L'activité ultérieure a ciblé des adresses supplémentaires et des soldes plus petits en utilisant des structures différentes. Cela peut indiquer une transition entre l'extraction rapide de portefeuilles visibles à haute valeur et le balayage continu de la population restante de graines faibles.
Une campagne d'énumération continue peut revisiter le même espace de graines vulnérables et cibler des soldes plus petits à mesure que les outils d'attaque s'améliorent ou que les coûts de transaction changent. La divulgation publique peut également créer une course entre les propriétaires légitimes tentant de migrer et les attaquants tentant de reconstruire leurs clés. La quatrième vague suspectée est donc importante non seulement en raison de sa valeur observée, mais parce qu'elle indique que les graines non migrées peuvent rester exploitables après que les vols initiaux les plus visibles ont pris fin.
La cause racine technique : aléatoire prévisible
L'équipe d'ingénierie et de sécurité Bitcoin de Block a retracé le problème sous-jacent à l'intégration du firmware Coldcard avec son chemin de génération de nombres aléatoires. Selon Block, une configuration destinée à désactiver l'implémentation matérielle du RNG de MicroPython a provoqué le repli d'une bibliothèque externe sur le générateur logiciel déterministe Yasmarang plutôt que sur le RNG matériel STM32 attendu. La bibliothèque vérifiait si une macro de configuration existait, mais pas si elle était activée.
Pour les firmwares Mk2 et Mk3 affectés, le générateur de repli pouvait être initialisé en utilisant les métadonnées de l'appareil et l'état de synchronisation sans recevoir d'entropie cryptographiquement sécurisée via le chemin vulnérable. Si un attaquant pouvait déterminer ou contraindre suffisamment l'UID de l'appareil, l'état du minuteur et les appels précédents de nombres aléatoires, les sorties candidates pourraient potentiellement être reproduites hors ligne. Sur les appareils ultérieurs, une entrée d'élément sécurisé a été ajoutée, mais Block a rapporté que seulement quatre octets du digest résultant atteignaient la fonction de réensemencement, limitant l'état différencié de manière sécurisée à pas plus de (2^{32}) possibilités sous les hypothèses pertinentes.
Passer une sortie aléatoire faible à travers un hachage cryptographique ne résout pas le problème. Un hachage peut rendre les résultats apparemment uniformément distribués, mais il ne peut pas créer plus de secrets possibles que ce qui existait dans l'espace d'entrée d'origine. Un attaquant peut énumérer les graines candidates, dériver leurs adresses Bitcoin et comparer ces adresses avec la blockchain publique. Une correspondance fournit un signal de validation qui peut révéler la clé privée correspondante sans accès physique au portefeuille.
Ce n'est pas une défaillance du système de signature de Bitcoin ou des normes de graines. La vulnérabilité concerne l'aléatoire utilisé avant la création des clés privées. Une fois qu'une graine faible existe, un appareil hors ligne, isolé ou physiquement sécurisé ne peut pas empêcher une autre partie de reconstruire le même secret par calcul.
Block a décrit son rapport comme une évaluation technique précoce publiée alors que l'exploitation semblait active et a noté qu'il n'avait pas terminé les tests empiriques de chaque chemin d'attaque possible. Ses conclusions doivent donc être considérées en parallèle avec l'enquête de Coinkite et ses conclusions techniques finales. Même avec cette réserve, le problème de sécurité central est clair : les protections appliquées après la génération de clés ne peuvent pas restaurer l'entropie qui était absente lors de la création de la graine.
Pourquoi la mise à jour du firmware ne suffit-elle pas ?
Les directives officielles de Coinkite distinguent la prévention de la génération de seeds vulnérables à l'avenir de la réparation d'une seed existante. Un firmware corrigé modifie la façon dont les nouveaux secrets sont générés, mais il ne peut pas modifier une phrase mnémonique créée sous une version affectée. Importer cette phrase mnémonique dans un firmware mis à jour ou dans un autre portefeuille matériel recrée les mêmes clés privées et préserve le risque sous-jacent. Une remédiation complète nécessite de générer une nouvelle seed véritablement aléatoire via un processus corrigé et de transférer les fonds sur la chaîne.
Coinkite identifie les seeds Mk2 et Mk3 générées sur les versions de firmware 4.0.1 à 4.1.9 comme étant affectées. Il conseille également la migration pour les seeds Mk4 et Mk5 créées avant le firmware standard 5.6.0 ou le firmware Edge 6.6.0X, ainsi que pour les seeds Coldcard Q créées avant le firmware standard 1.5.0Q ou le firmware Edge 6.6.0QX. La société décrit l'impact sur les appareils Mk4, Mk5 et Q comme moins grave que sur les appareils Mk2 et Mk3 affectés, mais toujours sérieux. Les propriétaires de Mk2 et Mk3 peuvent générer des seeds de remplacement après avoir installé la version 4.2.0 ou ultérieure.
Une entropie véritablement indépendante peut fournir des exceptions limitées. Coinkite déclare qu'au moins 50 lancers de dés équitables, indépendants et privés peuvent contribuer à 128 bits d'entropie, tandis que 99 lancers ou plus contribuent à environ 256 bits. Les utilisateurs qui ne peuvent pas confirmer avec certitude comment les lancers ont été générés et intégrés ne devraient pas se fier à cette exception. Une phrase de passe BIP-39 forte peut créer une barrière supplémentaire, mais Coinkite recommande toujours la migration car la phrase de passe ne répare pas la seed d'origine. Un code PIN Coldcard n'est pas une phrase de passe BIP-39 et n'empêche pas les fonds de la blockchain d'être déplacés si les clés privées sont reconstruites.
Que doivent faire les utilisateurs de Coldcard maintenant ?
Les utilisateurs potentiellement affectés doivent déterminer le modèle de l'appareil et la version du firmware utilisée lors de la génération initiale de la seed actuelle. La version actuelle du firmware seule est insuffisante si la seed a été créée sur un ancien Coldcard ou importée depuis un autre appareil. Les vérifications et téléchargements du firmware doivent être effectués uniquement via les canaux officiels de Coinkite, sans suivre les liens fournis par des comptes de support non sollicités, des messages sur les réseaux sociaux ou des services de récupération.
Les utilisateurs dans une plage affectée doivent installer le firmware corrigé applicable et générer une toute nouvelle seed. Ils doivent enregistrer en toute sécurité la nouvelle sauvegarde, vérifier l'empreinte du portefeuille et l'adresse de réception directement sur l'écran du matériel, et envoyer une petite transaction de test avant de transférer le solde restant. Restaurer l'ancienne phrase mnémonique dans un nouvel appareil ou continuer à l'utiliser après une mise à jour du firmware ne résout pas la vulnérabilité.
L'incident crée également une opportunité de fraude secondaire. Les utilisateurs ne doivent jamais divulguer les mots de la seed, les clés privées, les phrases de passe, les séquences de lancers de dés ou les sauvegardes du portefeuille à quiconque prétendant représenter Coldcard, Coinkite, Galaxy, une bourse, les forces de l'ordre ou une société de récupération. Le personnel de support légitime n'a pas besoin de ces secrets pour vérifier le firmware ou expliquer les procédures de migration.
Les utilisateurs de multisignature doivent évaluer combien de clés affectées participent au seuil de dépense. Si suffisamment de clés vulnérables peuvent être reconstruites, la protection multisignature peut également échouer. Remplacer les clés sans affaiblir le seuil ou exposer inutilement les scripts du portefeuille peut nécessiter une migration plus soigneusement planifiée, en particulier pour les portefeuilles de grande valeur ou gérés institutionnellement.
Implications plus larges pour la sécurité des portefeuilles matériels
L'incident ne démontre pas que tous les portefeuilles matériels ou systèmes de garde autonome sont dangereux. Il montre que la sécurité du portefeuille dépend de l'ensemble du cycle de vie des clés : génération d'entropie, configuration du firmware, revue des dépendances, sauvegarde de la seed, vérification des transactions et migration éventuelle. Les étiquettes telles que « air-gapped », « hors ligne », « open source » ou « protégé par élément sécurisé » décrivent des défenses individuelles plutôt que la sécurité du système complet.
Le firmware open source permet une revue indépendante mais ne garantit pas que les erreurs d'implémentation seront découvertes avant l'exploitation. Une assurance plus forte nécessite des builds reproductibles, des tests d'entropie, une revue de code à travers les limites des bibliothèques, des vecteurs de test déterministes et un comportement de fermeture en cas d'échec lorsque le hasard sécurisé n'est pas disponible. Un portefeuille peut sinon continuer à recevoir des fonds et signer des transactions valides tout en dissimulant une faiblesse qui existe depuis la création de la seed.
La leçon centrale est celle de la provenance de la seed. Déplacer une ancienne phrase mnémonique vers un matériel plus récent améliore son environnement de stockage mais ne change pas sa sécurité mathématique. Les portefeuilles matériels protègent la façon dont les clés privées sont stockées et utilisées ; ils ne peuvent pas rendre rétroactivement imprévisible une seed prévisible.
Conclusion
La quatrième vague d'attaques suspectée contre Coldcard indique que la fenêtre de risque reste ouverte. Le calendrier compressé, l'augmentation d'environ 45 fois du taux de balayage, la limite d'entrée liée au firmware et la structure régulière des transactions soutiennent l'évaluation de Galaxy d'une activité systématique. Les identités des attaquants et la relation entre les différentes vagues, cependant, restent non confirmées.
Pour les utilisateurs potentiellement concernés, la priorité est de vérifier quand et comment leur seed actuelle a été créée. Un firmware corrigé peut protéger les secrets nouvellement générés, mais il ne peut pas réparer une seed faible existante. Le remède efficace est de générer une nouvelle seed via un processus corrigé et de migrer les actifs en toute sécurité.
Avertissement de risque : Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil en investissement, juridique ou en cybersécurité. Les utilisateurs doivent vérifier les versions du firmware et les procédures de migration via la documentation officielle de Coinkite et demander une assistance qualifiée pour les configurations de portefeuille complexes.
