Wenn Self-Custody versagt: Was aktuelle Bitcoin-Diebstähle über Wallet-Sicherheit, Schlüsselgenerierung und Infrastruktur zeigen

Executive Summary

Mehrere aktuelle Sicherheitsvorfälle im Bitcoin-Umfeld zeigen, dass der Schutz von Kryptoassets weit über die bloße Verwahrung eines Private Keys hinausgeht. Bei BTCPay Server ermöglichte eine kritische Schwachstelle den unautorisierten Zugriff auf Zugangsdaten einer LND-Instanz. Dadurch konnten betroffene Lightning Nodes kompromittiert und Gelder transferiert werden.

Bei COLDCARD führte ein Fehler in der Firmware dazu, dass die Seed Generation, also die Erzeugung des kryptografischen Ausgangswerts einer Wallet, unter bestimmten Bedingungen nicht wie vorgesehen auf den Hardware Random Number Generator zurückgriff. Stattdessen konnte ein softwarebasierter PRNG verwendet werden. Ein PRNG erzeugt Zufallswerte nicht direkt aus einer physikalischen Zufallsquelle, sondern berechnet sie aus einem internen Ausgangszustand.

War dieser Ausgangszustand zu vorhersehbar, stand für die Seed-Erzeugung deutlich weniger Entropy, also tatsächliche Unvorhersagbarkeit, zur Verfügung als vorgesehen.

Dadurch konnte sich der effektive Key Space, also die Zahl der praktisch möglichen Schlüssel, erheblich verkleinern.

Parallel dazu wurde über eine mutmaßlich gefälschte Wasabi-Wallet-Anwendung im Apple App Store berichtet, über die ein Nutzer rund sechs Bitcoin verloren haben soll. Unabhängig von der abschließenden Bewertung dieses konkreten Falls zeigt der Vorfall eine weitere wichtige Schwachstelle: Auch der Weg, über den Wallet-Software bezogen wird, ist Teil des Sicherheitsmodells.

Die drei Fälle betreffen unterschiedliche technische Ebenen, führen aber zu derselben Schlussfolgerung: Die Sicherheit einer Blockchain und die Sicherheit der darauf verwalteten Assets sind nicht dasselbe.

Bitcoin kann auf Protokollebene vollständig korrekt funktionieren, während Vermögenswerte durch kompromittierte Zugangsdaten, schwache Schlüsselgenerierung, manipulierte Software oder fehlerhafte Infrastruktur verloren gehen.

„Nicht die Blockchain muss kompromittiert werden. Es genügt, eine sicherheitskritische Komponente zwischen Blockchain und Nutzer zu kontrollieren.“

Bitcoin wurde nicht „gehackt“

Wenn Bitcoin gestohlen werden, wird häufig verkürzt davon gesprochen, Bitcoin selbst sei „gehackt“ worden.

Technisch ist das in den meisten Fällen nicht korrekt. Das Bitcoin-Netzwerk prüft, ob eine Transaktion die kryptografischen Bedingungen erfüllt, die notwendig sind, um die jeweiligen Bitcoin auszugeben.

Es prüft jedoch nicht, warum eine gültige Signatur erzeugt wurde oder ob jene Person, die über den erforderlichen Schlüssel verfügt, tatsächlich zur Verfügung über die Assets berechtigt ist.

Hat ein Angreifer Zugriff auf einen Private Key oder auf eine Infrastruktur erlangt, die eine Transaktion autorisieren kann, sieht die Blockchain zunächst nur eines: eine technisch gültige Transaktion.

Für eine realistische Sicherheitsbewertung müssen deshalb mehrere Ebenen unterschieden werden.

Protocol Security

Hier geht es um die Frage, ob das Bitcoin-Protokoll oder der Konsensmechanismus selbst kompromittiert wurde.

Key Security

Hier steht die Sicherheit des Private Keys beziehungsweise des Seeds im Mittelpunkt. Kann ein Angreifer diesen rekonstruieren, auslesen oder anderweitig kontrollieren?

Endpoint Security

Hier geht es um das Endgerät. Ist jener Computer oder jenes Smartphone vertrauenswürdig, auf dem Wallet-Software ausgeführt oder eine Transaktion vorbereitet wird?

Infrastructure Security

Hier werden Nodes, APIs, Zugangsdaten und administrative Schnittstellen betrachtet.

Supply Chain & Software Distribution

Hier geht es darum, ob Hardware, Firmware und Wallet-Software tatsächlich aus einer vertrauenswürdigen Quelle stammen und unverändert sind.

Human Security

Und schließlich bleibt der Mensch selbst Teil des Sicherheitsmodells. Phishing, Fake Support oder Social Engineering können selbst technisch sehr gute Schutzmaßnahmen umgehen.

Erst wenn diese Ebenen gemeinsam betrachtet werden, entsteht ein realistisches Bild der tatsächlichen Sicherheit.

Fall 1: BTCPay Server – wenn Zugangsdaten zur Kontrolle über einen Lightning Node führen

BTCPay Server veröffentlichte Anfang August 2026 eine kritische Security Advisory für Versionen vor 2.4.2.

Nach Angaben des Projekts konnte ein nicht authentifizierter Angreifer unter bestimmten Voraussetzungen auf .macaroon-Dateien einer eingebundenen LND-Instanz zugreifen.

BTCPay bestätigte, dass die Schwachstelle aktiv ausgenutzt wurde, Nutzer betroffen waren und Gelder gestohlen wurden.

Gleichzeitig wurde der Umfang des Vorfalls klar eingegrenzt: Die regulären BTCPay-On-Chain-Wallets waren von diesem spezifischen Angriff nicht betroffen. Betroffen war die LND-Umgebung. Innerhalb eines LND-Nodes verwaltete Guthaben konnten jedoch Teil der exponierten Infrastruktur sein.

