Von Vorfällen zur Regulierung: Warum Krypto-Institutionen Blockchain-Penetrationstests benötigen

Für Krypto-Institutionen und Dienstleister – einschließlich Kryptowährungsbörsen, Zahlungsunternehmen, Verwahrer digitaler Vermögenswerte sowie Anbieter von verwahrten und nicht verwahrten Wallets – ist Blockchain-Penetrationstests für alle im Geltungsbereich keine optionale Vorsichtsmaßnahme. Wo eine Kompromittierung Signaturen oder Gelder erreichen kann oder geltende Vorschriften eine adversariale Validierung verlangen, ist dies eine notwendige Sicherheitsebene. Die Begründung stützt sich auf zwei Säulen: die Herkunft von Risiken jenseits des Vertragscodes sowie regulatorische Anforderungen oder Erwartungen an adversariale Validierung.

Institutionelle Risiken gehen über Vertragsfehler hinaus und betreffen Signaturen, Verwahrung, Schlüssel, Personen, Lieferketten und Infrastruktur [1]. Daher wird diese Angriffsfläche nicht vollständig durch die bekannten Web3-Sicherheitslösungen – Audits auf Code-Ebene und Überwachung auf Transaktionsebene – oder durch traditionelle Penetrationstests allein abgedeckt. Dies gilt für jede Institution, bei der eine Person, ein Anbieter, eine Schnittstelle oder eine Anwendung Einfluss darauf haben kann, was signiert, genehmigt, gutgeschrieben oder bewegt wird – auch wenn die Verwahrung ausgelagert ist. Parallel dazu erlassen Regulierungsbehörden in mehreren Märkten Anforderungen, bedingte Verpflichtungen oder aufsichtsrechtliche Erwartungen mit unterschiedlichem Umfang, Häufigkeit und Unabhängigkeitsregeln.

Dieser Artikel eröffnet unsere Serie zu Blockchain-Penetrationstests. In der gesamten Serie bezeichnen die Begriffe Blockchain-Penetrationstests und Web3-Penetrationstests dieselbe Disziplin: Wir verwenden Ersteres als Hauptbegriff und Letzteres als gebräuchliches Synonym in der Branche. Er stellt die übergeordnete Gesamtargumentation für die Notwendigkeit dar; spätere Artikel definieren die Disziplin, ihre Einsatzgrenzen und die institutionelle Angriffsfläche im Detail.

Teil 1: Woher das Risiko kommt

1.1 Risiko jenseits des Smart Contracts

Schwachstellen in Smart Contracts bleiben wichtig, aber viele der größten jüngsten Verluste hatten ihren Ursprung anderswo, insbesondere bei Schlüsseln, Signatursystemen und der operativen Infrastruktur. Im Jahr 2024 stahlen Angreifer rund 305 Millionen US-Dollar von DMM Bitcoin, indem sie einen Wallet-Software-Anbieter kompromittierten und eine legitime Transaktionsanfrage manipulierten [2]. Im Jahr 2025 verlor Bybit etwa 1,5 Milliarden US-Dollar, nachdem eine Kompromittierung der Lieferkette die Signaturschnittstelle manipulierte [3], während der Verlust der Hot-Wallet von BtcTurk ebenfalls auf kompromittierte private Schlüssel zurückzuführen war [4]. Unsere Recherchen deuten in dieselbe Richtung: Unter den von uns 2026 erfassten Vorfällen mit Verlusten über 100.000 US-Dollar machten außervertragliche Fehler etwa jeden achten Vorfall aus, jedoch mehr als drei Viertel der Gesamtverluste. Stand August 2026 waren sieben der zehn größten Hacks auf der öffentlichen Rangliste von rekt.news, ohne Betrugsfälle und andere Nicht-Hack-Einträge, außervertragliche Kompromittierungen, die sowohl nach Anzahl der Vorfälle als auch nach Dollarwert rund 70 % ausmachten [5].

