Coldcard-Angriff: Firmware-Fehler ermöglicht Abfluss von 89 Mio. US-Dollar in BTC

Ein Angriff auf Coldcard, eine der am häufigsten genutzten Hardware-Wallets im Bitcoin-Ökosystem, hat eine schwerwiegende Schwachstelle in der Seed-Erzeugung offengelegt. In drei Angriffswellen wurden rund 1.367 BTC im Gegenwert von etwa 89 Mio. US-Dollar aus Tausenden Adressen abgezogen. Anders als bei klassischen Phishing-Kampagnen oder Börsen-Hacks zielten die Täter auf den internen Prozess der Schlüsselerzeugung: Ein seit fünf Jahren bestehender Firmware-Bug erzeugte Seeds mit zu geringer Zufälligkeit. Dadurch konnten Angreifer Private Keys offline rekonstruieren und Guthaben abräumen. Was passiert ist: Drei Wellen, 1.367 BTC abgezogen Am 30. Juli 2026 begann der Abfluss aus Coldcard-Wallets. In der ersten Welle verschwanden innerhalb von 25 Minuten 594 BTC (rund 38 Mio. US-Dollar) aus etwa 500 Wallets. Die Täter priorisierten dabei offenbar die größten Bestände. Eine zweite Welle erhöhte die Verluste am selben Tag auf 1.082 BTC (rund 70 Mio. US-Dollar) über 1.196 Adressen innerhalb von 41 Minuten. Bis zum 2. August summierten sich die Abflüsse über drei Wellen auf 1.367 BTC (rund 89 Mio. US-Dollar) aus 4.585 Adressen. Chainalysis zufolge wurden besonders vermögende Ziele zuerst angegangen; innerhalb der ersten 10 Minuten sollen mehr als 30 Mio. US-Dollar eingesammelt worden sein. Eine einzelne Wallet verlor rund 1,8 Mio. US-Dollar. Das Muster spricht für eine vorbereitete, sequenzielle Abarbeitung bereits identifizierter Zieladressen. Der großflächige Sweep lief nahezu 30 Stunden, bevor Coinkite die erste öffentliche Warnung veröffentlichte. Galaxy Research identifizierte später rund 600 mutmaßliche Angreifer-Adressen und leitete diese an Ermittler weiter. Zudem beobachtete das Research-Team ähnliche operative Muster in Welle 1 und 2, während Welle 3 andere Sammelmethoden nutzte. Wichtig ist die Abgrenzung: Es gab keinen Gerätezugriff und keinen Diebstahl von Seed-Phrasen im klassischen Sinne. Die betroffenen Seeds waren bereits bei der Initialisierung schwach; genau das machte eine Rekonstruktion der Private Keys ohne Zugriff auf die Hardware möglich. Für ein Produkt, das Online-Risiken durch Offline-Schlüsselhaltung reduzieren soll, ist das besonders gravierend. Zeitachse zur Schwachstelle (Auswahl) - 1. März 2021: Ein Firmware-Commit ersetzt ckcc.rng_bytes (Hardware-RNG) durch ngu.random.bytes (Software-PRNG). Quellen: Coinkite Advisory; Block-Analyse. - 17. März 2021: Firmware v4.0.0 wird ausgeliefert; ab diesem Zeitpunkt erzeugte Seeds bei Mk2/Mk3 effektiv nur noch rund 40 Bit Entropie. Quelle: Coinkite Advisory. - 2021–2026: Der Fehler bleibt über fünf Jahre und mehrere Updates, Security-Reviews sowie ein KI-gestütztes Audit unentdeckt. Quellen: crypto.news; Bitcoin Magazine. - 30. Juli 2026, ca. 12:00 UTC: Welle 1 mit 594 BTC Verlust in 25 Minuten; Fokus auf High-Value-Wallets. Quellen: Lookonchain; Block; Chainalysis; 24/7 Wall St. - 30. Juli 2026: Welle 2 mit insgesamt 1.082 BTC über 1.196 Adressen in 41 Minuten. Quellen: Galaxy Research; The Hacker News. - 30.–31. Juli 2026: Coinkite veröffentlicht Advisory, rät zur Seed-Migration und stellt gepatchte Firmware bereit. Quellen: Coinkite Blog; Bitcoin Magazine. - 31. Juli 2026: Block (Unternehmen von Jack Dorsey) publiziert eine unabhängige technische Analyse zur RNG-Schwachstelle. Quelle: Block-Analyse. - 1.–2. August 2026: Welle 3; kumuliert 1.367 BTC über 4.585 Adressen. Coinkite erweitert Advisory um Mk4, Mk5 und Q. Quellen: PYMNTS; CyberInsider; Galaxy Research. - 2.–3. August 2026: Galaxy Research meldet ca. 600 verdächtige Angreifer-Adressen an Ermittlungs- und Compliance-Stellen. Quellen: The Hacker News; Galaxy Research. Der Kernfehler: Eine Codezeile, fünf Jahre unentdeckt Am 1. März 2021 wurde in der Firmware die Seed-Erzeugung umgestellt: Statt echter Zufallswerte aus dem Hardware-RNG des STM32-Chips (ckcc.rng_bytes) kam ein softwarebasierter PRNG (ngu.random.bytes) zum Einsatz, gespeist aus deterministischen Eingaben wie Seriennummer, Timer-Werten und dem Verlauf vorheriger RNG-Aufrufe. Diese Inputs wurden anschließend per SHA256d gehasht. Hashing kann Daten mischen, erzeugt aber keine neue Entropie: Wenn der Eingang nur 2^40 Zustände zulässt, bleibt auch der Ausgang effektiv bei 2^40 Möglichkeiten. Damit lagen Mk2/Mk3-Seeds bei etwa 40 Bit Entropie. Mk4, Mk5 und Q erhielten zusätzlich Input aus einem Secure Element und kamen so auf grob 72 Bit. Beide Werte liegen deutlich unter dem in der Praxis erwarteten Sicherheitsniveau von 128 Bit für Bitcoin-Seed-Generierung. Foundation Devices-CEO Zach Herbert ordnete den Bug als Nebenprodukt eines großen Firmware-Umbaus im März 2021 ein, bei dem verbleibender GPL-Code durch neue Kryptobibliotheken ersetzt wurde. Unabhängig vom Motiv blieb der fehlerhafte Code fünf Jahre aktiv. Coinkite hatte wenige Wochen vor dem Angriff ein KI-gestütztes Firmware-Audit durchgeführt, das den Fehler ebenfalls nicht erkannte. Wie der Angriff funktionierte: Offline-Rekonstruktion und Brute-Force Die Täter mussten weder Geräte entwenden noch sich auf die Coldcards aufschalten. Entscheidend war, dass sich zentrale Variablen (z.B. Geräte-UID, Timer-Zustand, Sequenz vorheriger RNG-Calls) in realistischen Grenzen abschätzen lassen. Mit diesen Einschränkungen konnten Kandidaten-Seed-Ströme offline reproduziert werden. Anschließend wurden daraus Bitcoin-Adressen abgeleitet und mit öffentlich einsehbaren On-Chain-Daten abgeglichen. Sobald eine Kandidaten-Seed eine Adresse mit Guthaben traf, konnten die passenden Private Keys abgeleitet und die Funds abgezogen werden. Bei rund 40 Bit Entropie entspricht der Suchraum etwa einer Billion Möglichkeiten. Das ist groß, aber mit moderner Hardware in praktischer Zeit durchsuchbar, insbesondere wenn sich die Zielmenge auf Seeds aus dem Zeitraum 2021 bis 2026 eingrenzen lässt. Galaxy Research hält es für möglich, dass Welle 1 und 2 vom selben Akteur stammen, während Welle 3 anderes On-Chain-Verhalten zeigte. Damit ist auch ein zweiter, unabhängig agierender Angreifer denkbar. Für Mk4/Mk5/Q mit etwa 72 Bit Entropie gibt es laut Bericht keine bestätigte Ausnutzung im großen Stil. Block bezeichnete das Design dennoch als "gefährliche Fail-open-Struktur", weil bestimmte Boot-Bedingungen die Suche auf nur 2^32 Werte reduzieren könnten. Eine breite Ausnutzung dieser Teil-Schwäche wurde bisher nicht beobachtet. Wer betroffen ist: Risiko hängt vom Seed-Erstellungszeitpunkt ab Entscheidend ist nicht, welche Firmware heute installiert ist, sondern welche Firmware beim Erzeugen des Seeds aktiv war. Eine spätere Aktualisierung macht einen bereits erzeugten schwachen Seed nicht stärker. Betroffene Modelle und Fixes (laut Advisory) - Mk2 / Mk3: Seed-Erzeugung unter v4.0.0 / v4.0.1 bis v4.1.9; effektive Entropie ~40 Bit; behoben ab v4.2.0+; höchstes Risiko, aktiv ausgenutzt. - Mk4 / Mk5: vor v5.6.0 (Standard) bzw. vor v6.6.0X (Edge); effektive Entropie ~72 Bit; Fix ab v5.6.0+ / v6.6.0X+; keine bestätigte Massen-Ausnutzung, aber unter Standard. - Q: vor v1.5.0Q (Standard) bzw. vor v6.6.0QX (Edge); effektive Entropie ~72 Bit; Fix ab v1.5.0Q+ / v6.6.0QX+; vergleichbares Restrisiko wie Mk4/Mk5. Wichtig: Nutzer, die bei der Seed-Erstellung mindestens 50 unabhängige und private Würfelwürfe eingebracht haben, fügten echte externe Entropie hinzu. Das kann die Schwäche des Software-RNG übersteuern. Eine starke BIP39-Passphrase erschwert Brute-Force, repariert aber den zugrunde liegenden Seed nicht. Coinkite empfiehlt daher weiterhin die Migration von Guthaben, die aus betroffenen Seeds stammen. Empfohlene Maßnahmen je Setup (Kurzüberblick) - Seed vor der Änderung im März 2021 erstellt: in der Regel nicht betroffen; keine Migration nur wegen dieser Schwachstelle. - Seed auf verwundbarer Firmware mit mindestens 50 privaten Würfelwürfen: minimales Risiko; Setup-Dokumentation prüfen und offizielle Hinweise befolgen. - Seed auf verwundbarer Firmware ohne ausreichende Würfel-Entropie: als kompromittiert behandeln; neue Seed erstellen und Guthaben migrieren. - Seed mit starker BIP39-Passphrase: Angriffsrisiko geringer, Seed bleibt schwach; Migration empfohlen. - Multisig mit Coldcard-Schlüssel aus betroffenem Seed: Risiko hängt vom Threshold ab; betroffene Keys rotieren und Policy prüfen. Trezor, Ledger und Block (Bitkey) erklärten, ihre Produkte nutzten andere Verfahren zur Entropie-Erzeugung; diese konkrete Coldcard-Schwäche betrifft Seeds dieser Geräte demnach nicht. Coinkites Reaktion: Patches und Kritikpunkte Coinkite veröffentlichte die erste Sicherheitswarnung am 30. und 31. Juli, rund 30 Stunden nach Beginn des Sweeps. Das Unternehmen stellte gepatchte Firmware für alle betroffenen Modelle bereit (u.a. v4.2.0 für Mk3, v5.6.0 für Mk4/Mk5, v1.5.0Q für Q), publizierte eine technische Analyse und eine Migrationsanleitung. Am 1. August wurde die Advisory erweitert, um die reduzierte Entropie bei Mk4/Mk5/Q zu berücksichtigen. Gleichzeitig gibt es substanzielle Kritik: Der Bug überstand fünf Jahre Produktion, Reviews und Security-Releases sowie ein kurz vor dem Angriff durchgeführtes KI-Audit. Zudem blieb Nutzern während der fast 30 Stunden bis zur ersten Warnung die Möglichkeit verwehrt, proaktiv zu migrieren. Sicherheitsforscher Kevin Loaec (Wizardsardine) weist außerdem darauf hin, dass Multisig-Setups mit betroffenen Coldcard-Keys als potenziell exponiert betrachtet werden sollten, was in der Advisory nicht vollständig adressiert sei. So migrieren Betroffene ihre BTC (Praxisleitfaden) Ein Firmware-Update allein macht eine bestehende Wallet nicht sicher, weil der schwache Seed bereits erzeugt wurde. Wer betroffen ist, muss einen neuen Seed erstellen und die Bestände übertragen. 1) Firmware aktualisieren: Neueste gepatchte Version für das jeweilige Modell/Release-Track installieren; Download ausschließlich über die offizielle Coinkite-Website verifizieren. 2) Neuen Seed erzeugen: Auf dem aktualisierten Gerät neu generieren, nicht den alten Seed importieren/restore. Für zusätzliche Entropie mindestens 50 unabhängige, private Würfelwürfe erwägen. 3) Backup prüfen: Seed-Wörter korrekt notieren und die Geräte-Verifikation abschließen. Empfangsadresse erzeugen und sicherstellen, dass Wallet-Software und Coldcard-Display dieselbe Adresse anzeigen. 4) Guthaben übertragen: Gesamten BTC-Bestand vom alten Seed auf Adressen des neuen Seeds senden. Zieladresse und Transaktionsdaten vor dem Signieren auf dem Gerät prüfen. 5) Migration verifizieren: Bestätigungen im Blockexplorer prüfen; alte Adressen auf Restbestände kontrollieren; neuer Wallet-Bestand muss vollständig sein. 6) Altes Seed-Backup sicher vernichten: Erst nach vollständiger Bestätigung und erfolgreichem Zugriff auf den neuen Seed; alle physischen und digitalen Kopien entfernen. Zu beachten: Jede Migration erfordert On-Chain-Transaktionen. Netzwerkgebühren sollten einkalkuliert werden; in einer akuten Lage kann eine zu niedrig gewählte Fee riskant sein. Multisig-Nutzer müssen zusätzlich alle betroffenen Schlüssel rotieren, den Threshold prüfen und die neue Konfiguration verifizieren, bevor größere Beträge bewegt werden. Einordnung: Was der Vorfall für Self-Custody bedeutet Self-Custody beruht auf zwei Säulen: Kontrolle über die Private Keys und eine robuste, echte Zufallsquelle bei der Schlüsselgenerierung. Der Vorfall zeigt, dass vollständige Key-Kontrolle nicht ausreicht, wenn die Entropie bei der Erzeugung vorhersagbar ist. Er reiht sich zudem als dritter großer PRNG-Ausfall der letzten Jahre ein, nach Milk Sad (2023) und Ill Bloom (2026). Solche Fehler sind für Nutzer oft kaum überprüfbar: Eine Wallet kann korrekte Seed-Phrasen anzeigen und gültige Adressen erzeugen, während die Entropie im Hintergrund unzureichend ist. Auch die Open-Source-Debatte erhält neue Schärfe: Coldcard stellt den Firmware-Quellcode öffentlich bereit, dennoch blieb der Bug fünf Jahre unentdeckt. Quelloffenheit ist keine Garantie für Sicherheit, aber weiterhin eine Voraussetzung für unabhängige Audits. CoinDesk berichtete, der Vorfall könne einzelne Investoren in Richtung Bitcoin-ETFs bewegen. Damit entfallen operative Risiken rund um Seed-Erzeugung und Schlüsselverwaltung, werden aber durch Verwahr- und Gegenparteirisiken ersetzt. Blockaid zufolge waren in der ersten Hälfte 2026 kompromittierte Schlüssel und operative Sicherheitsfehler die häufigste Ursache für Krypto-Verluste, nicht Smart-Contract-Exploits. Der Coldcard-Fall passt in dieses Muster: Angegriffen wurde der Key-Generation-Prozess, nicht Bitcoin selbst. Cold Storage bleibt für viele Langfrist-Halter sinnvoll, ist aber nicht unfehlbar. Hinweis: Dieser Beitrag dient ausschließlich Informations- und Bildungszwecken und stellt keine Finanz-, Anlage-, Rechts- oder Sicherheitsberatung dar. FAQ zum Coldcard-Exploit - Ist meine Coldcard kompromittiert? Ein Risiko besteht insbesondere, wenn der Seed auf Mk2 oder Mk3 mit Firmware v4.0.0 bis v4.1.9 ohne ausreichende Würfel-Entropie erzeugt wurde. Mk4, Mk5 und Q, deren Seeds vor den Patches erstellt wurden, liegen bei etwa 72 Bit Entropie; eine breit bestätigte Ausnutzung ist nicht bekannt, das Niveau bleibt aber unter dem erwarteten Standard. Empfohlen werden Update, neuer Seed und vollständige Migration. - Behebt ein Firmware-Update das Problem? Nein. Updates sichern nur die zukünftige Seed-Erzeugung. Ein bereits schwach erzeugter Seed bleibt schwach. Es braucht einen neuen Seed und die Übertragung aller Bestände. - Sind Ledger und Trezor betroffen? Nein. Ledger, Trezor und Block (Bitkey) gaben an, andere Entropie-Verfahren zu nutzen; diese konkrete Coldcard-Schwäche betrifft deren Seeds nicht. - Wie viel BTC wurde gestohlen? Stand 2. August 2026: rund 1.367 BTC im Wert von etwa 89 Mio. US-Dollar über drei Wellen; betroffen sind 4.585 Adressen. Die Untersuchung läuft, Zahlen können sich ändern. - Wer steckt dahinter? Der Angreifer ist nicht identifiziert. Galaxy Research vermutet für Welle 1 und 2 denselben Operator; Welle 3 könnte auf einen separaten Akteur hindeuten. Rund 600 verdächtige Adressen wurden gemeldet. - Schützen Würfelwürfe? Ja, sofern mindestens 50 unabhängige und private Würfelwürfe bei der Seed-Erzeugung genutzt wurden. Das fügt echte externe Entropie hinzu, die der defekte RNG nicht reduzieren kann. Coinkite sieht in diesem Fall ein minimales Risiko im Kontext dieser Schwachstelle.