Coldcards vermutete vierte Angriffswelle: Warum werden immer noch 462 Adressen geleert?

Galaxy-Researchleiter Alex Thorn hat eine scheinbar vierte organisierte Welle von Bitcoin-Diebstählen identifiziert, die Seeds betrifft, die von betroffener Coldcard-Firmware generiert wurden. Während des etwa 2,5-stündigen Zeitraums zwischen den Blöcken 960.778 und 960.792 beobachteten Forscher 218 Transaktionen, die 462 mutmaßliche Opferadressen, 216 neue Ziele und 388,92748828 BTC umfassten. Ähnliche Transaktionen verblieben reportedly im Mempool, während bestätigte Transaktionen Replace-by-Fee (RBF) aktiviert hatten.

Die Aktivität deutet darauf hin, dass öffentliche Bekanntmachungen und Notfall-Firmware-Updates das Risiko im Zusammenhang mit zuvor generierten Seeds nicht beseitigt haben. Die beobachtete Sweep-Rate erreichte 13,8 pro Block, verglichen mit 0,3 in einem Kontrollfenster vor dem Vorfall – eine etwa 45-fache Steigerung. Dennoch bleibt „vierte Welle“ eine Forschungsklassifizierung, die auf On-Chain-Mustern basiert. Die Beweise identifizieren die Angreifer nicht schlüssig oder beweisen nicht, dass dieselbe Entität jede Welle durchgeführt hat.

Wichtigste Erkenntnisse

• Die mutmaßliche vierte Welle umfasste 218 Transaktionen, 462 mutmaßliche Opferadressen, 216 neue Ziele und 388,92748828 BTC.
• Die Konzentration der Aktivität und die etwa 45-fache Steigerung der Sweep-Rate unterstützen die Interpretation einer systematischen Ausnutzung rather than einer gewöhnlichen Wallet-Migration.
• Vorwiegend 1:1-Übertragungen, minimale Zielwiederverwendung und Second-Hop-Bewegungen könnten auf eine stärker dezentralisierte Fondsverwaltungsstrategie hindeuten.
• Das Aktualisieren der Coldcard-Firmware repariert keinen bestehenden schwachen Seed; potenziell betroffene Benutzer müssen einen neuen Seed durch einen korrigierten Prozess generieren und ihre Assets migrieren.

Was geschah während der mutmaßlichen vierten Angriffswelle?

Laut Thorns Überwachung erschien der neueste Transaktionscluster zwischen den Bitcoin-Blöcken 960.778 und 960.792. Über etwa 2,5 Stunden hinweg identifizierten Forscher 218 Transaktionen, die Merkmale aufwiesen, die mit dem anhaltenden Coldcard-Vorfall verbunden sind. Die Transaktionen betrafen 462 Adressen, die als mutmaßliche Opferadressen klassifiziert wurden, 216 neue Zieladressen und 388,92748828 BTC. Ähnliche Transaktionen warteten reportedly noch auf Bestätigung im Mempool, was darauf hindeutet, dass das beobachtete Fenster nicht das Ende der Aktivität darstellen könnte.

Zuvor bestätigte Transaktionen aktivierten ebenfalls RBF, wodurch eine unbestätigte Bitcoin-Transaktion durch eine Version mit höherer Gebühr ersetzt werden kann. RBF ist eine normale Netzwerkfunktion und zeigt nicht unabhängig böswillige Absichten an. Im Kontext eines laufenden Massensweeps deutet seine Verwendung jedoch darauf hin, dass der Initiator der Transaktionen die Bestätigungspriorität aktiv verwaltete und Gebühren erhöhen konnte, wenn konkurrierende Transaktionen erschienen.

Die gemeldeten Adress- und Wertangaben erfordern eine sorgfältige Interpretation. Eine „Opferadresse“ ist eine Adresse, die von Forschern durch ihr Transaktionsverhalten und ihre Verbindung zur relevanten Coldcard-Firmware-Grenze klassifiziert wurde; sie repräsentiert nicht unbedingt einen einzelnen Benutzer. Ein Wallet kann mehrere Adressen kontrollieren, und eine Transaktion kann mehrere Inputs ausgeben. Ebenso sollten die 388,92748828 BTC, die in diesem Fenster beobachtet wurden, nicht automatisch zu früheren Verlustschätzungen addiert werden, bis Forscher bestätigen, dass die Adressen, Inputs und übertragenen Mittel sich nicht mit früheren Clustern überschneiden.