Was ist ein Macaroon?

LND verwendet sogenannte Macaroons als kryptografisch abgesicherte Berechtigungsnachweise.

Vereinfacht gesagt funktionieren sie ähnlich wie digitale Zugangsschlüssel, denen bestimmte Rechte zugewiesen werden. Je nach Berechtigungsumfang kann ein Macaroon beispielsweise ermöglichen, Informationen aus einem Node auszulesen oder bestimmte Funktionen auszuführen.

Ein Macaroon ist kein Bitcoin Private Key.

Operativ kann ein ausreichend privilegiertes Macaroon dennoch ähnlich kritisch sein: Wer es kontrolliert, kann unter Umständen Funktionen eines Nodes ausführen, ohne den eigentlichen Wallet-Seed zu kennen.

Damit zeigt der Fall sehr deutlich, warum die einfache Vorstellung

„Solange niemand meinen Seed kennt, sind meine Bitcoin sicher“

für komplexere Infrastrukturen nicht ausreicht.

Der eigentliche Attack Vector

Der Attack Vector, also der konkrete technische Angriffsweg, lag hier nicht in der Bitcoin-Blockchain.

Auch die mathematische Sicherheit der zugrunde liegenden Signaturverfahren wurde nicht gebrochen. Angegriffen wurde eine Autorisierungsebene innerhalb der Infrastruktur.

Das ist ein entscheidender Unterschied. Neben Seed Phrases und Private Keys müssen deshalb auch andere Komponenten als hochsensible Secrets behandelt werden:

• LND Macaroons
• API Keys
• RPC Credentials
• Session Tokens
• administrative Zugangsdaten
• Konfigurationsdateien mit Zugangsdaten
• Backup- und Wallet-Dateien
• Secrets innerhalb von Server- oder Container-Umgebungen

Die zentrale Frage lautet deshalb nicht nur:

„Wo befindet sich mein Private Key?“

Sondern:

„Welche weiteren Komponenten können mittelbar oder unmittelbar eine Verfügung über meine Assets ermöglichen?“

Warum die Attack Surface entscheidend ist

In der IT-Sicherheit wird die Gesamtheit aller technisch erreichbaren Angriffsmöglichkeiten als Attack Surface bezeichnet.

Je mehr Dienste ein System nach außen anbietet, desto größer wird grundsätzlich diese Angriffsfläche.

Dazu können beispielsweise gehören:

• offene Ports
• Reverse Proxies
• externe APIs
• Remote-Zugänge
• Tor Services
• administrative Weboberflächen

BTCPay empfahl Betreibern, die nicht unmittelbar aktualisieren konnten, betroffene LND-Installationen vorübergehend offline zu nehmen.

Der Fall zeigt zugleich einen wichtigen Grundsatz:

„Ein Patch behebt eine konkrete Schwachstelle. Er ersetzt keine Überprüfung der gesamten Attack Surface.“

Ein System kann also korrekt aktualisiert sein und trotzdem über andere, selbst konfigurierte Zugangswege exponiert bleiben.

Kurz gesagt:

„Ein Lightning Node ist Zahlungsinfrastruktur – kein langfristiger Tresor.“

Fall 2: COLDCARD – die Sicherheitslücke bei der Seed Generation

Der COLDCARD-Vorfall betrifft eine noch grundlegendere Ebene. Hier ging es nicht darum, einen bereits sicher erzeugten Private Key aus einem Gerät zu extrahieren.

Das Problem lag nach den veröffentlichten technischen Analysen bereits bei der Seed Generation.

Der Seed ist vereinfacht gesagt der kryptografische Ausgangspunkt einer deterministischen Wallet. Aus ihm können später die zugehörigen Private Keys und Adressen abgeleitet werden.

Coinkite und Block veröffentlichten detaillierte Analysen zu einem Fehler innerhalb der Random-Number-Generation der COLDCARD-Firmware. Die kryptografische Bibliothek selbst war dabei nicht das Problem. Entscheidend war ihre Integration in die Firmware.

Der technische Fehler

COLDCARD hatte ursprünglich einen hardwarebasierten Random Number Generator verwendet. Ein solcher Hardware RNG erzeugt Zufallswerte mithilfe einer speziellen Hardwarekomponente.

Im Zuge einer späteren Firmware-Änderung wurde die Seed Generation auf einen anderen Codepfad verlagert.

Dieser griff jedoch nicht wie vorgesehen auf den Hardware RNG zurück. Stattdessen konnte MicroPythons softwarebasierter Yasmarang-PRNG verwendet werden. Ein PRNG – Pseudo Random Number Generator – erzeugt Werte deterministisch aus einem internen Ausgangszustand. Das ist nicht grundsätzlich unsicher.

Moderne kryptografische Systeme verwenden regelmäßig sichere PRNGs. Problematisch wird es jedoch dann, wenn der interne Ausgangszustand nur wenig echte Entropy enthält. Genau darin lag das Risiko.

Warum der Fehler so schwerwiegend war

Besonders problematisch war eine Build-Konfiguration, bei der eine RNG-Funktion im Code zwar als vorhanden galt, tatsächlich aber deaktiviert war.

Vereinfacht gesprochen wurde geprüft:

„Existiert diese Funktion?“

aber nicht ausreichend:

„Wird tatsächlich die sichere Hardware-Funktion verwendet?“

Dadurch konnte die Firmware erfolgreich gebaut werden, obwohl bei der Seed Generation ein anderer Random-Number-Generator verwendet wurde als vorgesehen.

Aus Sicht von Software Security ist das eine wichtige Erkenntnis:

