Coldcard: Vermutete vierte Angriffswelle – Warum werden 462 Adressen immer noch abgeräumt?

BTC
Seed-SchwachstelleFirmware-AngriffBitcoin-DiebstahlColdcardMempoolRBF
2026-08-03Quelle: mexc.com
Coldcard: Vermutete vierte Angriffswelle – Warum werden 462 Adressen immer noch abgeräumt?

Der Forschungsleiter von Galaxy, Alex Thorn, hat eine vierte organisierte Welle von Bitcoin-Diebstählen identifiziert, die offenbar 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 mit 462 mutmaßlichen Opferadressen, 216 neuen Zieladressen und 388,92748828 BTC. Ähnliche Transaktionen befanden sich Berichten zufolge weiterhin im Mempool, während bestätigte Transaktionen Replace-by-Fee (RBF) aktiviert hatten.

Die Aktivität deutet darauf hin, dass die öffentliche Offenlegung und Notfall-Firmware-Updates das Risiko, das mit zuvor generierten Seeds verbunden ist, nicht beseitigt haben. Die beobachtete Abschöpfungsrate erreichte 13,8 pro Block, verglichen mit 0,3 in einem Kontrollfenster vor dem Vorfall – ein Anstieg um etwa das 45-fache. Dennoch bleibt die „vierte Welle“ eine Forschungsklassifikation, die auf On-Chain-Mustern basiert. Die Beweise identifizieren die Angreifer nicht eindeutig und 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 Zieladressen und 388,92748828 BTC.
  • Die Konzentration der Aktivität und der etwa 45-fache Anstieg der Abschöpfungsrate unterstützen die Interpretation einer systematischen Ausbeutung und nicht einer gewöhnlichen Wallet-Migration.
  • Überwiegend 1:1-Transfers, minimale Wiederverwendung von Zieladressen und Bewegungen in zweiter Hüpfebene könnten auf eine stärker dezentrale Strategie zur Vermögensverwaltung hindeuten.
  • Die Aktualisierung der Coldcard-Firmware repariert keinen vorhandenen schwachen Seed; potenziell betroffene Benutzer müssen über einen korrigierten Prozess einen neuen Seed generieren und ihre Vermögenswerte migrieren.

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

Laut Thorns Überwachung erschien der jüngste Transaktionscluster zwischen den Bitcoin-Blöcken 960.778 und 960.792. Über etwa 2,5 Stunden identifizierten Forscher 218 Transaktionen, die Merkmale aufwiesen, die mit dem laufenden Coldcard-Vorfall in Verbindung stehen. Die Transaktionen betrafen 462 Adressen, die als mutmaßliche Opferadressen eingestuft wurden, 216 neue Zieladressen und 388,92748828 BTC. Ähnliche Transaktionen warteten Berichten zufolge noch im Mempool auf Bestätigung, was darauf hindeutet, dass das beobachtete Fenster möglicherweise nicht das Ende der Aktivität darstellt.

Zuvor bestätigte Transaktionen hatten ebenfalls RBF aktiviert, was es ermöglicht, eine unbestätigte Bitcoin-Transaktion durch eine Version mit höherer Gebühr zu ersetzen. RBF ist eine normale Netzwerkfunktion und beweist nicht unabhängig böswillige Absicht. Im Zusammenhang mit einer laufenden Massen-Abschöpfung deutet ihre Verwendung jedoch darauf hin, dass derjenige, der die Transaktionen initiierte, aktiv die Bestätigungspriorität verwaltete und die Gebühren erhöhen konnte, wenn konkurrierende Transaktionen auftauchten.

Die gemeldeten Adress- und Wertangaben müssen sorgfältig interpretiert werden. Eine „Opferadresse“ ist eine Adresse, die von Forschern anhand ihres Transaktionsverhaltens und ihrer Verbindung zur relevanten Coldcard-Firmware-Grenze klassifiziert wurde; sie repräsentiert nicht unbedingt einen einzelnen Benutzer. Eine Wallet kann mehrere Adressen kontrollieren, und eine Transaktion kann mehrere Eingaben ausgeben. Ebenso sollten die in diesem Fenster beobachteten 388,92748828 BTC nicht automatisch zu früheren Verlustschätzungen hinzugefügt werden, bis Forscher bestätigen, dass die Adressen, Eingaben und übertragenen Gelder sich nicht mit früheren Clustern überschneiden.