Der wichtigste Beweis ist die Intensität und Konsistenz der Aktivität. Forscher berechneten 13,8 Sweeps pro Block während des überwachten Zeitraums, verglichen mit 0,3 pro Block in einem Kontrollfenster vor dem Vorfall. Ein so starker Anstieg ist schwer allein als Reaktion unabhängiger Benutzer auf eine Sicherheitswarnung zu erklären. Die Transaktionen enthielten reportedly auch keine Inputs, die vor der relevanten Coldcard-Firmware-Grenze lagen, was die Assoziation zwischen den gesweepten Mitteln und unter betroffener Firmware erstellten Seeds verstärkt.

Galaxys Bewertung beruht daher auf der kombinierten Gewichtung von Timing, Adressauswahl, Transaktionskonstruktion und Zielverhalten. Kein einzelnes Merkmal ist schlüssig: Legitime Benutzer können RBF aktivieren, neue Empfangsadressen generieren oder Mittel gleichzeitig nach einer offiziellen Warnung migrieren. Die Interpretation eines organisierten Angriffs wird überzeugender, wenn diese Merkmale mit ungewöhnlicher Regelmäßigkeit über hunderte firmware-verknüpfte Adressen hinweg auftreten.

Allerdings kann die On-Chain-Analyse nicht direkt offenlegen, wer die privaten Schlüssel kontrolliert. Ein Angreifer könnte die Transaktionsstrategien zwischen den Wellen ändern, während mehrere Operatoren dieselbe Schwachstelle unabhängig voneinander ausnutzen könnten, nachdem sie öffentlich geworden ist. Galaxy hat die Cluster folglich als koordinierte Angriffswellen behandelt, ohne zu behaupten, dass jede Welle definitiv derselben Entität zugeordnet wurde.

Was enthüllt die neue Transaktionstopologie?

Die mutmaßliche vierte Welle zeigte eine vorwiegend 1:1-Struktur, bei der Mittel von Opferadressen an separate neue Ziele gesendet wurden. Nur ein Ziel erhielt reportedly zwei Sweeps, und während der initialen Überwachungsphase erschien keine offensichtliche zentrale Sammeladresse. Einige der Mittel bewegten sich anschließend zu Second-Hop-Adressen.

Diese Struktur unterscheidet sich von den klarsten Fingerabdrücken, die früher im Vorfall beobachtet wurden. Galaxys Analyse ergab, dass die ersten beiden großen Wellen wiederholt hardcodierte Gebühren von 30 sat/vB und ähnliche Batch-Muster verwendeten, was die Möglichkeit eines gemeinsamen Operators oder Angriffstools unterstützt. Eine spätere Welle verlagerte sich hin zu individuellen Transfers und dezentralisierten Zielen. Über die ersten drei identifizierten Wellen hinweg bezifferten mit Galaxy verbundene Berichte den betroffenen Betrag auf 1.367,05 BTC von 4.585 Adressen, wobei betont wurde, dass Unterschiede in den Transaktionsfingerabdrücken eine definitive Zuordnung zu einem einzelnen Angreifer verhinderten.

Eine Erklärung ist, dass ein Angreifer erkannte, dass zentralisierte Sammeladressen frühere Transaktionen leichter zu clustern und zu überwachen machten, und dann neue Ziele und zusätzliche Hops adoptierte, um die unmittelbare Sichtbarkeit zu reduzieren. Eine andere ist, dass die Offenlegung der Schwachstelle Nachahmer-Angreifern ermöglichte, nach verbleibenden anfälligen Seeds zu suchen, indem sie unabhängig entwickelte Tools verwendeten. Beide Interpretationen sind konsistent mit den Transaktionsmustern, aber keine kann allein aus der Topologie bewiesen werden.

