Quatrième vague d’attaques suspectée de Coldcard : pourquoi 462 adresses sont-elles encore balayées ?

Alex Thorn, responsable de la recherche chez Galaxy, a identifié ce qui semble être une quatrième vague organisée de vols de Bitcoin impliquant des seeds 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 suspectées, 216 nouvelles destinations et 388,92748828 BTC. Des transactions similaires seraient restées dans le mempool, tandis que les transactions confirmées avaient activé le remplacement par frais (RBF).

Cette activité suggère que la divulgation publique et les mises à jour d'urgence du firmware n'ont pas éliminé le risque associé aux seeds précédemment générées. Le taux de balayage observé a atteint 13,8 par bloc, contre 0,3 pendant une fenêtre de contrôle pré-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 on-chain. 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

• La quatrième vague suspectée a impliqué 218 transactions, 462 adresses de victimes suspecté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 ordinaire de portefeuille.
• Des transferts principalement 1:1, une réutilisation minimale des destinations et des mouvements vers des adresses de second saut peuvent indiquer une stratégie de gestion des fonds plus dispersée.
• La mise à jour du firmware Coldcard ne répare pas une seed faible existante ; les utilisateurs potentiellement affectés doivent générer une nouvelle seed via un processus corrigé et migrer leurs actifs.

Que s'est-il passé lors de la quatrième vague d'attaque suspecté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 suspectées, 216 nouvelles adresses de destination et 388,92748828 BTC. Des transactions similaires attendraient toujours confirmation dans le mempool, suggérant que la fenêtre observée ne représente peut-être pas la fin de l'activité.

Les transactions précédemment confirmées avaient également activé le RBF, qui permet de remplacer une transaction Bitcoin non confirmée par une version payant des frais plus élevés. Le RBF est une fonctionnalité normale du réseau et ne démontre pas indépendamment une intention malveillante. Dans le contexte d'un balayage massif en cours, cependant, 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 rapportés concernant les adresses et les valeurs nécessitent une interprétation prudente. Une « adresse de victime » est une adresse classée par les chercheurs en fonction de son comportement transactionnel et de sa connexion à la limite pertinente du firmware Coldcard ; 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 se chevauchent pas avec 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 pré-incident. Une telle augmentation brutale est difficile à expliquer uniquement comme la réaction d'utilisateurs indépendants à un avertissement de sécurité. Les transactions ne contenaient apparemment aucune entrée antérieure à la limite pertinente du firmware Coldcard, renforçant l'association entre les fonds balayés et les seeds créées sous le firmware affecté.

L'évaluation de Galaxy repose donc sur le poids combiné du timing, de la sélection des adresses, de la construction des transactions et du comportement des destinations. Aucune caractéristique unique n'est concluante : les utilisateurs légitimes peuvent activer le 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 à travers des centaines d'adresses liées au firmware.

Cependant, l'analyse on-chain 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 affirmer 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 suspectée présentait une structure principalement 1:1 dans laquelle les fonds des adresses de victimes étaient envoyés vers de nouvelles destinations séparées. Une seule destination aurait reçu deux balayages, et aucune adresse d'agrégation 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 second saut.

Cette structure diffère des empreintes les plus claires observées plus tôt dans l'incident. L'analyse de Galaxy a révélé que les deux premières vagues majeures utilisaient répétitivement des frais codés en dur de 30 sat/vB et des modèles de regroupement similaires, soutenant la possibilité d'un opérateur partagé ou d'un outil d'attaque. Une vague ultérieure s'est orientée vers des transferts individuels et des destinations dispersées. À travers 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 transactionnelles 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 antérieures 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 seeds vulnérables restantes en utilisant des outils développés indépendamment. Les deux interprétations sont cohérentes avec les modèles de transaction, mais aucune ne peut être prouvée par la topologie seule.

Les transferts de second 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 second saut convergent finalement 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 change également le risque pratique pour les utilisateurs. Galaxy a identifié une explosion initiale où 1 082,65 BTC ont été balayés depuis 1 196 adresses en environ 41 minutes. L'activité ultérieure a ciblé des adresses supplémentaires et des soldes plus petits en utilisant différentes structures. Cela peut indiquer une transition de l'extraction rapide de portefeuilles visibles à haute valeur vers un balayage continu de la population restante de seeds faibles.

Une campagne d'énumération continue peut revisiter le même espace de seeds 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 seeds non migrées peuvent rester exploitables après la fin des vols initiaux les plus visibles.

La cause technique racine : 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 RNG matériel de MicroPython a provoqué le repli d'une bibliothèque externe vers le générateur logiciel déterministe Yasmarang plutôt que vers 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 pouvaient potentiellement être reproduites hors ligne. Sur les appareils plus récents, une entrée d'élément sécurisé a été ajoutée, mais Block a rapporté que seuls quatre octets du digest résultant atteignaient la fonction de reseeding, limitant l'état différencié de manière sécurisée à pas plus de (2^{32}) possibilités selon les hypothèses pertinentes.

Faire passer une sortie aléatoire faible à travers un hachage cryptographique ne résout pas le problème. Un hachage peut faire apparaître les résultats comme uniformément distribués, mais il ne peut pas créer plus de secrets possibles qu'il n'en existait dans l'espace d'entrée original. Un attaquant peut énumérer les seeds 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 standards de seed. La vulnérabilité concerne l'aléatoire utilisé avant la création des clés privées. Une fois qu'une seed 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 voie d'attaque possible. Ses conclusions doivent donc être considérées conjointement avec l'enquête de Coinkite et les 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 des clés ne peuvent pas restaurer l'entropie qui était absente lors de la création de la seed.

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. Le firmware corrigé modifie la façon dont les nouveaux secrets sont générés, mais il ne peut pas altérer une phrase mnémonique créée sous une version affectée. Importer cette phrase mnémonique dans un firmware mis à jour ou 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 la génération d'une véritable nouvelle seed via un processus corrigé et le transfert des fonds on-chain.

Coinkite identifie les seeds Mk2 et Mk3 générées sur les versions de firmware 4.0.1 à 4.1.9 comme 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. L'entreprise décrit l'impact sur les appareils Mk4, Mk5 et Q comme moins sévère 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 confiance comment les lancers ont été générés et incorporés ne devraient pas compter sur 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 originale. Un code PIN Coldcard n'est pas une phrase de passe BIP-39 et n'empêche pas le déplacement des fonds blockchain 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 lorsque la seed actuelle a été générée à l'origine. 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 de 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 entirely nouvelle seed. Ils doivent enregistrer securely 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 seed, les clés privées, les phrases de passe, les séquences de lancers de dés ou les sauvegardes de 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 multisignatures 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. Le remplacement des 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 à haute 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 d'auto-garde sont dangereux. Il montre que la sécurité du portefeuille dépend de tout le 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. Des étiquettes telles que « isolé », « 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 fail-closed lorsque l'aléatoire sécurisé n'est pas disponible. Un portefeuille peut sinon continuer à recevoir des fonds et signer des transactions valides tout en cachant une faiblesse qui existe depuis la création de la seed.

La leçon centrale concerne 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 manière dont les clés privées sont stockées et utilisées ; ils ne peuvent pas rétroactivement rendre une seed prévisible imprévisible.

Conclusion

La quatrième vague d'attaque Coldcard suspectée indique que la fenêtre de risque reste ouverte. Le timing 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 restent cependant non confirmées.

Pour les utilisateurs potentiellement affectés, la priorité est de vérifier quand et comment leur seed actuelle a été créée. Le 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 de manière sécurisée.

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 solliciter une assistance qualifiée pour les configurations de portefeuille complexes.