„Nicht entscheidend ist, welcher Security Code irgendwo im System vorhanden ist. Entscheidend ist, welcher Code zur Laufzeit tatsächlich ausgeführt wird.“

PRNG ist nicht automatisch unsicher

Gerade für technisch weniger versierte Leser ist hier eine Präzisierung wichtig.

PRNG bedeutet nicht automatisch „unsicher“. Ein cryptographically secure PRNG kann sehr sichere Zufallswerte erzeugen.

Entscheidend ist, wie er initialisiert wird. Der interne Ausgangswert eines PRNG wird häufig als Seed State bezeichnet.

Wenn dieser State ausreichend unvorhersagbar ist, kann auch der daraus erzeugte Output kryptografisch sicher sein.

Ist der Ausgangszustand dagegen stark eingeschränkt oder teilweise vorhersehbar, kann auch der spätere Output nur aus einer begrenzten Menge möglicher Werte stammen.

Und genau das wird bei der Erzeugung von Bitcoin-Schlüsseln kritisch.

Warum Entropy entscheidend ist

Entropy beschreibt in diesem Zusammenhang vereinfacht die Menge an tatsächlicher Unvorhersagbarkeit.

Je höher die Entropy, desto größer ist die Zahl realistischer Möglichkeiten, aus denen ein Schlüssel stammen kann.

Bei einem korrekt erzeugten kryptografischen Schlüssel ist dieser Raum so groß, dass ein vollständiges Durchprobieren praktisch ausgeschlossen ist.

Sinkt die Entropy jedoch deutlich, reduziert sich dieser sogenannte Key Space.

Der Key Space ist die Menge aller Schlüssel, die ein Angreifer theoretisch überprüfen müsste.

Je kleiner dieser Raum wird, desto realistischer kann eine sogenannte Brute-Force-Suche werden – also das systematische Durchprobieren möglicher Schlüssel.

Warum Hashing fehlende Entropy nicht repariert

Dieser Punkt wird häufig missverstanden. Ein schwacher Zufallswert kann anschließend durch eine Hashfunktion verarbeitet werden und danach wie ein vollkommen zufälliger 256-Bit-Wert aussehen.

Das bedeutet jedoch nicht, dass dadurch zusätzliche Sicherheit entstanden ist.

Eine Hashfunktion kann vorhandene Information verteilen. Sie kann aber keine zusätzliche unbekannte Information erzeugen.

Ein einfaches Beispiel: Angenommen, ein System kann aufgrund einer fehlerhaften Zufallsquelle nur eine Million unterschiedliche Ausgangswerte erzeugen. Auch wenn jeder dieser Werte anschließend mit SHA-256 gehasht wird, existieren weiterhin nur eine Million relevante Möglichkeiten. Die Ergebnisse sehen zwar wie zufällige 256-Bit-Werte aus. Ein Angreifer muss jedoch weiterhin nur diese eine Million Kandidaten prüfen.

Das grundlegende Prinzip lautet:

„Hashing verteilt Entropy. Hashing erzeugt keine Entropy.“

Wie stark wurde der Key Space reduziert?

Die Auswirkungen unterscheiden sich je nach Gerätegeneration und Konfiguration. Coinkite schätzt den effektiven Suchraum für bestimmte betroffene Mk2-/Mk3-Konfigurationen nach aktuellem Stand auf ungefähr 40 Bit. Bei späteren Geräten wie Mk4, Q und Mk5 wurde zusätzliche Entropy aus Secure Elements eingebracht.

Ein Secure Element ist ein speziell abgesicherter Hardwarebaustein, der kryptografische Funktionen und Secrets schützen soll. Dadurch wurden die Auswirkungen reduziert.

Nach Herstellerangaben wurde das ursprünglich angestrebte Sicherheitsniveau dennoch nicht vollständig erreicht. Dort wird derzeit von ungefähr 72 Bit effektiver Entropy gegenüber einem angestrebten Niveau von 128 Bit ausgegangen.

Für Nicht-Techniker ist dabei vor allem eines entscheidend: Eine Reduktion von 128 Bit auf 40 oder 72 Bit ist keine kleine Verschlechterung.

Sie verändert den Aufwand eines möglichen Angriffs um enorme Größenordnungen.

Die Sicherheit kryptografischer Keys beruht gerade darauf, dass das Durchsuchen des gesamten Key Space praktisch unmöglich ist.

Wird dieser Raum stark reduziert, verändert sich das Threat Model – also die Frage, welche Angriffe praktisch realistisch werden – grundlegend.

Kein physischer Zugriff auf das Hardware Wallet erforderlich

Das Besondere an diesem Szenario: Ein Angreifer muss das Hardware Wallet nicht zwingend stehlen. Er muss keinen Private Key aus einem Secure Element extrahieren. Er muss das Gerät unter Umständen niemals physisch berühren.

Ist der mögliche Key Space klein genug und besitzt der Angreifer Informationen, mit denen mögliche Seeds überprüft werden können, kann die Suche vollständig offline erfolgen.

Eine bekannte Bitcoin-Adresse oder ein Extended Public Key kann dabei zur Verifikation dienen.

Der Angreifer erzeugt mögliche Seeds, leitet daraus die zugehörigen Public Keys beziehungsweise Adressen ab und vergleicht sie mit der Ziel-Wallet.

Findet er einen passenden Kandidaten, kann er daraus das zugehörige Key Material rekonstruieren.

Die On-Chain-Folgen

TRM Labs dokumentierte ab dem 30. Juli 2026 mehrere Abflusswellen aus mutmaßlich betroffenen Wallets.

Zum Zeitpunkt der Veröffentlichung belief sich die vorläufige Schadensschätzung auf rund 1.816 BTC aus mehr als 5.200 Adressen, entsprechend einem damaligen Gegenwert von ungefähr 116 Millionen US-Dollar.