Wallets und Verwahrungssysteme verdeutlichen dieses Muster, und die Wallet-Sicherheit ist in den letzten Jahren ein besonders aktiver Bereich für Vorfälle geblieben. Unsere Untersuchung gruppiert Fehler in Schlüsselverwaltung, die Transaktions-Signierungspipeline, Lieferkette und Abhängigkeiten, Offenlegung sensibler Daten sowie kryptografische Implementierung.

_* Die ~90 Mio. $ von Coldcard sind der verifizierte On-Chain-Mindestwert (etwa 1.405 BTC); private Schätzungen gehen bis zu ~130 Mio. $.

Was diese Fälle mit Penetrationstests verbindet, ist nicht einfach, dass sie außerhalb des Vertrags liegen, sondern dass die Frage, ob sie ausgenutzt werden können, oft davon abhängt, wie die eingesetzten Komponenten – Identitäten, Abhängigkeiten, Signaturkontrollen, Genehmigungen und Fondslogik – sich zu einem Pfad zusammensetzen, den ein Angreifer durchgängig durchlaufen kann – von einem Einstiegspunkt bis zu den Geldern.

1.2 Audit auf Code-Ebene und Überwachung auf Transaktionsebene: unverzichtbar, aber begrenzt

Jede der bestehenden bekannten Web3-Sicherheitslösungen arbeitet auf einer bestimmten Ebene. Audit auf Code-Ebene (Code-Audit) untersucht Code – Vertrags-, Wallet- oder Dienstlogik. Überwachung auf Transaktionsebene (Monitoring) untersucht Transaktionen, sobald sie die Chain erreichen; Phalcon Security [11] beispielsweise erkennt, alarmiert und blockiert schädliche Aktivitäten zur Laufzeit.

Diese Lösungen sind nützlich, aber begrenzt, wenn es um die Geldverarbeitungskette von Krypto-Institutionen geht – die verbundenen Identitäten, die Cloud-Infrastruktur, Signaturworkflows, Genehmigungsketten, Wallets, Anbieter und Bediener-Konsolen, durch die Werte von einem Einstiegspunkt zu einer geldbewegenden Aktion fließen. Ein erreichbarer Angreiferpfad ist eine Route über diese Kette: Er kann von einem Web-, dApp-, Mobile-, API-, Cloud- oder Identitäts-Einstiegspunkt durch Signatur-, Genehmigungs- und Fondslogik verlaufen und kann durchlaufen, wie sich ein Vertrag in diesem live Kontext verhält, bis hin zur geldbewegenden Aktion am anderen Ende. Die Überprüfung des Codes setzt diesen Pfad nicht zusammen, und die Beobachtung von Transaktionen antizipiert ihn nicht. Selbst zusammen eingesetzt, können die beiden Ansätze eine Kompositionslücke hinterlassen: Ein Audit zeigt, dass der Code wie geschrieben solide war, nicht dass die eingesetzten Identitäten, Genehmigungen und Signaturgeber ihn weiterhin durchsetzen; und Monitoring kann eine Übertragung durchlassen, die technisch gültig ist, aber niemals das war, was der Betreiber beabsichtigt hat. Was diese Lücke schließt, ist eine unabhängige adversariale Validierung, dass die Kontrollen im laufenden System korrekt zusammenwirken.

Blockchain-Penetrationstests testen das zusammengesetzte, laufende System, um zu ermitteln und nachzuweisen, ob ein solcher Pfad die Gelder erreichen kann, bevor ein Vorfall dies offenlegt. Das Bybit-Muster zeigt die Form des Problems: eine kompromittierte Signaturschnittstelle verwandelte die eigene Genehmigung der Betreiber in eine Übertragung, die sie nie beabsichtigt hatten – ein Ergebnis, das der Vertrag, ein Audit davon und die Transaktionsüberwachung jeweils als legitim hätten einstufen können. Blockchain-Penetrationstests zielen direkt auf diese Zusammensetzung ab: Aus der Position eines kompromittierten Anbieters, Betreibers oder einer Schnittstelle wird getestet, ob ein solcher Zugriffspunkt eine scheinbar gültige Genehmigung in eine unbefugte Geldbewegung verwandeln kann, und welche eingesetzten Kontrollen – Identitäten, Genehmigungsschritte, Signaturprüfungen – dies tatsächlich verhindern. Die Sicherstellung auf Code-Ebene des Vertrags bleibt Aufgabe des Audits; Blockchain-Penetrationstests befassen sich mit einem eingesetzten Vertrag nur über sein Live-Verhalten, sofern dies Teil einer Route auf Institutionsebene zu den Geldern ist – ergänzende Geltungsbereiche, die sich durch Schwerpunktsetzung unterscheiden, nicht durch eine feste Grenze. Teil 2 definiert, was Blockchain-Penetrationstests validieren und wo ihr Geltungsbereich endet.