Second-Hop-Transfers sollten nicht automatisch als Geldwäsche beschrieben werden. Sie können die initiale Extraktion von der längerfristigen Verwahrung trennen, Mittel für spätere Konsolidierung vorbereiten, testen, ob Adressen markiert wurden, oder Assets zu externen Diensten routen. Ermittler müssen bestimmen, ob die Second-Hop-Adressen schließlich konvergieren oder mit identifizierbaren Entitäten interagieren. In dieser Phase ist die vertretbare Schlussfolgerung, dass die neuesten Transaktionen systematisches Sweeping kombiniert mit zunehmend dezentralisierter Fondsverwaltung zeigen.

Die Evolution der Angriffe ändert auch das praktische Risiko für Benutzer. Galaxy identifizierte einen initialen Ausbruch, bei dem 1.082,65 BTC von 1.196 Adressen innerhalb von etwa 41 Minuten gesweept wurden. Spätere Aktivitäten zielten auf zusätzliche Adressen und kleinere Salden mit unterschiedlichen Strukturen ab. Dies könnte einen Übergang von der schnellen Extraktion sichtbarer High-Value-Wallets zum kontinuierlichen Scannen der verbleibenden Population schwacher Seeds anzeigen.

Eine fortlaufende Enumerationskampagne kann denselben anfälligen Seed-Raum erneut besuchen und kleinere Salden ins Visier nehmen, da sich Angriffstools verbessern oder Transaktionskosten ändern. Die öffentliche Bekanntmachung könnte auch ein Wettrennen zwischen legitimen Eigentümern, die versuchen zu migrieren, und Angreifern, die versuchen, ihre Schlüssel zu rekonstruieren, schaffen. Die mutmaßliche vierte Welle ist daher nicht nur wegen ihres beobachteten Werts wichtig, sondern weil sie anzeigt, dass nicht migrierte Seeds nach Ende der sichtbarsten initialen Diebstähle weiterhin ausnutzbar sein könnten.

Die technische Ursache: Vorhersehbare Zufälligkeit

Das Bitcoin Engineering and Security Team von Block führte das zugrunde liegende Problem auf die Integration der Coldcard-Firmware mit ihrem Pfad zur Zufallszahlengenerierung zurück. Laut Block verursachte eine Konfiguration, die die Hardware-RNG-Implementierung von MicroPython deaktivieren sollte, dass eine externe Bibliothek auf den deterministischen Yasmarang-Softwaregenerator zurückfiel, statt auf den erwarteten STM32-Hardware-RNG. Die Bibliothek prüfte, ob ein Konfigurationsmakro existierte, aber nicht, ob es aktiviert war.

Für betroffene Mk2- und Mk3-Firmware konnte der Fallback-Generator mithilfe von Gerätemetadaten und Timing-Zustand initialisiert werden, ohne kryptografisch sichere Entropie über den anfälligen Pfad zu erhalten. Wenn ein Angreifer die Geräte-UID, den Timer-Zustand und vorherige Zufallszahlenaufrufe bestimmen oder ausreichend einschränken könnte, könnten Kandidatenausgaben potenziell offline reproduziert werden. Bei späteren Geräten wurde Secure-Element-Input hinzugefügt, aber Block berichtete, dass nur vier Bytes des resultierenden Digests die Reseed-Funktion erreichten, was den sicher differenzierten Zustand unter den relevanten Annahmen auf höchstens (2^{32}) Möglichkeiten beschränkte.

Das Durchleiten schwacher Zufallsausgaben durch einen kryptografischen Hash löst das Problem nicht. Ein Hash kann die Ergebnisse gleichmäßig verteilt erscheinen lassen, kann aber nicht mehr mögliche Geheimnisse erzeugen, als im ursprünglichen Input-Raum vorhanden waren. Ein Angreifer kann Kandidatenseeds enumerieren, ihre Bitcoin-Adressen ableiten und diese Adressen mit der öffentlichen Blockchain vergleichen. Eine Übereinstimmung liefert ein Validierungssignal, das den entsprechenden privaten Schlüssel ohne physischen Zugriff auf das Wallet offenbaren kann.

Dies ist kein Versagen des Bitcoin-Signatursystems oder der Seed-Standards. Die Schwachstelle betrifft die Zufälligkeit, die verwendet wurde, bevor die privaten Schlüssel erstellt wurden. Sobald ein schwacher Seed existiert, kann ein offline-, air-gapped- oder physisch gesichertes Gerät nicht verhindern, dass eine andere Partei dasselbe Geheimnis durch Berechnung rekonstruiert.