Der wichtigste Beweis ist die Intensität und Konsistenz der Aktivität. Forscher berechneten 13,8 Abschöpfungen 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 durch unabhängige Benutzer zu erklären, die auf eine Sicherheitswarnung reagieren. Die Transaktionen enthielten Berichten zufolge auch keine Eingaben, die vor der relevanten Coldcard-Firmware-Grenze lagen, was die Verbindung zwischen den abgeschöpften Geldern und Seeds, die unter betroffener Firmware erstellt wurden, verstärkt.

Die Einschätzung von Galaxy stützt sich daher auf das kombinierte Gewicht von Zeitpunkt, Adressauswahl, Transaktionskonstruktion und Zielverhalten. Kein einzelnes Merkmal ist schlüssig: Legitime Benutzer können RBF aktivieren, neue Empfangsadressen generieren oder Gelder nach einer offiziellen Warnung gleichzeitig migrieren. Die Interpretation eines organisierten Angriffs wird überzeugender, wenn diese Merkmale mit ungewöhnlicher Regelmäßigkeit über Hunderte von Firmware-verbundenen Adressen auftreten.

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

Was offenbart die neue Transaktionstopologie?

Die mutmaßliche vierte Welle zeigte eine überwiegend 1:1-Struktur, bei der Gelder von Opferadressen an separate neue Ziele gesendet wurden. Nur ein Ziel erhielt Berichten zufolge zwei Abschöpfungen, und während des anfänglichen Überwachungszeitraums erschien keine offensichtliche zentrale Sammeladresse. Einige der Gelder wurden anschließend an Adressen der zweiten Hüpfebene weitergeleitet.

Diese Struktur unterscheidet sich von den klarsten Fingerabdrücken, die früher in dem Vorfall beobachtet wurden. Die Analyse von Galaxy ergab, dass die ersten beiden großen Wellen wiederholt feste Gebühren von 30 sat/vB und ähnliche Batching-Muster verwendeten, was die Möglichkeit eines gemeinsamen Betreibers oder Angriffswerkzeugs unterstützt. Eine spätere Welle verlagerte sich auf einzelne Überweisungen und verstreute Ziele. Über die ersten drei identifizierten Wellen hinweg bezifferte der mit Galaxy verbundene Bericht den betroffenen Betrag auf 1.367,05 BTC von 4.585 Adressen, betonte jedoch, dass Unterschiede in den Transaktions-Fingerabdrücken eine eindeutige Zuordnung zu einem einzelnen Angreifer verhinderten.

Eine Erklärung ist, dass ein Angreifer erkannte, dass zentralisierte Sammeladressen frühere Transaktionen leichter zu gruppieren und zu überwachen machten, und dann neue Ziele und zusätzliche Hops einführte, um die unmittelbare Sichtbarkeit zu verringern. Eine andere ist, dass die Offenlegung der Schwäche Nachahmer-Angreifer dazu veranlasste, mit unabhängig entwickelten Werkzeugen nach verbleibenden verwundbaren Seeds zu suchen. Beide Interpretationen sind mit den Transaktionsmustern vereinbar, aber keine kann allein aus der Topologie bewiesen werden.

Überweisungen des zweiten Hops sollten nicht automatisch als Geldwäsche bezeichnet werden. Sie können die anfängliche Extraktion von der langfristigen Verwahrung trennen, Gelder für eine spätere Konsolidierung vorbereiten, testen, ob Adressen markiert wurden, oder Vermögenswerte an externe Dienste weiterleiten. Ermittler müssen feststellen, ob die Adressen des zweiten Hops schließlich konvergieren oder mit identifizierbaren Entitäten interagieren. In diesem Stadium ist die vertretbare Schlussfolgerung, dass die neuesten Transaktionen ein systematisches Abräumen in Kombination mit zunehmend verstreuter Vermögensverwaltung zeigen.

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

Eine fortlaufende Aufzählungskampagne kann denselben verwundbaren Seed-Raum erneut besuchen und kleinere Guthaben anvisieren, wenn sich Angriffswerkzeuge verbessern oder Transaktionskosten ändern. Die öffentliche Offenlegung kann auch ein Rennen zwischen legitimen Eigentümern, die migrieren möchten, und Angreifern, die ihre Schlüssel rekonstruieren möchten, schaffen. Die vermutete vierte Welle ist daher nicht nur wegen ihres beobachteten Werts wichtig, sondern weil sie darauf hindeutet, dass nicht migrierte Seeds auch nach dem Ende der sichtbarsten anfänglichen Diebstähle weiterhin ausnutzbar sein könnten.