1.3 Traditionelle Penetrationstests: nützlich, aber nicht ausreichend

Traditionelle Penetrationstests bleiben wertvoll für Cloud-, Web- und API-, Identitäts- und privilegierte Zugriffsbereiche. Ihre Begrenzung liegt im Geltungsbereich und im Domänenkontext: Ein konventioneller Einsatz bringt möglicherweise nicht die Geschäftssemantik von Krypto oder das gekoppelte Sicherheits- und Compliance-Modell mit.

Im Kryptobereich kann eine Signatur eine unwiderrufliche Wertbewegung autorisieren; die Genehmigung einer Auszahlung ist eine Entscheidung zur Fondskontrolle, nicht nur eine Formularabgabe. Einzahlungsgutschriften, Saldenverbuchung und interne Übertragungen sind Geldlogik. Adressen und Transaktionen können auch eine Sanktions- oder Herkunftsbedeutung tragen. Ein Tester könnte eine Authentifizierungsumgehung finden, jedoch übersehen, wie sich diese mit einer fehlerhaften Signaturanzeige, einer schwachen Genehmigungsrichtlinie oder einem Rundungsfehler zu einem Pfad zu den Geldern verbindet.

Blockchain-Penetrationstests wenden etablierte adversariale Techniken auf traditionelle Angriffsflächen sowie auf web3-spezifische Signatur-, Genehmigungs-, Fondslogik- und vertragsdynamische Flächen im gesamten laufenden System an. Ihr Unterscheidungsmerkmal ist spezialisiertes Web3-Sicherheitsurteil, nicht neue Werkzeuge: Tester interpretieren Verwahrung, Transaktionsabsicht, Geldflüsse und Compliance-Kontrollen wie ein Angreifer. Der Unterschied liegt im Ziel: Ein konventioneller Test weist typischerweise IT-Kontrollauswirkungen nach – eine übernommene Admin-Sitzung, ein erreichter Server – während ein Blockchain-Test die Bewegung von Werten als Endzustand behandelt. Er geht weiter: Er ändert den Empfänger oder Betrag innerhalb einer legitimen Signaturanfrage und prüft, ob das, was der Genehmiger sieht, die Genehmigungsrichtlinie und die tatsächlich bewegten Gelder noch übereinstimmen.

Zusammenfassend handelt es sich um komplementäre Sicherheit, nicht um eine statische Gegenüberstellung mit dynamischen Ansätzen. Audits auf Code-Ebene, Überwachung auf Transaktionsebene und traditionelle Penetrationstests bleiben notwendig. Blockchain-Penetrationstests verbinden sie, indem sie erreichbare Pfade validieren; sie ersetzen sie nicht, garantieren keine Entdeckung von Sicherheitsverletzungen und garantieren keine Prävention.

Teil 2: Was Regulierungsbehörden fordern

Die Anforderungen variieren je nach Jurisdiktion und ergeben ein Spektrum an Lizenzierungs-, laufenden und regulatorisch ausgelösten Verpflichtungen für bestimmte Einrichtungen und Systeme.

Diese Beispiele dienen der Veranschaulichung und stellen keine Rechtsberatung dar. Institutionen sollten ihren Status, ihre Ausnahmen, Systeme und Verpflichtungen mit Rechtsberatern klären.