Diese Zahlen wurden ausdrücklich als vorläufig eingeordnet.

Auch die Frage, ob sämtliche beobachteten Abflüsse demselben Täter oder derselben Tätergruppe zuzuordnen sind, ist offen.

Unterschiede in der Struktur einzelner Transaktionen können auf unterschiedliche Vorgehensweisen oder verschiedene Akteure hindeuten.

Forensisch ist hier eine saubere Trennung notwendig:

„On-Chain-Muster können Hinweise auf gemeinsame Kontrolle liefern. Sie ersetzen jedoch keine belastbare Attribution.“

Attribution bedeutet in der Blockchain-Forensik die Zuordnung einer Adresse, Wallet oder eines Clusters zu einem bestimmten Dienst, Unternehmen oder Akteur.

Eine solche Zuordnung benötigt regelmäßig mehr als nur die sichtbaren Blockchain-Transaktionen.

Warum ein Firmware Update einen alten Seed nicht repariert

Ein Firmware Update kann die zukünftige Seed Generation korrigieren. Ein bereits erzeugter Seed verändert sich dadurch jedoch nicht. War seine Entstehung betroffen, wird er durch das Update nicht nachträglich sicherer.

Deshalb muss zwischen zwei völlig unterschiedlichen Vorgängen unterschieden werden.

Patch Der technische Fehler im System wird behoben.

Key Migration Das möglicherweise unsicher erzeugte Schlüsselmaterial wird durch neues Key Material ersetzt.

Für betroffene Nutzer bedeutet dies nach den aktuellen Herstellerhinweisen grundsätzlich: prüfen, ob die verwendete Firmware betroffen war, korrigierte Firmware verifizieren und installieren, einen vollständig neuen Seed erzeugen, Wallet Fingerprint und Empfangsadresse kontrollieren, zunächst eine kleine Testtransaktion durchführen, anschließend den verbleibenden Bestand migrieren. Ein potenziell betroffener Seed sollte nicht lediglich in ein neues Hardware Wallet importiert werden. Denn:

„Die Schwachstelle liegt nicht zwingend in dem Gerät, auf dem ein Seed heute gespeichert ist. Sie kann bereits bei der Entstehung dieses Seeds entstanden sein.“

Was Dice Rolls und Passphrases verändern können

COLDCARD ermöglicht unter anderem, zusätzliche Entropy durch Dice Rolls, also physische Würfelwürfe, in die Seed Generation einzubringen.

Der Gedanke dahinter ist einfach: Jeder unabhängige und geheim gehaltene Würfelwurf liefert zusätzliche Information, die ein Angreifer nicht kennt. Wenn ausreichend viele faire und unabhängige Würfelwürfe verwendet wurden, kann dadurch ein erheblicher zusätzlicher Entropy-Beitrag entstehen.

Eine BIP39 Passphrase funktioniert anders. Sie repariert keinen schwachen Seed. Sie führt zusammen mit der Mnemonic jedoch zu einer anderen Wallet-Ableitung und kann damit eine zusätzliche Schutzschicht darstellen – vorausgesetzt, sie ist stark, unabhängig und nicht kompromittiert.

Der allgemeine Grundsatz lautet: Mehrere Schutzmechanismen erhöhen die Sicherheit nur dann, wenn sie tatsächlich unabhängig voneinander sind.

Fall 3: Fake Wallets – wenn der Software Distribution Channel selbst zum Angriff wird

Ein völlig anderer Attack Vector betrifft gefälschte Wallet-Anwendungen. Im August 2026 wurde öffentlich über eine mutmaßlich gefälschte Wasabi Wallet im Apple App Store berichtet. Nach den derzeit verfügbaren Berichten soll mindestens ein Nutzer dadurch rund sechs Bitcoin verloren haben.

Dieser konkrete Schadensfall ist zum Zeitpunkt dieser Analyse nicht in derselben Qualität durch eine Primärquelle wie Wasabi oder Apple bestätigt wie die zuvor beschriebenen BTCPay- und COLDCARD-Vorfälle. Die zugrunde liegende Sicherheitsproblematik ist dennoch klar.

Wasabi beschreibt seine offizielle Software als Desktop Wallet und stellt Installationspakete für Windows, macOS und Linux bereit. Die offizielle Dokumentation empfiehlt außerdem, die Software über die offiziellen Quellen zu beziehen und die veröffentlichten Signaturen zu überprüfen.

Warum ein App Store keine Authentizitätsgarantie ist

Ein offizieller App Store schafft Vertrauen. Dieses Vertrauen ist nachvollziehbar. Es sollte bei Wallet-Software aber nicht die einzige Sicherheitsprüfung darstellen.

Ein App Store kann bestätigen, dass eine Anwendung über seine Plattform angeboten wurde. Er kann dem Nutzer jedoch nicht in jedem Fall garantieren, dass eine Anwendung tatsächlich vom Projekt stammt, dessen Namen oder Erscheinungsbild sie verwendet.

Bei Wallet-Software sollte deshalb der Vertrauensweg umgekehrt werden.

Nicht: App Store → Wallet suchen → installieren

sondern: offizielle Projektseite → dort ausgewiesene Software → Entwickler beziehungsweise Signatur prüfen → installieren Name, Logo und Screenshots sind keine kryptografischen Echtheitsnachweise.

Warum Fake Wallets keine hochentwickelte Malware benötigen

Eine gefälschte Wallet muss keinen Zero-Day ausnutzen. Sie muss keinen Private Key aus einem Hardware Wallet extrahieren. Im einfachsten Fall muss sie lediglich den Nutzer davon überzeugen, seine Recovery Phrase selbst einzugeben.