Die technische Grundursache: Vorhersehbare Zufälligkeit

Das Bitcoin-Engineering- und Sicherheitsteam von Block führte das zugrunde liegende Problem auf die Integration der Coldcard-Firmware mit ihrem Zufallszahlengenerierungspfad zurück. Laut Block führte eine Konfiguration, die die Hardware-RNG-Implementierung von MicroPython deaktivieren sollte, dazu, dass eine externe Bibliothek auf den deterministischen Softwaregenerator Yasmarang zurückfiel, anstatt auf die erwartete 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 mit Gerätemetadaten und Zeitstatus initialisiert werden, ohne kryptographisch sichere Entropie über den verwundbaren Pfad zu erhalten. Wenn ein Angreifer die Geräte-UID, den Timer-Status und frühere Zufallszahlenaufrufe bestimmen oder ausreichend einschränken konnte, konnten Kandidatenausgaben möglicherweise offline reproduziert werden. Bei späteren Geräten wurde Secure-Element-Eingabe 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 nicht mehr als (2^{32}) Möglichkeiten begrenzte.

Das Durchleiten schwacher Zufallsausgabe durch einen kryptographischen Hash löst das Problem nicht. Ein Hash kann die Ergebnisse gleichmäßig verteilt erscheinen lassen, aber er kann nicht mehr mögliche Geheimnisse erzeugen, als im ursprünglichen Eingaberaum existierten. Ein Angreifer kann Kandidaten-Seeds aufzählen, 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 offenlegen kann.

Dies ist kein Versagen des Bitcoin-Signatursystems oder der Seed-Standards. Die Schwachstelle betrifft die Zufälligkeit, die vor der Erstellung der privaten Schlüssel verwendet wurde. 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 merkte an, dass es keine empirischen Tests jedes möglichen Angriffspfads abgeschlossen hatte. Seine Ergebnisse sollten daher zusammen mit der Untersuchung und den endgültigen technischen Schlussfolgerungen von Coinkite betrachtet werden. Selbst mit dieser Einschränkung ist das zentrale Sicherheitsproblem klar: Schutzmaßnahmen, die nach der Schlüsselerzeugung angewendet werden, können keine Entropie wiederherstellen, die bei der Erstellung des Seeds fehlte.

Warum ist die Aktualisierung der Firmware nicht genug?

Coinkites offizielle Anleitung unterscheidet zwischen der Verhinderung anfälliger Seed-Generierung in der Zukunft und der Reparatur eines bestehenden Seeds. Eine korrigierte Firmware ändert, wie neue Geheimnisse generiert werden, aber sie kann eine Mnemonik, die unter einer betroffenen Version erstellt wurde, nicht ändern. Das Importieren dieser Mnemonik in eine aktualisierte Firmware oder eine andere Hardware-Wallet erstellt dieselben privaten Schlüssel neu und bewahrt das zugrunde liegende Risiko. Eine vollständige Behebung erfordert die Generierung eines wirklich neuen Seeds durch einen korrigierten Prozess und die Übertragung der Gelder auf der Blockchain.

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 immer noch ernst. Mk2- und Mk3-Besitzer können nach der Installation von Version 4.2.0 oder später Ersatz-Seeds generieren.

Wirklich 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 ungefähr 256 Bit beitragen. Benutzer, die nicht sicher bestätigen können, wie die Würfe generiert und einbezogen 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 ursprünglichen Seed nicht repariert. Eine Coldcard-PIN ist keine BIP-39-Passphrase und verhindert nicht, dass Blockchain-Gelder bewegt werden, wenn die privaten Schlüssel rekonstruiert werden.

Was sollten Coldcard-Benutzer jetzt tun?

Potentiell betroffene Benutzer sollten das Gerätemodell und die Firmware-Version bestimmen, die bei der ursprünglichen Generierung des aktuellen Seeds verwendet wurde. Die aktuelle Firmware-Version allein ist unzureichend, wenn der Seed auf einer älteren Coldcard erstellt oder von einem anderen Gerät importiert wurde. Firmware-Überprüfungen und Downloads sollten nur über offizielle Coinkite-Kanäle erfolgen, ohne Links zu folgen, die von unaufgeforderten Support-Konten, Social-Media-Nachrichten oder Wiederherstellungsdiensten bereitgestellt werden.