• Vereinigte Staaten, New York: ausdrückliche Anforderung mit begrenzter Ausnahme. Erfasste Einrichtungen gemäß NYDFS 23 NYCRR Part 500 [12], einschließlich von der DFS lizenzierter virtueller Währungsunternehmen, müssen Informationssysteme mindestens jährlich von innen und außen ihrer Grenzen testen, basierend auf einer Risikobewertung. Ein qualifizierter interner oder externer Beteiligter kann den Test durchführen. Qualifizierte kleine Einrichtungen erhalten eine begrenzte Ausnahme von dieser Testanforderung, unterliegen jedoch weiterhin den übrigen geltenden Bestimmungen von Part 500.

• Dubai: jährliche und änderungsauslösende Anforderung. Lizenzierte VASPs müssen mindestens jährlich sowie vor der Einführung neuer Systeme, Anwendungen oder Produkte eine Schwachstellenbewertung und Penetrationstests durchführen [13], unter Einsatz eines qualifizierten, unabhängigen Dritten. Ein Smart-Contract-Audit gilt, sofern relevant für das Geschäft und die Aktivitäten des VASP. Bedrohungsgeführte Penetrationstests (Threat-Led Penetration Testing) haben keinen universellen Rhythmus: Die VARA kann sie verlangen, wenn dies auf Grundlage des Risikos notwendig und angemessen ist.

• Hongkong: Lizenzbedingungsanforderung für gilt-als-lizenziert-Antragsteller. Antragsteller, die als lizenziert geltende Handelsplattformen für virtuelle Vermögenswerte betreiben, müssen vor dem eingeschränkten Betrieb Penetrationstests und Schwachstellenbewertungen mit zufriedenstellenden Ergebnissen abschließen [14]. Für Anträge neuer Gesellschaften gelten separate Leitlinien. Ein unabhängiger Dritter muss festgelegte Infrastruktur und Anwendungen über die Anwendungs- und Netzwerkebenen hinweg abdecken. Vor dem eingeschränkten Betrieb muss das Management alle größeren und kritischen Behebungsschritte für Befunde mit mittlerem bis hohem Risiko abschließen.

• Europäische Union: proportionaler Rahmen; TLPT abhängig von Identifizierung. DORA erfasst Finanzunternehmen, einschließlich Krypto-Dienstleister [15]. Sie verlangt angemessene Tests – nicht speziell Penetrationstests – mindestens jährlich für Systeme, die kritische oder wichtige Funktionen unterstützen. Penetrationstests sind eine Methode, die je nach Risiko und Verhältnismäßigkeit ausgewählt wird. Bedrohungsgeführte Penetrationstests gelten nur für von den zuständigen Behörden identifizierte Einrichtungen, werden auf Live-Produktionssystemen durchgeführt und sind im Allgemeinen mindestens alle drei Jahre erforderlich; die Behörden können diese Häufigkeit aus Risikogründen anpassen. DORA legt außerdem Bedingungen zur Unabhängigkeit der Tester fest. Kleinstunternehmen sind von der Anforderung eines Testprogramms ausgenommen.

• Singapur: unverbindliche aufsichtsrechtliche Erwartung. Die MAS Technology Risk Management Guidelines besagen, dass Finanzinstitute Penetrationstests durchführen sollten, und erwarten, dass über das Internet zugängliche Systeme mindestens jährlich oder nach größeren Änderungen oder Aktualisierungen getestet werden [16]. Dies ist eine unverbindliche aufsichtsrechtliche Leitlinie und verlangt keinen unabhängigen Dritten. Der verbindliche, bankspezifische Cyber Hygiene Notice spezifiziert keine Penetrationstests. Der verbindliche Zahlungs- oder Digital-Payment-Token-Notice liegt außerhalb des Geltungsbereichs dieses Artikels.

Zusammengenommen fordern oder erwarten diese Regelwerke Penetrationstests – keine markenspezifische „Web3“-Kategorie. Die web3-spezialisierte Version ergibt sich aus den erfassten Systemen: Wo diese Kryptowerte autorisieren, signieren, verwahren oder verbuchen, erfordert ein ordnungsgemäßer Test dieselbe Signatur- und Geldfluss-Kompetenz, die in Teil 1 beschrieben wird.