Genau deshalb sind solche Anwendungen so gefährlich. Die 12 oder 24 Wörter einer Recovery Phrase sind nicht lediglich ein Passwort für eine bestimmte App.

Bei deterministischen Wallet-Systemen bilden sie die Grundlage für die Ableitung der Private Keys.

Kennt ein Angreifer diese Wörter – und gegebenenfalls die zusätzlich verwendete Passphrase –, benötigt er das ursprüngliche Hardware Wallet oder Smartphone nicht mehr zwingend. Die Wallet kann auf einem anderen System rekonstruiert werden.

„Seed niemals eingeben“ ist zu pauschal

Die häufige Empfehlung, eine Seed Phrase niemals irgendwo einzugeben, ist gut gemeint, aber technisch zu pauschal.

Bei einer legitimen Wallet Recovery muss eine Recovery Phrase naturgemäß auf einem vertrauenswürdigen Zielsystem eingegeben werden.

Die korrekte Regel lautet deshalb:

„Eine Recovery Phrase darf ausschließlich im Rahmen eines bewusst eingeleiteten Recovery-Prozesses auf einem zuvor verifizierten und vertrauenswürdigen System eingegeben werden.“

Sie gehört niemals in:

• Webseiten
• Support-Chats
• E-Mails
• Messenger
• Cloud-Dokumente
• Online-Formulare
• Remote-Support-Sitzungen
• nicht zweifelsfrei verifizierte Wallet-Anwendungen

Kein seriöser Wallet-Hersteller, Supportdienst oder Blockchain-Forensiker benötigt die vollständige Recovery Phrase eines Geschädigten.

Auch für eine On-Chain-Analyse werden weder Private Keys noch Seed Phrases benötigt.

Warum „Not your keys, not your coins“ als Sicherheitsmodell nicht ausreicht

Der bekannte Grundsatz

„Not your keys, not your coins“

bleibt richtig.

Er beantwortet jedoch vor allem die Frage:

Wer besitzt die technische Kontrolle über die Keys?

Er beantwortet nicht:

• Wie wurden die Keys erzeugt?
• War die Entropy ausreichend?
• Welche Firmware war daran beteiligt?
• Ist das Hardware Wallet authentisch?
• Welche Software bereitet Transaktionen vor?
• Welche Credentials können indirekt Assets bewegen?
• Wo befinden sich Backups?
• Welche Komponenten besitzen gemeinsame Schwachstellen?
• Kann ein kompromittiertes Endgerät Transaktionsdaten manipulieren?
• Kann Social Engineering den Nutzer zur Preisgabe seines Seeds bewegen?

Für eine belastbare Self-Custody-Architektur reicht die bloße Kontrolle über den Private Key deshalb nicht aus.

Das Sicherheitsmodell einer Wallet

Eine sichere Wallet besteht nicht aus einem einzigen Schutzmechanismus.

Sie besteht aus mehreren Ebenen, die gemeinsam funktionieren müssen.

1. Entropy Layer

Woher stammt die Zufälligkeit für den Seed? Ist sie ausreichend und kryptografisch belastbar?

2. Key Generation

Wie wird das Schlüsselmaterial tatsächlich erzeugt? Welche Software und welche Hardware sind daran beteiligt?

3. Key Storage

Wo befinden sich Private Keys und Recovery Information? Existieren zusätzliche digitale Kopien?

4. Signing Process

Welche Informationen werden vor einer Signatur angezeigt? Kann ein kompromittierter Computer beispielsweise eine falsche Zieladresse darstellen?

5. Firmware

Ist die verwendete Firmware authentisch und aktuell?

6. Coordinator

Bei komplexeren Setups erstellt häufig ein Computer oder eine Wallet-Software die Transaktion, bevor sie vom Hardware Wallet signiert wird.

Dieses vorbereitende System wird als Coordinator bezeichnet. Auch dessen Sicherheit ist relevant.

7. Infrastructure

Welche Nodes, APIs, Credentials und administrativen Schnittstellen existieren?

8. Recovery

Wie sind Backups abgesichert? Ist bekannt, wie die Wallet im Ernstfall wiederhergestellt wird?

9. Human Layer

Welche Risiken bestehen durch Phishing, Fake Support und Social Engineering?

Erst die Gesamtheit dieser Ebenen beschreibt das tatsächliche Sicherheitsniveau.

Hardware Wallet Sicherheit: Hardware Wallet ist nicht gleich Cold Storage

Eine Hardware Wallet ist ein spezialisiertes Gerät zur sicheren Verwaltung und Nutzung kryptografischer Schlüssel. Cold Storage ist dagegen ein gesamtes Sicherheitskonzept.

Ein Nutzer kann deshalb ein technisch hochwertiges Hardware Wallet besitzen und trotzdem ein unsicheres Setup betreiben.

Ein einfaches Beispiel: Der Seed wird korrekt auf dem Hardware Wallet erzeugt. Anschließend fotografiert der Nutzer die Recovery Phrase mit seinem Smartphone.

Das Foto wird automatisch in die Cloud synchronisiert. Der Private Key hat das Hardware Wallet möglicherweise niemals verlassen.

Die Informationen, aus denen er vollständig rekonstruiert werden kann, befinden sich trotzdem auf einem internetfähigen System. Die Sicherheitswirkung des Hardware Wallets wurde damit an einer entscheidenden Stelle unterlaufen.

„Entscheidend ist nicht nur, wo der Private Key gespeichert ist. Entscheidend ist, wo genügend Informationen existieren, um ihn wiederherzustellen.“

Multisig: Mehrere Keys bedeuten nicht automatisch mehr Sicherheit