Benutzer innerhalb eines betroffenen Bereichs sollten die anwendbare 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 überprüfen und eine kleine Testtransaktion senden, bevor sie den Restbetrag übertragen. Das Wiederherstellen der alten Mnemonik auf einem neuen Gerät oder die weitere Verwendung nach einem Firmware-Update behebt die Schwachstelle nicht.

Der Vorfall schafft auch eine Gelegenheit für sekundären Betrug. Benutzer sollten niemals Seed-Wörter, private Schlüssel, Passphrasen, Würfelwurf-Sequenzen oder Wallet-Backups an Personen weitergeben, die behaupten, Coldcard, Coinkite, Galaxy, eine Börse, Strafverfolgungsbehörden oder ein Wiederherstellungsunternehmen zu vertreten. Legitime Support-Mitarbeiter benötigen diese Geheimnisse nicht, um Firmware zu überprüfen oder Migrationsverfahren zu erklären.

Multisignatur-Benutzer sollten bewerten, wie viele betroffene Schlüssel an der Ausgabeschwelle beteiligt sind. 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 hochwertige oder institutionell verwaltete Wallets.

Breitere Auswirkungen auf die Sicherheit von Hardware-Wallets

Der Vorfall zeigt nicht, dass alle Hardware-Wallets oder Selbstverwahrungssysteme unsicher sind. Er zeigt, dass die Wallet-Sicherheit vom gesamten Schlüssellebenszyklus abhängt: Entropie-Generierung, Firmware-Konfiguration, Abhängigkeitsüberprüfung, Seed-Backup, Transaktionsverifizierung und eventuelle Migration. Bezeichnungen wie „luftgespalten“, „offline“, „Open Source“ oder „durch sicheres Element geschützt“ beschreiben einzelne Verteidigungsmaßnahmen und nicht die Sicherheit des gesamten Systems.

Open-Source-Firmware ermöglicht unabhängige Überprüfung, garantiert jedoch nicht, dass Implementierungsfehler vor der Ausnutzung entdeckt werden. Eine stärkere Sicherheit erfordert reproduzierbare Builds, Entropie-Tests, Code-Review über Bibliotheksgrenzen hinweg, deterministische Testvektoren und Fail-Closed-Verhalten, wenn sichere Zufälligkeit nicht verfügbar ist. Andernfalls kann eine Wallet weiterhin Gelder empfangen und gültige Transaktionen signieren, während sie eine Schwäche verbirgt, die seit der Seed-Erstellung besteht.

Die zentrale Lektion ist die der Seed-Herkunft. Das Verschieben einer alten Mnemonik auf neuere Hardware verbessert ihre Speicherumgebung, ändert aber nicht ihre 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 vermutete vierte Coldcard-Angriffswelle zeigt, dass das Risikofenster weiterhin offen ist. Die komprimierte Zeitspanne, die etwa 45-fache Erhöhung der Abräumrate, die firmwarebezogene Eingabegrenze und die reguläre Transaktionsstruktur unterstützen Galaxys Einschätzung systematischer Aktivität. Die Identitäten der Angreifer und die Beziehung zwischen den verschiedenen Wellen bleiben jedoch unbestätigt.

Für potenziell betroffene Benutzer besteht die Priorität darin, zu überprüfen, wann und wie ihr aktueller Seed erstellt wurde. Aktualisierte Firmware kann neu generierte Geheimnisse schützen, aber sie kann einen bestehenden schwachen Seed nicht reparieren. Die wirksame Abhilfe besteht darin, einen neuen Seed durch einen korrigierten Prozess zu generieren und die Vermögenswerte sicher zu migrieren.

Risikohinweis: Dieser Artikel dient nur zu Informationszwecken und stellt keine Anlage-, Rechts- oder Cybersicherheitsberatung dar. Benutzer sollten Firmware-Versionen und Migrationsverfahren anhand der offiziellen Coinkite-Dokumentation überprüfen und für komplexe Wallet-Konfigurationen qualifizierte Unterstützung in Anspruch nehmen.