Die Schlussfolgerung ist präzise: Ein beträchtlicher Teil lizenzierter Einrichtungen in bestimmten Jurisdiktionen sieht sich bereits einer Anforderung oder aufsichtsrechtlichen Erwartung gegenüber – nicht demselben Mandat in jedem Markt. Die Unterschiede bestimmen Geltungsbereich, Häufigkeit, Unabhängigkeit der Tester, Behebung, Nachweise und ob der Test der Lizenzierung, der laufenden Compliance oder einer regulatorisch ausgelösten Maßnahme dient.

Fazit: Die zwei Säulen laufen zusammen

Die Herkunft von Risiken sowie regulatorische Anforderungen oder Erwartungen führen zur gleichen Schlussfolgerung: Für Institutionen im Geltungsbereich sind Blockchain-Penetrationstests eine notwendige Sicherheitsebene. Sie validieren erreichbare Pfade über Zugriff, Genehmigung, Signatur und Gelder hinweg und ergänzen bestehende Kontrollen. Sie können keine Prävention garantieren, nicht nachweisen, dass sie einen bestimmten vergangenen Vorfall verhindert hätten, oder jeden ausnutzbaren Pfad finden. Das Ziel ist kontinuierliche Sicherheit über Launch, Betrieb, Erkennung, Reaktion und regulatorischen Nachweis hinweg – nicht ein einmaliger Bericht.

Setzen Sie die Serie fort:

• Teil 2: Was sind Blockchain-Penetrationstests? Definitionen und Grenzen

• Teil 3: Einsatzregeln und Produktionssicherheit für institutionelle Blockchain-Penetrationstests

• Teil 4: Web3-Angriffsflächen: Ein Überblick über Penetrationstests

Ebenfalls in dieser Serie, erscheint in Kürze:

• Teil 5: Autorisierungs- und Signatursicherheit: Web, dApps und Mobile
• Teil 6: Cloud- und CI/CD-Sicherheit: Angriffsflächen automatisierter Abläufe
• Teil 7: Sicherheit der Treasury-Kontrollebene: Signatur- und Auszahlungsgenehmigungen
• Teil 8: Sicherheit von Exchange-Ledgern: Diebstahlspfade und Datenebenen-Logik

BlockSec hilft Institutionen dabei, diese Ebene präzise zu positionieren: Vermögenswerte, Geldflüsse, Vertrauensgrenzen und bestehende Sicherheitsmaßnahmen werden erfasst; die von Rechtsberatern bestätigten geltenden Verpflichtungen werden überprüft; anschließend werden Testziel, Geltungsbereich, Zugriff, Produktionsschutzmaßnahmen, Behebungsnachweise und Retest-Plan definiert. Um Ihre Sicherheitslücke zu identifizieren, sprechen Sie mit unserem Team für Blockchain-Penetrationstests; Umfang und Preise des Einsatzes sind auf Anfrage erhältlich. Beginnen Sie dort, wo die Gelder fließen.

Referenzen

Nummeriert in der Reihenfolge des ersten Auftretens.

1. BlockSec, Crypto Payment Security Playbook.
2. U.S. Federal Bureau of Investigation, DC3, und Japan National Police Agency, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (Dezember 2024).
3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack.
4. rekt.news, BtcTurk — Rekt.
5. rekt.news, Leaderboard.
6. SwissBorg, SwissBorg Security Update: Kiln Breach.
7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor.
8. Slope, Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report.
9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability.
10. BlockSec, Coldcard Entropy Failure and Seed Recovery.
11. BlockSec, Phalcon Security.
12. New York State Department of Financial Services, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
13. Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Teil I, Abschnitt E.
14. Hong Kong Securities and Futures Commission, Circular 24EC65 (18. Dezember 2024, PDF).
15. Europäische Union, Verordnung (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Artikel 24–27.
16. Monetary Authority of Singapore, Technology Risk Management Guidelines (Januar 2021), Abschnitte 2 und 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).