Eine 2-of-3-Multisignature-Struktur kann das Risiko eines einzelnen kompromittierten Keys erheblich reduzieren. Bei einer solchen Multisig-Struktur sind beispielsweise drei Schlüssel vorhanden, von denen mindestens zwei benötigt werden, um eine Transaktion freizugeben.

Das kann einen erheblichen Sicherheitsgewinn darstellen. Aber nur dann, wenn die Schlüssel tatsächlich unabhängig voneinander abgesichert sind.

Werden beispielsweise drei Hardware Wallets verwendet, aber:

• alle Geräte beruhen auf derselben technischen Architektur,
• alle Seeds wurden über denselben fehlerhaften Prozess erzeugt,
• alle Backups befinden sich am selben Ort,
• alle Geräte werden über denselben kompromittierten Computer koordiniert,

bestehen weiterhin gemeinsame Fehlerquellen. Im Security-Bereich spricht man hier von gemeinsamen Failure Modes – also Schwachstellen, durch die mehrere Schutzmechanismen gleichzeitig ausfallen können.

Deshalb ist nicht allein die Anzahl der Keys entscheidend. Entscheidend ist die Unabhängigkeit der einzelnen Sicherheitsbereiche.

Praktische Sicherheitsarchitektur für größere Krypto-Bestände

Größere Bestände sollten möglichst nach ihrem Verwendungszweck getrennt werden.

Long-Term Cold Storage

Für Vermögenswerte, die über längere Zeit nicht bewegt werden.

Operational Wallet

Für regelmäßig benötigte Beträge.

Hot Wallet

Für kleinere Beträge und häufige Nutzung.

Lightning Infrastructure

Nur für jene Liquidität, die tatsächlich für den laufenden Betrieb erforderlich ist.

Multisignature Vault

Für größere Bestände, bei denen ein einzelner kompromittierter Key nicht zur alleinigen Verfügung über das Vermögen ausreichen soll. Ziel ist Compartmentalization – also die bewusste Trennung verschiedener Sicherheitsbereiche.

Der Ausfall eines einzelnen Bereichs sollte möglichst nicht zum Verlust des gesamten Vermögens führen.

Was Nutzer regelmäßig überprüfen sollten

Krypto-Sicherheit ist kein einmaliger Einrichtungsvorgang. Insbesondere bei größeren Beständen sollten regelmäßig folgende Punkte geprüft werden:

• Gibt es aktuelle Security Advisories des Herstellers?
• Ist die installierte Firmware aktuell?
• Stammt die Wallet-Software tatsächlich aus der offiziellen Quelle?
• Kann die Signatur oder der Hash eines Installationspakets überprüft werden?
• Existieren digitale Kopien des Seeds?
• Auf welchen Geräten wurden Seeds oder Passphrases jemals eingegeben?
• Welche Browser Extensions sind installiert?
• Befinden sich unnötig hohe Beträge in Hot Wallets?
• Welche externen Zugänge zu Nodes bestehen?
• Welche API- oder RPC-Credentials sind aktiv?
• Wie sind physische Backups verteilt?
• Funktioniert der Recovery-Prozess tatsächlich?

Besonders wichtig ist dabei ein häufig übersehener Punkt: Ein Backup, das nie kontrolliert getestet wurde, ist zunächst nur eine Annahme.

Incident Response: Was nach einem vermuteten Wallet-Diebstahl wirklich zählt

Nach einem tatsächlichen oder vermuteten Krypto-Diebstahl zählt Geschwindigkeit. Ebenso wichtig ist jedoch die richtige Reihenfolge der Maßnahmen.

1. Zuerst klären, was möglicherweise kompromittiert wurde

Es macht einen erheblichen Unterschied, ob betroffen sind:

• eine Wallet-Anwendung
• ein Endgerät
• ein Seed
• eine BIP39 Passphrase
• ein Hardware Wallet
• ein API Key
• LND Credentials
• ein Exchange Account

Die notwendigen Gegenmaßnahmen unterscheiden sich entsprechend.

2. Gefährdete Assets sichern – aber nicht über das möglicherweise kompromittierte System

Besteht ein begründeter Verdacht, dass Seed oder Private Key offengelegt wurden, können sämtliche daraus ableitbaren Assets gefährdet sein. Ein neues Ziel muss deshalb mit neu und unabhängig erzeugtem Key Material eingerichtet werden.

Den alten Seed lediglich in ein neues Hardware Wallet zu importieren, beseitigt die Kompromittierung nicht.

3. Asset Containment und Evidence Preservation abwägen

Asset Containment bedeutet, noch vorhandene gefährdete Assets möglichst schnell zu sichern.

Evidence Preservation bedeutet, gleichzeitig digitale Beweismittel nicht unnötig zu zerstören.

Beides kann miteinander in Konflikt stehen. Ein verdächtiger Computer sollte beispielsweise nicht automatisch sofort neu installiert werden.

Dadurch können verloren gehen:

• Malware-Artefakte
• Browserdaten
• Download-Historien
• Logfiles
• Wallet-Artefakte
• Zeitstempel
• Persistence Mechanisms, also Hinweise darauf, wie sich Schadsoftware dauerhaft im System festgesetzt hat

Bei größeren Schadensfällen muss deshalb möglichst früh entschieden werden, wie Assets gesichert werden können, ohne gleichzeitig relevante digitale Spuren zu vernichten.

4. Point of Compromise und First Unauthorized Outflow bestimmen

Zwei Zeitpunkte sind forensisch besonders relevant. Der Point of Compromise beschreibt den möglichen Zeitpunkt oder Vorgang, bei dem ein System, Account oder Seed kompromittiert wurde. Der First Unauthorized Outflow bezeichnet die erste sicher feststellbare Transaktion, die nicht vom rechtmäßigen Nutzer veranlasst wurde.

