Bekannte Sicherheitsvorfälle, Angriffsmethoden und forensische Möglichkeiten nach dem Diebstahl von Kryptowerten — von der Seed-Erzeugung bis zur strukturierten Ursachenanalyse.
Whitepaper 2026
Management Summary
Hardware Wallets gelten als eine der sichersten Möglichkeiten der Selbstverwahrung. Der Grundgedanke: Private Keys liegen nicht auf Computer oder Smartphone, sondern in einer dafür entwickelten Hardware. Daraus wird jedoch oft die technisch zu weit gehende Aussage abgeleitet, Kryptowährungen auf einer Hardware Wallet könnten „nicht gehackt werden“. Hardware Wallets reduzieren Risiken erheblich — sie beseitigen sie nicht.
Die Sicherheit eines Hardware Wallets ist nicht allein eine Eigenschaft des Geräts. Sie entsteht aus einer Sicherheitskette: Herstellung, Lieferweg, Initialisierung, Seed-Erzeugung, Firmware, Hardware, App oder Hostsystem, Transaktionsfreigabe, Backup und Nutzerverhalten.
Dokumentierte Vorfälle zeigen unterschiedliche Angriffswege: physische Seed-Extraktion, Fault-Injection- und Voltage-Glitching-Angriffe, fehlerhafte Zufallszahlenerzeugung, Firmware-Schwachstellen, kompromittierte Softwarebibliotheken, Supply-Chain- und Evil-Maid-Szenarien sowie sensible Schlüsseldaten in App-Protokollen. Aus forensischer Sicht bedeutet ein Diebstahl von einer Hardware Wallet deshalb keineswegs automatisch, dass der Geschädigte seinen Seed weitergegeben hat — und ein unautorisierter Transfer beweist für sich genommen keinen Hardware-Hack.
Der Grundsatz „Not your keys, not your coins“ prägt die Kryptowelt. Hersteller wie Ledger, Trezor, Tangem, BitBox, COLDCARD, OneKey, SafePal, Keystone oder Ellipal verfolgen dabei unterschiedliche technische Konzepte — bei Mikrocontrollern, Secure Elements, Firmware, Seed-Erzeugung, Backup, Display/Eingabe, Kommunikationswegen (USB, Bluetooth, NFC, QR) und dem Anteil offener Software. Eine pauschale Bewertung „Hersteller A sicher, Hersteller B unsicher“ wäre daher weder technisch noch forensisch sinnvoll.
Grundlage sind Sicherheitsmitteilungen der Hersteller, veröffentlichte Forschungs- und Auditberichte sowie Fachberichterstattung; eigene Laborprüfungen wurden für diese Fassung nicht durchgeführt. Herstellerangaben sind Parteivortrag. Schadenshöhen laufender Vorfälle sind Momentaufnahmen. Eine nachgewiesene Schwachstelle belegt keinen Vermögensdiebstahl; ein Diebstahl belegt keine Geräteschwachstelle. Maßgeblich ist der im Deckblatt genannte Stand.
Eine Hardware Wallet speichert streng genommen keine Coins — die Assets liegen in der Blockchain. Das Gerät verwaltet die Schlüssel, mit denen Transaktionen autorisiert werden:
Die Signatur soll innerhalb der geschützten Umgebung erfolgen; der private Schlüssel wird gegenüber dem Hostsystem nicht offengelegt. Diese Isolation ist der wesentliche Vorteil gegenüber Software Wallets — sie schützt aber nur, wenn der Seed korrekt und zufällig erzeugt wurde, nicht anderweitig offengelegt ist, die Firmware korrekt arbeitet, das Gerät nicht manipuliert wurde und der Nutzer tatsächlich die beabsichtigte Transaktion bestätigt.
Die Sicherheit sollte nicht auf einen einzelnen Chip reduziert werden. Forensisch relevant ist die gesamte Kette:
Ein Fehler an nur einer Stelle kann das Gesamtsystem schwächen. Nach einem Diebstahl ist deshalb zuerst zu klären, auf welcher Ebene ein Angriff technisch möglich war und welche Hypothesen durch die vorhandenen Spuren tatsächlich gestützt werden.
Wer den vollständigen Seed hat, braucht das Originalgerät nicht mehr — er kann Assets transferieren, während das Gerät beim Opfer bleibt. Wege: Phishing/gefälschter Support, Fotografieren oder Kopieren des Seeds, Cloud-/Datei-Backups, Eingabe auf Computer oder Website, gefälschte Wallet-Software, vorgegebener Seed bei manipulierten Geräten.
Eine Wallet ist nur so sicher wie ihre Zufallswerte. Bei vorhersehbarer oder zu kleiner Entropie kann ein Angreifer mögliche Seeds offline berechnen und mit öffentlichen Blockchain-Adressen abgleichen.
Firmware steuert zentrale Sicherheitsfunktionen. Fehler können Schlüsselerzeugung, Signaturprüfung, Updates, Speicherzugriffe oder die Kommunikation zwischen Sicherheitskomponenten betreffen.
Fault Injection, Voltage Glitching, Side-Channel-Analysen, Speicherextraktion und Bus Sniffing erfordern physischen Zugriff und sind von Remote-Angriffen klar zu trennen.
Auch wenn der Private Key das Gerät nicht verlässt, können Malware oder manipulierte Anwendungen die Oberfläche verändern, Empfangsadressen austauschen oder den Nutzer zur Seed-Preisgabe bewegen.
Ein Gerät kann vor der ersten Nutzung kompromittiert werden: ausgetauschte Geräte, manipulierte Verpackungen, veränderte Firmware, vorgegebene Seeds, gefälschte Begleitkarten oder nachgeahmte Herstellerseiten und Apps.
Der COLDCARD-Vorfall des Sommers 2026 zeigt, dass ein Hardware Wallet kompromittiert sein kann, ohne dass ein Angreifer es je berührt oder aus der Ferne übernommen hat. Mechanismus: Ein Build- und Link-Integrationsfehler führte dazu, dass die Seed-Erzeugung nicht die vorgesehene Hardware-TRNG-Implementierung, sondern den in MicroPython enthaltenen Software-PRNG Yasmarang verwendete. Eine Schutzabfrage prüfte nur, ob ein Konfigurationswert gesetzt war — nicht, ob er von null verschieden war. Der Hardware-Generator fiel nicht aus, wurde aber schlicht nicht erreicht. [1][2]
Auswirkung: Die effektive Schlüsselstärke sank auf rund 40 Bit (Mk2/Mk3) bzw. rund 72 Bit (Mk4/Mk5/Q) statt 128 Bit. Ein Suchraum von 40 Bit ist mit moderner Rechenleistung praktisch angreifbar; TRM Labs bezeichnet die Schlüssel als ohne physischen Zugriff durchsuchbar. Ausmaß: Ab dem 30. Juli 2026 wurden Adressen in mehreren Wellen geleert — in der ersten Welle rund 594 BTC aus etwa 500 Wallets in 25 Minuten. Laut TRM Labs (05.08.2026) rund 1.816 BTC aus über 5.200 Adressen in vier Wellen, Gegenwert etwa 116 Mio. US-Dollar; keine abschließende Schadensbilanz. [2][4]
Ausnahmen: Seeds mit mindestens 50 fairen, unabhängigen Würfelwürfen gelten hinsichtlich dieses RNG-Problems als nicht gefährdet. Eine starke, nur einmal verwendete BIP-39-Passphrase erschwert die Ausnutzung, repariert den schwachen Seed aber nicht. Entscheidend: Ein Firmwareupdate repariert einen bereits erzeugten schwachen Seed nicht — betroffene Wallets müssen auf einen neu erzeugten Seed migriert werden. [1][2][3]
Das Opfer kann den Seed niemals digitalisiert, das Gerät nie aus der Hand gegeben und keine unbekannte Transaktion bestätigt haben – und dennoch können Assets entwendet werden, wenn die Schlüssel schon bei ihrer Erzeugung unzureichend geschützt waren.
| Merkmal | Hinweis auf Kohorten-/RNG-Fall | Hinweis auf Einzelkompromittierung |
|---|---|---|
| Zeitliche Verteilung | viele nicht verbundene Geschädigte innerhalb weniger Stunden oder Tage | einzelner Geschädigter, kein zeitliches Muster |
| Gemeinsamkeiten | gleiches Modell/Modellreihe, Seed-Erzeugung im selben Firmwarezeitraum | keine gemeinsame technische Grundlage erkennbar |
| Vorgeschichte | kein Phishing, kein Support-Kontakt, kein digitalisierter Seed | Phishing, Support-Chat, Screenshot oder Cloud-Backup nachweisbar |
| Adressauswahl | Abfluss ohne jede vorherige Interaktion mit dem Täter | gezielte Ansprache oder vorherige Kontaktaufnahme |
| Transaktionsmuster | Sweeps über viele Adressen in kurzer Folge, oft ohne Rücksicht auf Gebühren | einzelner Abfluss, oft nach einer Testtransaktion |
| Gegenmaßnahmen | bei schwachem Seed: Firmwareupdate genügt nicht; Migration erforderlich | Neueinrichtung/Bereinigung der Umgebung kann genügen |
Ledger Donjon (2019) und Kraken Security Labs (2020, Voltage Glitching) demonstrierten mit physischem Zugriff das Auslesen von Speicher und die Extraktion eines Seeds bei Trezor One / Model T. Keine Remote-Hacks — sie setzen Gerätebesitz, Know-how und Ausrüstung voraus. [7][8]
Ledger Donjon brachte per 1064-nm-Laser die Ed25519-Signaturprüfung des Secure Elements TROPIC01 dazu, eine ungültige Signatur als gültig zu werten, und konnte in Kombination eigene Firmware ausführen (Offenlegung 03.06.2026). Die gespeicherten Geheimnisse liegen hinter einem Hardwaremechanismus (MAC-and-Destroy). Der Chiphersteller stuft die Lücke mit CVSS 5,7 (mittel) ein; der Angriff setzt Entkapselung, Laborausrüstung (>30.000 €) und vollständigen Gerätebesitz voraus, ein Nachweis realer Ausnutzung liegt nicht vor. Der Befund liegt auf Siliziumebene und ist nicht per Firmwareupdate behebbar. [5][6][19][20]
Über einen API-Schlüssel gelangte ein Angreifer an Ledgers E-Commerce-/Marketingdatenbank: über eine Million E-Mail-Adressen und rund 272.000 Datensätze mit weiteren Personendaten. Private Keys waren nicht unmittelbar betroffen, das Risiko gezielter Phishing- und physischer Angriffe auf bekannte Besitzer stieg jedoch. [9]
Im Dezember 2023 verbreitete ein Angreifer nach Phishing gegen einen Ex-Mitarbeiter manipulierte Versionen des Ledger Connect Kit über NPMJS; einbindende DApps konnten Schadcode laden und Assets abfließen lassen. Die Hardware selbst war nicht kompromittiert — entscheidend war die Software- und Integrationsumgebung. [10]
Bei mit Seed Phrase aktivierten Wallets konnte der Private Key irrtümlich in App-Logs erscheinen; potenziell betroffen waren Nutzer, die zusätzlich binnen sieben Tagen Logs an den Support übermittelten. Tangem meldete keine festgestellten Nutzerverluste. Schwachstellen können also außerhalb des Wallet-Chips entstehen. [11]
Unciphered demonstrierte einen physischen Angriff über die unzureichend geschützte Kommunikation zwischen CPU und Secure Element; OneKey erklärte die Behebung. Entscheidend war der physische Zugriff, kein Remote-Angriff. [12]
Kraken Security Labs (2021) berichtete über Fragen zur Manipulationserkennung und ein mögliches Firmware-Downgrade, konnte aber keine Coins aus dem Gerät stehlen. Eine nachgewiesene Schwachstelle ist nicht automatisch ein Vermögensdiebstahl. [13]
Ledger Donjon (2019) berichtete über Schwachstellen inkl. Seed-Extraktion bei physischem Zugriff sowie reaktivierbare Schnittstellen (Supply-Chain-/Evil-Maid-Relevanz). Bemerkenswert, weil Ellipal mit „air-gapped“ Architektur warb: Air Gap reduziert die Angriffsfläche, ist aber keine Garantie gegen Hardware-/Firmwarefehler. [14]
Keylabs (2023) identifizierte u. a. eine hoch eingestufte Firmware-Schwachstelle (Manipulationsreaktion); nach Prüferangabe wurden die hoch eingestufte und weitere Feststellungen behoben und erneut getestet. Veröffentlichte Audits zeigen auch, dass ein Hersteller externe Prüfungen zulässt. [15]
BitBox beschreibt eine Dual-Chip-Architektur (Mikrocontroller + separater Secure Chip), verschlüsselte Seed-Speicherung, mehrere unabhängige Geheimnisse/Entropiequellen, Secure Bootloader, Geräteauthentisierung und Transaktionsprüfung am Display. In den ausgewerteten Quellen wurde kein mit COLDCARD 2026 vergleichbarer bestätigter Diebstahlsfall identifiziert — ausdrücklich keine Aussage über absolute Sicherheit. [16]
| Hersteller / Fall | Ebene | Zugriff | Realer Nutzerverlust? | Kernaussage |
|---|---|---|---|---|
| COLDCARD 2026 | Seed-Erzeugung / Firmware | kein physischer Zugriff nötig | Ja; Sweep-Wellen ab 30.07.2026 | Schwach erzeugte Schlüssel sind offline rekonstruierbar. |
| Trezor 2019/2020 | Hardware / physisch | physisch | nicht belegt; Extraktion demonstriert | Physischer Besitz kann bei älteren Designs entscheiden. |
| TROPIC01 2026 | Secure Element | Labor, Entkapselung | nicht belegt; Laborangriff | Auch Sicherheitschips können angreifbar sein. |
| Ledger 2020 | Kundendaten | remote gegen DB | nicht durch das Leck selbst | Herstellerdaten können Folgeangriffe ermöglichen. |
| Ledger Connect Kit 2023 | Software-Lieferkette | remote / DApp | Ja | Wallet-Hardware selbst nicht kompromittiert. |
| Tangem 2024 | Mobile App / Logs | Support-Konstellation | Nein (Herstellerangabe) | Schlüsseldaten können außerhalb des Chips exponiert werden. |
| OneKey Mini | Hardware-Integration | physisch | nicht belegt; Extraktion | CPU ↔ Secure Element ist Teil der Architektur. |
| SafePal S1 | Firmware / Schutz | physisch | nicht belegt; kein Diebstahl im Test | Schwachstelle ≠ Vermögensdiebstahl. |
| Ellipal 2019 | Hardware / physisch | physisch | nicht belegt; Extraktion | Air Gap schützt nicht vor jedem Fehler. |
| Keystone 3 Audit | Firmware / Hardware | Audit | nicht belegt; Befunde behoben | Externe Audits machen Risiken behebbar. |
Eine besonders problematische Angriffsklasse entsteht, bevor der Anwender das Gerät erstmals nutzt. Der Täter muss nicht sofort stehlen — er kann einen kompromittierten Seed oder eine manipulierte Umgebung vorbereiten und auf eine größere Einzahlung warten: Öffnen/erneutes Verpacken, Austausch durch gefälschte Geräte, manipulierte Firmware/Elektronik, vorgegebene Seeds, manipulierte Begleitkarten, gefälschte Websites/Apps.
| Zeitpunkt | Ereignis |
|---|---|
| Tag 1 | Manipulation oder Kenntnis des Seeds |
| Tag 5 | Nutzer aktiviert die vermeintlich neue Wallet |
| Tag 6 | kleine Testtransaktion |
| Tag 8 | größere Bitcoin-Übertragung |
| kurz danach | vollständiger Transfer auf eine unbekannte Adresse |
Ein Angreifer erhält vorübergehend physischen Zugriff und manipuliert das Gerät unbemerkt — bei Transport, Lagerung, Hotelaufenthalt, Reparatur, Versand oder persönlicher Übergabe.
Ein Nutzer kann glauben, ein Originalgerät zu verwenden, obwohl es eine Kopie, ein modifiziertes Original oder ein manipuliertes Gebrauchtgerät ist. Echtheitsprüfung und kontrollierte Lieferkette sind Teil des Sicherheitsmodells.
Das praktisch relevanteste Szenario ist das unspektakulärste: Der Eigentümer richtet die Wallet nicht selbst ein, sondern erhält ein bereits initialisiertes Gerät oder lässt die Einrichtung von Händler, Vermittler, Bekanntem oder „Experten“ übernehmen. Wer die Erstinitialisierung kontrolliert und den Schlüssel kennt oder eine Sicherungskopie zurückbehält, hat später weiterhin Zugriff — unabhängig davon, wer das Gerät besitzt. Tangem warnt: Geräte werden nie mit vorgenerierten Schlüsseln ausgeliefert; ein beiliegendes „Initialisierungspasswort“ ist ein Warnzeichen. Das Kopieren auf Sicherungsgeräte erfolgt nur einmalig bei der Erstinitialisierung — eine eingerichtete Wallet lässt sich nicht nachträglich bereinigen, sondern muss zurückgesetzt und neu erzeugt werden. Typisches Schadensbild: Abfluss nicht bei der Übergabe, sondern kurz nach der ersten nennenswerten Einzahlung. [17][18][21]
Nach einem Diebstahl sollte keine Ursache vorschnell angenommen werden. Sinnvoll ist eine strukturierte Untersuchung in mehreren Ebenen.
Ausgangsadresse und Transaktionshash; Zeitpunkt, Betrag, Netzwerkgebühr; Zieladresse und nachgelagerte Wallets; Konsolidierungen und Aufsplittungen; Swaps, Bridges und andere Protokolle; Einzahlungen auf zentrale Börsen oder identifizierbare Dienstleister.
Ein sehr kurzer Abstand zwischen Eingang und unautorisiertem Abfluss kann auf automatisierte Überwachung oder bereits vorhandenen Schlüsselzugriff hinweisen — beweist dies aber nicht.
| Ereignis | Beispielzeitpunkt |
|---|---|
| Wallet aktiviert | 14:05 Uhr |
| Empfangsadresse erstellt | 14:08 Uhr |
| BTC gesendet | 14:23 Uhr |
| Bestätigung im Netzwerk | 14:31 Uhr |
| Unbekannte Ausgangstransaktion | 14:37 Uhr |
Hersteller/Modell, Serien-/Geräteinformationen, Firmwareversion, Kaufdatum/Verkäufer, Verpackung und Manipulationsmerkmale, durchgeführte Updates, Wallet-App und Kopplungsart. Wichtig: Bei ungeklärtem Sachverhalt das Gerät nicht zurücksetzen, aktualisieren oder verändern — das kann spätere Prüfungen unmöglich machen. Zeitpunkt der Seed-Erzeugung und damalige Firmware festhalten (Kohortenprüfung). Gerät und Begleitmaterial mit dokumentierter Beweiskette verwahren.
Installationsquelle und Version der Wallet-Software; verdächtige Apps/Erweiterungen/Downloads; Supportkontakte; Screenshots, Dateien und mögliche Seed-Abbildungen; Hinweise auf Remote-Zugriffe oder Schadsoftware; Browserhistorie rund um Einrichtung und Transaktionen.
Zu klären ist, ob das Gerät direkt vom Hersteller, über autorisierten Händler, Online-Marktplatz, Privatperson, Berater, Vermittler oder angeblichen Finanzdienstleister bezogen wurde. Die Antwort kann die Risikoeinschätzung erheblich verändern.
„Meine Hardware Wallet wurde gehackt“ beschreibt nur die Wahrnehmung. Technisch möglich sind: (1) Seed kompromittiert, (2) Seed vorhersehbar/schwach erzeugt, (3) Hardware kompromittiert, (4) Firmware kompromittiert, (5) Software/App kompromittiert, (6) Transaktion manipuliert/irreführend dargestellt, (7) Lieferkette kompromittiert, (8) Social Engineering oder gefälschter Support.
Ein Gutachten sollte die Ursache nur dann als feststehend bezeichnen, wenn sie durch technische oder dokumentarische Belege gestützt wird. Plausible Alternativhypothesen sind ausdrücklich zu kennzeichnen.
Bewährt hat sich, von den überprüfbaren zu den unüberprüfbaren Annahmen zu arbeiten: zuerst die Kohortenfrage (bekannte Sicherheitsmitteilung zu Gerät/Modellreihe/Erzeugungszeitraum — ohne Mitwirkung Dritter beantwortbar), dann die dokumentierbaren Umstände (Beschaffung, Erstinitialisierung, Seed-Handhabung, Support-/Phishing-Kontakte, App-Quelle), dann die Blockchain (Zeitachse, Zielstruktur, Weiterleitung, Endpunkte), zuletzt die technischen Restszenarien, die nur im Labor oder mit physischem Zugriff erklärbar wären. Ein als offen gekennzeichneter Befund ist für Ermittlungsbehörden verwertbar; eine zu früh festgelegte Ursache ist es nicht.
| Angriffsszenario | Physischer Zugriff | Seed direkt benötigt | Ohne Gerätezugriff möglich? | Typische Blockchain-Spuren |
|---|---|---|---|---|
| Seed-Phishing | Nein | Ja | Ja | Abfluss wie regulär signierte Transaktion |
| Schwache Seed-Erzeugung | Nein | Nein | Ja (Offline-Rekonstruktion) | Abfluss wie regulär signierte Transaktion |
| Manipuliertes Gerät | Vor Nutzung / physisch | Nicht zwingend | Ja, nach Manipulation | Abfluss nach Einzahlung |
| Supply Chain | Vor Nutzung | Nicht zwingend | Ja, nach Manipulation | oft zeitnah oder ereignisgesteuert |
| Fault Injection | Ja | Nein | Nein | Abfluss nach Schlüsselgewinnung |
| Side Channel | Ja | Nein | Nein | Abfluss nach Schlüsselgewinnung |
| Firmware-Schwachstelle | abhängig | abhängig | abhängig vom Angriff | abhängig vom Angriff |
| App-/Software-Kompromittierung | Nein | nicht zwingend | Ja | manipulierte oder autorisierte Transaktion |
| Seed in Logdateien | Nein | indirekt | Ja, sofern Daten abgeflossen | regulär signierter Abfluss |
Die Matrix dient der ersten Strukturierung und ersetzt keine Einzelfallprüfung; verschiedene Angriffsklassen können kombiniert werden.
Zusätzliche Sicherheitsmaßnahmen erhöhen häufig auch die Komplexität. Ein Sicherheitskonzept muss deshalb nicht nur gegen Angreifer schützen, sondern vom Eigentümer dauerhaft und fehlerarm bedient werden können.
Der Begriff „Hardware Wallet“ ist kein Beweis dafür, dass ausschließlich der Geschädigte Zugriff auf die Private Keys hatte — umgekehrt ist ein unautorisierter Transfer nicht automatisch ein Produktfehler. Für eine belastbare Ersteinschätzung dokumentieren: Hersteller/Modell/Generation, Kaufquelle und -zeitpunkt, Initialisierung, Firmware/Updatehistorie, Art der Seed-Erzeugung und Aufbewahrung, Smartphone/Computer, Wallet-App und Quelle, letzter legitimer Zugriff, Zeitpunkt von Asset-Eingang und unautorisiertem Transfer, Zieladresse und weitere Wege.
Zwei Punkte werden regelmäßig übersehen: Erstens sollte das Gerät früh gesichert und nicht zurückgesetzt werden. Zweitens ist zu prüfen, ob weitere Geschädigte mit demselben Gerätetyp im selben Zeitfenster bekannt sind — fällt der Fall in eine bekannte betroffene Kohorte, spricht das deutlich gegen eine ausschließlich nutzerseitige Ursache. Die rechtliche Bewertung eines möglichen Mitverschuldens bleibt davon getrennt.
Hardware Wallets reduzieren viele klassische Cyberrisiken erheblich, sind aber keine absolute Sicherheitsgrenze. Der COLDCARD-Vorfall 2026 zeigt: Ein Angreifer muss das Gerät nicht besitzen oder aus der Ferne übernehmen — ist die Schlüsselerzeugung fehlerhaft, versagt das Sicherheitsmodell an seinem Ausgangspunkt. Umgekehrt darf nicht jeder Transfer vorschnell als „Hardware-Wallet-Hack“ gelten; Ursache können Seed-Kompromittierung, Phishing, manipulierte Software oder Lieferkettenrisiken sein.
Nicht das einzelne Hardware Wallet entscheidet über die Sicherheit der Kryptowährungen, sondern die gesamte Kette von der Erzeugung des Private Keys bis zur Freigabe einer Transaktion.
Für die Blockchain-Forensik ist anschließend entscheidend: Wann wurden die Assets transferiert? Welche Adresse hat sie erhalten? Wie wurden sie weitergeleitet? Welche Börsen, Bridges oder Dienstleister wurden genutzt? Und welche technische Erklärung ist mit den vorhandenen Beweisen tatsächlich vereinbar?
Herstellerangaben werden als solche behandelt und ersetzen keine unabhängige technische Bewertung. Verweise zuletzt im September 2026 abgerufen; Schadenshöhen sind Momentaufnahmen.
[1] Coinkite: Coldcard Security Advisory, 07/2026 · [2] Coinkite: Entropy Technical Deep Dive · [3] Coinkite: COLDCARD Security Update 5.6.1/1.5.1q · [4] TRM Labs: Inside the $116M Coldcard Hack, 08/2026 · [5][6] Trezor: TROPIC01 disclosure · [7] Ledger Donjon: Seed Extraction on Trezor, 2019 · [8] Kraken Security Labs: Trezor Flaw, 2020 · [9] Ledger: Data Breach Update, 2020 · [10] Ledger: Connect Kit Incident, 2023 · [11] Tangem: Log Issue, 2024 · [12] Unciphered: OneKey, 2023 · [13] Kraken: SafePal S1, 2021 · [14] Ledger Donjon: Ellipal, 2019 · [15] Keylabs: Keystone 3 Audit, 2023 · [16] BitBox02 Security Features · [17][18][21] Tangem: Pre-Activated Wallets / Firmware & Echtheit / Backup · [19] Ledger Donjon: LFI on TROPIC01, 06/2026 · [20] Tropic Square: TROPIC01 Security Advisory, 06/2026 · [22] COLDCARD: Security Status, 09/2026.
David Lüdtke
Geschäftsführer · OSINT-Analyst & Krypto-Forensiker · Finanz Forensik GmbH
Gerichtsfeste Kryptotransaktionsanalysen, OSINT-gestützte Vermögensermittlung und gutachterliche Aufbereitung für Strafverteidiger, Insolvenzverwalter und Unternehmen. Zertifiziert als Crystal Expert (CECF · CEEI · CEUI). Finanz Forensik unterstützt Kanzleien, Unternehmen, Ermittlungsstellen und Insolvenzverwalter — Schwerpunkte: Blockchain-Forensik, Wallet-Analyse, gerichtsfeste Dokumentation, OSINT.
Kontakt: postfach@finanz-forensik.de · +49 6057 9189145 · finanz-forensik.de
Wir klären die Kohortenfrage, sichern Gerät und Zeitachse, rekonstruieren die Blockchain-Spur und bereiten den Befund gerichtsfest für Kanzlei und Ermittlungsbehörde auf.