Block beschrieb seinen Bericht als eine frühe technische Bewertung, die veröffentlicht wurde, während die Ausnutzung aktiv zu sein schien, und stellte fest, dass es empirische Tests jedes möglichen Angriffspfads nicht abgeschlossen hatte. Seine Erkenntnisse sollten daher neben Coinkites Untersuchung und finalen technischen Schlussfolgerungen betrachtet werden. Selbst mit dieser Einschränkung ist das zentrale Sicherheitsproblem klar: Schutzmaßnahmen, die nach der Schlüsselerzeugung angewendet werden, können Entropie nicht wiederherstellen, die bei der Erstellung des Seeds fehlte.

Warum reicht das Aktualisieren der Firmware nicht aus?

Coinkites offizielle Richtlinie unterscheidet zwischen der Verhinderung der Generierung anfälliger Seeds in der Zukunft und der Reparatur eines bestehenden Seeds. Korrigierte Firmware ändert, wie neue Geheimnisse generiert werden, kann aber ein Mnemonic, das unter einer betroffenen Version erstellt wurde, nicht ändern. Das Importieren dieses Mnemonics in aktualisierte Firmware oder ein anderes Hardware-Wallet erstellt dieselben privaten Schlüssel neu und bewahrt das zugrunde liegende Risiko. Eine vollständige Behebung erfordert die Generierung eines genuinely neuen Seeds durch einen korrigierten Prozess und die On-Chain-Übertragung der Mittel.

Coinkite identifiziert Mk2- und Mk3-Seeds, die auf Firmware-Versionen 4.0.1 bis 4.1.9 generiert wurden, als betroffen. Es empfiehlt auch die Migration für Mk4- und Mk5-Seeds, die vor Standard-Firmware 5.6.0 oder Edge-Firmware 6.6.0X erstellt wurden, sowie für Coldcard Q-Seeds, die vor Standard-Firmware 1.5.0Q oder Edge-Firmware 6.6.0QX erstellt wurden. Das Unternehmen beschreibt die Auswirkungen auf Mk4, Mk5 und Q als weniger schwerwiegend als auf betroffene Mk2- und Mk3-Geräte, aber dennoch ernst. Mk2- und Mk3-Besitzer können Ersatz-Seeds nach der Installation von Version 4.2.0 oder später generieren.

Genuinely unabhängige Entropie kann begrenzte Ausnahmen bieten. Coinkite gibt an, dass mindestens 50 faire, unabhängige und private Würfelwürfe 128 Bit Entropie beitragen können, während 99 oder mehr Würfe etwa 256 Bit beitragen. Benutzer, die nicht sicher bestätigen können, wie die Würfe generiert und integriert wurden, sollten sich nicht auf diese Ausnahme verlassen. Eine starke BIP-39-Passphrase kann eine zusätzliche Barriere schaffen, aber Coinkite empfiehlt dennoch die Migration, da die Passphrase den originalen Seed nicht repariert. Eine Coldcard-PIN ist keine BIP-39-Passphrase und verhindert nicht, dass Blockchain-Mittel bewegt werden, wenn die privaten Schlüssel rekonstruiert werden.

Was sollten Coldcard-Benutzer jetzt tun?

Potenziell betroffene Benutzer sollten das Gerätemodell und die Firmware-Version bestimmen, die verwendet wurde, als der aktuelle Seed ursprünglich generiert wurde. Die aktuelle Firmware-Version allein ist unzureichend, wenn der Seed auf einem älteren Coldcard erstellt oder von einem anderen Gerät importiert wurde. Firmware-Checks und Downloads sollten nur über offizielle Coinkite-Kanäle durchgeführt werden, ohne Links zu folgen, die von unaufgeforderten Support-Konten, Social-Media-Nachrichten oder Wiederherstellungsdiensten bereitgestellt werden.

Benutzer innerhalb eines betroffenen Bereichs sollten die entsprechende korrigierte Firmware installieren und einen völlig neuen Seed generieren. Sie sollten das neue Backup sicher aufzeichnen, den Wallet-Fingerabdruck und die Empfangsadresse direkt auf dem Hardware-Bildschirm verifizieren und eine kleine Testtransaktion senden, bevor sie den verbleibenden Saldo übertragen. Das Wiederherstellen des alten Mnemonics auf einem neuen Gerät oder die weitere Verwendung nach einem Firmware-Update löst die Schwachstelle nicht.