Diese beiden Ereignisse müssen nicht identisch sein. Ein Seed kann beispielsweise Monate vor dem tatsächlichen Diebstahl kompromittiert worden sein.

5. Den Asset Flow rekonstruieren und gestohlene Bitcoin verfolgen

Ausgehend von der ersten unautorisierten Transaktion wird untersucht:

• welche Adressen anschließend verwendet wurden,
• ob Guthaben gesplittet oder konsolidiert wurde,
• welche Services berührt wurden,
• ob Swaps stattfanden,
• ob Bridges verwendet wurden,
• ob Assets auf andere Blockchains wechselten,
• ob zentralisierte Exchanges oder andere VASPs erreicht wurden.

Dabei ist zwischen zwei Dingen zu unterscheiden:

Observation: Was ist unmittelbar auf der Blockchain sichtbar?

Attribution: Wem kann eine Adresse oder ein Wallet-Cluster zugeordnet werden?

Eine Transaktion zu einer bestimmten Adresse ist direkt auf der Blockchain feststellbar.

Die Aussage, dass diese Adresse beispielsweise zu einer bestimmten Exchange gehört, kann dagegen zusätzliche Datenquellen, Cluster-Heuristiken oder weitere Intelligence erfordern.

Die Belastbarkeit dieser Zuordnung muss entsprechend transparent dargestellt werden.

6. Exchange Touchpoints priorisieren

Ein Exchange Touchpoint entsteht, wenn gestohlene Assets eine identifizierbare zentralisierte Exchange oder einen vergleichbaren Service erreichen.

Das kann operativ besonders relevant sein.

Ein Täter kann Guthaben dort jedoch rasch:

• weitertransferieren,
• swappen,
• auf andere Netzwerke verschieben,
• oder über weitere Accounts verteilen.

Deshalb sollte eine belastbare Transaktionskette möglichst früh erstellt werden.

7. Cross-Chain bedeutet nicht „Spur verloren“

Ein Wechsel auf eine andere Blockchain beendet eine forensische Analyse nicht automatisch.

Bridge- und Swap-Vorgänge können – abhängig vom jeweiligen Protokoll – anhand unterschiedlicher Merkmale rekonstruiert werden.

Dazu zählen beispielsweise:

• Einzahlungs- und Auszahlungsbeträge,
• zeitliche Zusammenhänge,
• Protocol Events,
• Deposit Addresses,
• Transaction Parameters,
• Bridge-spezifische Mechanismen.

Entscheidend ist dabei die Qualität der Beweislage. Eine deterministische Zuordnung, bei der Ein- und Ausgang technisch eindeutig miteinander verbunden sind, besitzt eine andere Beweiskraft als eine probabilistische Korrelation, bei der eine Verbindung lediglich aufgrund von Zeit, Betrag und weiteren Indikatoren wahrscheinlich erscheint.

Vorsicht vor Recovery Scams

Nach einem Krypto-Diebstahl folgt nicht selten ein zweiter Betrugsversuch.

Betroffene werden von angeblichen Ermittlern, Hackern, Behördenvertretern oder Recovery-Unternehmen kontaktiert.

Typische Behauptungen lauten:

„Ihre Bitcoin wurden bereits gefunden.“

„Wir können die Wallet hacken.“

„Die Exchange hat das Guthaben eingefroren.“

„Vor der Auszahlung muss eine Steuer bezahlt werden.“

„Für die Freigabe benötigen wir Ihre Seed Phrase.“

Warnsignale sind insbesondere:

• garantierte Rückholung
• hohe Vorauszahlungen
• vermeintliche Freischaltgebühren
• Aufforderung zur Herausgabe der Seed Phrase
• Installation von Remote-Access-Software
• angebliche Blockchain-Steuern
• nicht überprüfbare Exchange- oder Behördenkontakte

Blockchain-Forensik kann Asset Flows rekonstruieren und operative Ansatzpunkte identifizieren.

Sie kann jedoch niemals seriös garantieren, dass gestohlene Assets zurückgeführt werden.

Bitcoin- und Blockchain-Forensik: Was Blockchain-Forensik tatsächlich leisten kann

Professionelle Blockchain-Forensik besteht nicht darin, lediglich Pfeile zwischen Wallet-Adressen auf einem Graphen darzustellen. Eine belastbare Analyse muss mehrere Ebenen voneinander trennen.

Observation

Was ist unmittelbar auf der Blockchain feststellbar?

Reconstruction

Wie hängen einzelne Transaktionen technisch zusammen?

Attribution

Welche Adresse oder welches Cluster kann einem Service oder Akteur zugeordnet werden?

Assessment

Wie belastbar ist diese Zuordnung?

Operational Relevance

Ergibt sich daraus ein konkreter Ansatzpunkt – beispielsweise bei einer Exchange, einem Payment Service oder einem anderen identifizierbaren Dienstleister?

Gerade diese Trennung ist für eine nachvollziehbare forensische Analyse entscheidend.

„Blockchain-Daten zeigen Transaktionen. Forensik macht daraus eine nachvollziehbare und überprüfbare Rekonstruktion.“

Warum Monitoring nach dem ersten Abfluss relevant bleibt

Gestohlene Assets werden nicht zwingend unmittelbar weiterbewegt. Angreifer können Guthaben über Tage, Wochen oder Monate ruhen lassen. Gerade ein späterer Transfer kann jedoch einen entscheidenden Service Touchpoint erzeugen.

Deshalb kann bei erheblichen Schadenssummen ein fortlaufendes Monitoring sinnvoll sein.

Die relevante Frage lautet nicht nur:

„Wo befinden sich die Assets jetzt?“

Sondern:

„Welche neue forensisch oder operativ relevante Situation entsteht bei der nächsten Bewegung?“

„Bitcoin Security schützt das Protokoll. Asset Security erfordert zusätzlich sichere Keys, sichere Software, sichere Infrastruktur und sichere Prozesse.“

Schlussbemerkung

Self-Custody verlagert Kontrolle zum Nutzer. Damit verlagert sie zugleich Verantwortung. Ein Hardware Wallet ist kein vollständiges Sicherheitskonzept. Eine Seed Phrase auf Papier ist kein vollständiges Sicherheitskonzept.

Ein Air Gap ist kein vollständiges Sicherheitskonzept. Multisig ist kein vollständiges Sicherheitskonzept. Und ein offizieller App Store ist keine kryptografische Vertrauensinstanz.

Jede dieser Maßnahmen adressiert bestimmte Risiken. Keine von ihnen adressiert sämtliche Risiken. Professionelle Krypto-Sicherheit beginnt deshalb nicht mit der Frage:

„Welches Hardware Wallet ist das sicherste?“

Sie beginnt mit einer grundsätzlicheren Frage:

„Welche Voraussetzungen müssen gleichzeitig erfüllt sein, damit ein Angreifer keine Verfügung über meine Assets erlangen kann – und wo befinden sich innerhalb dieser Architektur gemeinsame Schwachstellen?“

Genau darin liegt der Unterschied zwischen einem einzelnen Sicherheitsprodukt und einer belastbaren Sicherheitsarchitektur.

„Self-Custody bedeutet nicht nur, den eigenen Key zu besitzen. Self-Custody bedeutet, die gesamte Vertrauenskette zu verstehen und abzusichern, von der die Sicherheit dieses Keys und damit der eigenen Assets abhängt.“

Über den Autor

Albert Quehenberger ist Gründer und Geschäftsführer der AQ Forensics GmbH sowie Spezialist für Blockchain-Forensik, Kryptowährungsermittlungen und digitale Vermögensanalysen. Mit über einem Jahrzehnt Erfahrung in den Bereichen Intelligence, digitale Ermittlungen und Blockchain-Analyse unterstützt er Unternehmen, Banken, Rechtsanwälte, Behörden und Privatpersonen bei der Aufklärung von Krypto-Betrugsfällen, Asset Tracing und der Analyse komplexer Finanzströme auf öffentlichen Blockchains.

Seine berufliche Laufbahn umfasst mehr als sechs Jahre Tätigkeit im militärischen Nachrichtendienst, einen Masterabschluss der WU Executive Academy, Fachausbildungen für Gerichtssachverständige sowie die Ausbildung zum Wahlbeobachter nach den Standards der OSZE/ODIHR. Darüber hinaus ist er Mitglied des Expertenrats des European Institute for Future Generations (EIFG), ChangeNOW Ambassador und Berater für Web3-Bildungsprogramme in Äthiopien.

Albert Quehenberger

Founder & CEO AQ Forensics

Weiterführende Analysen & Praxisfälle

• // AQ CASES 002 - Asset Recovery in der Praxis
• // AQ INSIGHTS 001 - Cross-Chain Swaps rekonstruieren
• // AQ INSIGHTS 002 - Krypto-Mixer in der Blockchain-Forensik

Quellen & weiterführende Informationen

• Video mit 21 Bitcoin & AQ Forensics: Wir jagen die Coldcard-Hacker: Hier landen die gestohlenen Bitcoin! I 21weekly
• Linkedin-Post von 21 Bitcoin Was passiert mit gestohlenen Bitcoin und wie lassen sich ihre Spuren auf der Blockchain verfolgen?
• BTCPay Server – Security Advisory:Update BTCPay Server to 2.4.2 Immediately. Offizielle Security Advisory zur kritischen LND-Credential-Schwachstelle, zum bestätigten aktiven Exploit und zu den empfohlenen Gegenmaßnahmen.
• Coinkite – Technical Deep Dive into the Entropy Issue: Technische Root-Cause-Analyse des COLDCARD-Sicherheitsvorfalls, einschließlich RNG-Pfad, betroffener Firmware-Versionen und Auswirkungen auf die effektive Entropy.
• Block – Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware: Unabhängige technische Analyse des MicroPython-Yasmarang-Fallbacks, der RNG-Integration und der daraus resultierenden Reduktion des effektiven Key Space.
• TRM Labs – The Largest Hardware Wallet Exploit of 2026: Inside the USD 116 Million Coldcard Hack: On-Chain-Analyse der beobachteten Abflusswellen und der vorläufigen Schadensdimension im Zusammenhang mit dem COLDCARD-Sicherheitsvorfall.
• Wasabi Wallet – Official Installation Documentation: Offizielle Dokumentation zu unterstützten Plattformen, Downloadquellen und zur Verifikation authentischer Wasabi-Software.
• Wasabi Wallet – Getting Started
• Apple App Store – Wasabi Bitcoin & Crypto Wallet: Primärquelle für Existenz und Darstellung der unter diesem Namen angebotenen mobilen Anwendung.
• Pluang – Fake Wasabi Wallet app linked to reported theft of approximately 6 BTC: Ergänzende Berichterstattung zum konkreten Schadensfall. Der Verlust von rund sechs BTC ist zum Zeitpunkt dieser Analyse nicht in derselben Qualität durch eine offizielle Primärquelle bestätigt wie die technischen Sachverhalte der BTCPay- und COLDCARD-Vorfälle.

INFO: Stand der Analyse: 10. August 2026 Bei laufenden Sicherheitsvorfällen können sich technische Erkenntnisse, betroffene Firmware-Versionen, Schadenssummen und die Zuordnung einzelner On-Chain-Aktivitäten im Zuge weiterer Untersuchungen verändern.