Der Vorfall schafft auch eine Gelegenheit für Sekundärbetrug. Benutzer sollten niemals Seed-Wörter, private Schlüssel, Passphrasen, Würfelwurfsequenzen oder Wallet-Backups an jemanden offenlegen, der behauptet, Coldcard, Coinkite, Galaxy, eine Börse, Strafverfolgungsbehörden oder eine Wiederherstellungsfirma zu vertreten. Legitimes Support-Personal benötigt diese Geheimnisse nicht, um Firmware zu verifizieren oder Migrationsverfahren zu erklären.

Multisignatur-Benutzer sollten bewerten, wie viele betroffene Schlüssel an der Ausgabenschwelle teilnehmen. Wenn genügend anfällige Schlüssel rekonstruiert werden können, kann auch der Multisignatur-Schutz versagen. Das Ersetzen von Schlüsseln, ohne die Schwelle zu schwächen oder Wallet-Skripte unnötig offenzulegen, kann eine sorgfältiger geplante Migration erfordern, insbesondere für wertvolle oder institutionell verwaltete Wallets.

Weitere Implikationen für die Hardware-Wallet-Sicherheit

Der Vorfall zeigt nicht, dass alle Hardware-Wallets oder Self-Custody-Systeme unsicher sind. Er zeigt, dass Wallet-Sicherheit vom gesamten Schlüssel-Lebenszyklus abhängt: Entropiegenerierung, Firmware-Konfiguration, Abhängigkeitsprüfung, Seed-Backup, Transaktionsverifizierung und eventuelle Migration. Labels wie „air-gapped“, „offline“, „Open Source“ oder „Secure-Element-geschützt“ beschreiben individuelle Verteidigungen rather than die Sicherheit des kompletten Systems.

Open-Source-Firmware ermöglicht unabhängige Überprüfung, garantiert aber nicht, dass Implementierungsfehler vor der Ausnutzung entdeckt werden. Stärkere Assurance erfordert reproduzierbare Builds, Entropietests, Code-Review über Bibliotheksgrenzen hinweg, deterministische Testvektoren und Fail-Closed-Verhalten, wenn sichere Zufälligkeit nicht verfügbar ist. Ein Wallet kann sonst weiterhin Mittel empfangen und gültige Transaktionen signieren, während es eine Schwachstelle verbirgt, die seit der Seed-Erstellung existiert.

Die zentrale Lehre betrifft die Seed-Herkunft. Das Verschieben eines alten Mnemonics auf neuere Hardware verbessert seine Speicherumgebung, ändert aber nicht seine mathematische Sicherheit. Hardware-Wallets schützen, wie private Schlüssel gespeichert und verwendet werden; sie können einen vorhersehbaren Seed nicht rückwirkend unvorhersehbar machen.

Fazit

Die mutmaßliche vierte Coldcard-Angriffswelle zeigt an, dass das Risikofenster offen bleibt. Das komprimierte Timing, die etwa 45-fache Steigerung der Sweep-Rate, die firmware-verknüpfte Input-Grenze und die regelmäßige Transaktionsstruktur unterstützen Galaxys Bewertung systematischer Aktivität. Die Identitäten der Angreifer und die Beziehung zwischen den verschiedenen Wellen bleiben jedoch unbestätigt.

Für potenziell betroffene Benutzer hat die Verifizierung, wann und wie ihr aktueller Seed erstellt wurde, Priorität. Korrigierte Firmware kann neu generierte Geheimnisse schützen, kann aber keinen bestehenden schwachen Seed reparieren. Die wirksame Abhilfe besteht darin, einen neuen Seed durch einen korrigierten Prozess zu generieren und die Assets sicher zu migrieren.

Risikohinweis: Dieser Artikel dient nur zu Informationszwecken und stellt keine Investment-, Rechts- oder Cybersicherheitsberatung dar. Benutzer sollten Firmware-Versionen und Migrationsverfahren durch offizielle Coinkite-Dokumentation verifizieren und qualifizierte Unterstützung für komplexe Wallet-Konfigurationen suchen.