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 Custodial- und Non-Custodial-Wallets – ist Blockchain-Penetrationstests für die im Geltungsbereich befindlichen Akteure keine optionale Vorsichtsmaßnahme. Wo eine Kompromittierung Signierung oder Gelder erreichen kann, oder geltende Vorschriften eine gegnerische Validierung verlangen, ist sie eine notwendige Sicherheitsebene. Die Begründung stützt sich auf zwei Säulen: die Herkunft von Risiken jenseits des Vertragscodes und regulatorische Anforderungen oder Erwartungen an eine gegnerische Validierung.

Die institutionelle Gefährdung geht über Vertragsfehler hinaus und betrifft Signierung, Verwahrung, Schlüssel, Personen, Lieferketten und Infrastruktur [1]. Diese Angriffsfläche wird daher nicht vollständig durch die bekannten Web3-Sicherheitslösungen – Code-Audits und Transaktionsüberwachung – 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 nehmen 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, unterschiedlicher Taktung und unterschiedlichen Unabhängigkeitsregeln.

Dieser Artikel eröffnet unsere Serie zu Blockchain-Penetrationstests. In der gesamten Serie beziehen sich Blockchain-Penetrationstests und Blockchain-Penetrationstests auf dieselbe Disziplin: Wir verwenden Ersteren als Hauptbegriff und Letzteren als gängiges Synonym in der Branche. Der Artikel stellt die übergeordnete Begründung der Notwendigkeit im Gesamtbild dar; spätere Artikel definieren die Disziplin, ihre operativen Grenzen 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, doch viele der größten jüngsten Verluste hatten ihren Ursprung anderswo, insbesondere bei Schlüsseln, Signiersystemen und operativer Infrastruktur. Im Jahr 2024 stahlen Angreifer rund 305 Millionen US-Dollar von DMM Bitcoin, indem sie einen Anbieter von Wallet-Software kompromittierten und eine legitime Transaktionsanfrage manipulierten [2]. Im Jahr 2025 verlor Bybit etwa 1,5 Milliarden US-Dollar, nachdem eine Kompromittierung der Lieferkette dessen Signierschnittstelle manipulierte [3], während der Verlust der Hot-Wallet von BtcTurk ebenfalls auf kompromittierte private Schlüssel zurückzuführen war [4]. Unsere Recherche weist in dieselbe Richtung: Von den von uns 2026 verfolgten Vorfällen mit Verlusten über 100.000 US-Dollar entfielen off-contract-Fehler auf etwa jeden achten Vorfall, jedoch auf mehr als drei Viertel der Gesamtverluste. Stand August 2026 waren sieben der zehn größten Hacks auf der öffentlichen Rangliste von rekt.news, ohne Betrug und andere Nicht-Hack-Einträge, off-contract-Kompromittierungen, was sowohl bei der Anzahl der Vorfälle als auch beim Dollarwert rund 70 % ausmachte [5].

Wallets und Verwahrungssysteme veranschaulichen dieses Muster konkret, und die Sicherheit von Wallets blieb in den letzten Jahren ein besonders aktives Feld für Vorfälle. Unsere Untersuchung gruppiert Fehler in Schlüsselverwaltung, die Transaktionssignier-Pipeline, Lieferkette und Abhängigkeiten, Offenlegung sensibler Daten sowie kryptografische Implementierung.

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

Was diese Vorfälle mit Penetrationstests verbindet, ist nicht einfach, dass sie außerhalb des Vertrags liegen, sondern dass ob sie ausgenutzt werden können, oft davon abhängt, wie die eingesetzten Bestandteile – Identitäten, Abhängigkeiten, Signierkontrollen, Genehmigungen und Geldlogik – sich zu einem Pfad zusammenfügen, den ein Angreifer von Anfang bis Ende durchlaufen kann – von einem Einstiegspunkt bis zu den Geldern.

1.2 Code-Audit und Transaktionsüberwachung: essenziell, aber begrenzt

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

Diese Lösungen sind nützlich, aber begrenzt, wenn es um die Kette der Geldbehandlung bei Krypto-Institutionen geht – die verbundenen Identitäten, Cloud-Infrastrukturen, Signier-Workflows, Genehmigungsketten, Wallets, Anbieter und Betreiberkonsolen, durch die Werte von einem Einstiegspunkt bis zu einer geldbewegenden Aktion fließen. Der für einen Angreifer erreichbare Pfad ist eine Route über diese Kette: Er kann von einem Web-, dApp-, Mobil-, API-, Cloud- oder Identitätseinstiegspunkt durch Signierung, Genehmigung und Geldlogik verlaufen und dabei durchqueren, 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 wenn beide zusammen eingesetzt werden, kann eine Kompositionslücke bestehen bleiben: Ein Audit zeigt, dass der Code wie geschrieben solide war, nicht dass die eingesetzten Identitäten, Genehmigungen und Signierer ihn noch immer durchsetzen; und Monitoring kann eine Überweisung passieren lassen, die technisch gültig ist, aber nie das war, was der Betreiber beabsichtigt hatte. Was diese Lücke schließt, ist eine unabhängige gegnerische Validierung, dass die Kontrollen im laufenden System korrekt zusammenwirken.

Blockchain-Penetrationstests beanspruchen das zusammengesetzte, laufende System, um herauszufinden und zu demonstrieren, ob ein solcher Pfad die Gelder erreichen kann, bevor ein Vorfall dies offenlegt. Das Bybit-Muster zeigt die Form des Problems: Eine kompromittierte Signierschnittstelle verwandelte die eigene Genehmigung der Betreiber in eine Überweisung, die sie nie beabsichtigt hatten – ein Ergebnis, das der Vertrag, ein Audit davon und die Transaktionsüberwachung jeweils als legitim hätten lesen können. Blockchain-Penetrationstests zielen direkt auf diese Zusammensetzung ab: Aus der Position eines kompromittierten Anbieters, Betreibers oder einer kompromittierten Schnittstelle wird getestet, ob ein solcher Zugang eine legitim aussehende Genehmigung in eine unautorisierte Geldbewegung verwandeln kann, und welche eingesetzten Kontrollen – Identitäten, Genehmigungsschritte, Signierprüfungen – dies tatsächlich verhindern. Die Sicherstellung auf Vertragscode-Ebene bleibt Aufgabe des Audits; Blockchain-Penetrationstests befassen sich mit einem eingesetzten Vertrag nur über sein Live-Verhalten, soweit dies Teil einer institutionellen Route zu den Geldern bildet – komplementäre Geltungsbereiche, die sich durch den Schwerpunkt 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 Bereiche mit privilegiertem Zugriff. Ihre Einschränkung liegt im Geltungsbereich und Fachkontext: Ein herkömmlicher Einsatz bringt möglicherweise nicht die geschäftliche Semantik von Krypto oder das gekoppelte Sicherheits- und Compliance-Modell mit sich.

Im Kryptobereich kann eine Signatur eine unwiderrufliche Wertbewegung autorisieren; die Genehmigung einer Abhebung ist eine Entscheidung zur Geldkontrolle, nicht bloß eine Formularübermittlung. Einzahlungsgutschriften, Kontostandsbuchhaltung und interne Überweisungen sind Geldlogik. Adressen und Transaktionen können auch Sanktions- oder Herkunftsbedeutung von Geldern tragen. Ein Tester könnte eine Authentifizierungsumgehung finden, aber übersehen, wie sie sich mit einer fehlerhaften Signieranzeige, einer schwachen Genehmigungsrichtlinie oder einem Rundungsfehler zu einem Pfad zu den Geldern verbindet.

Blockchain-Penetrationstests wenden etablierte gegnerische Techniken auf traditionelle Angriffsflächen sowie auf Web3-spezifische Signier-, Genehmigungs-, Geldlogik- und Vertragsdynamik-Flächen im gesamten laufenden System an. Ihr Unterscheidungsmerkmal ist spezialisiertes Web3-Sicherheitsurteilsvermögen, nicht neues Werkzeug: Tester interpretieren Verwahrung, Transaktionsabsicht, Geldflüsse und Compliance-Kontrollen so, wie es ein Angreifer täte. Der Unterschied liegt im Ziel: Ein herkömmlicher Test weist typischerweise eine Auswirkung auf die IT-Kontrolle nach – eine übernommene Administratorsitzung, ein erreichter Server –, während ein Blockchain-Test die Bewegung von Werten als Endbedingung betrachtet. Er geht weiter: Er verändert den Empfänger oder Betrag innerhalb einer legitimen Signieranfrage und prüft, ob das, was der Genehmiger sieht, die Genehmigungsrichtlinie und die tatsächlich bewegten Gelder noch übereinstimmen.

Zusammengefasst handelt es sich um eine komplementäre Absicherung, nicht um eine starre Trennung zwischen statisch und dynamisch. Code-Audits, Transaktionsüberwachung und traditionelle Penetrationstests bleiben notwendig. Blockchain-Penetrationstests verbinden sie, indem sie erreichbare Pfade validieren; sie ersetzen sie nicht, garantieren keine Entdeckung von Einbrüchen und keine Verhinderung.

Teil 2: Was Regulierungsbehörden verlangen

Die Anforderungen variieren je nach Rechtsordnung und schaffen ein Spektrum aus Lizenzierungs-, laufenden und aufsichtsrechtlich ausgelösten Verpflichtungen für bestimmte Einrichtungen und Systeme.

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

• Vereinigte Staaten, New York: ausdrückliche Anforderung mit begrenzter Ausnahme. Erfasste Einrichtungen gemäß NYDFS 23 NYCRR Part 500 [12], einschließlich der von der DFS lizenzierten Virtual-Currency-Unternehmen, müssen Informationssysteme risikobasiert mindestens jährlich sowohl von innerhalb als auch von außerhalb ihrer Grenzen testen. Eine qualifizierte interne oder externe Partei darf testen. Kleine Einrichtungen, die die Voraussetzungen erfüllen, erhalten eine begrenzte Ausnahme von dieser Testvorschrift, unterliegen aber weiterhin den übrigen anwendbaren Bestimmungen von Part 500.

• Dubai: jährliche und änderungsbedingt ausgelöste 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. Smart-Contract-Audits gelten, sofern für das Geschäft und die Aktivitäten des VASP relevant. Threat-Led-Penetrationstests haben keine universelle Taktung: Die VARA kann sie bei Bedarf und risikobasiert als notwendig und angemessen verlangen.

• Hongkong: Lizenzbedingungsanforderung für als lizenziert geltende Antragsteller. Antragsteller, die als lizenzierte Handelsplattform für virtuelle Vermögenswerte gelten, müssen Penetrationstests und Schwachstellenbewertungen mit zufriedenstellenden Ergebnissen vor Aufnahme des eingeschränkten Betriebs abschließen [14]. Für Antragsteller neuer Gesellschaften gilt eine gesonderte Anleitung. Ein unabhängiger Dritter muss die festgelegte Infrastruktur und Anwendungen über Anwendungs- und Netzwerkschichten hinweg abdecken. Vor Aufnahme des eingeschränkten Betriebs muss das Management alle wesentlichen und kritischen Behebungsschritte für Feststellungen mit mittlerem bis hohem Risiko abgeschlossen haben.

• Europäische Union: proportionaler Rahmen; TLPT abhängig von Identifizierung. DORA erfasst Finanzunternehmen, einschließlich Anbieter von Krypto-Asset-Dienstleistungen [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. Threat-Led-Penetrationstests gelten nur für Einrichtungen, die von den zuständigen Behörden identifiziert wurden, laufen auf realen Produktionssystemen und sind grundsätzlich mindestens alle drei Jahre erforderlich; die Behörden können diese Häufigkeit aus Risikogründen anpassen. DORA legt zudem Bedingungen zur Unabhängigkeit der Tester fest. Kleinstunternehmen sind von der Anforderung des Testprogramms ausgenommen.

• Singapur: nicht verbindliche 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 wesentlichen Änderungen oder Aktualisierungen getestet werden [16]. Dies ist eine nicht verbindliche aufsichtsrechtliche Leitlinie und erfordert keinen unabhängigen Dritten. Die verbindliche, auf Banken bezogene Cyber Hygiene Notice spezifiziert keine Penetrationstests. Die verbindliche Notice zu Zahlungen oder Digital Payment Tokens liegt außerhalb des Geltungsbereichs dieses Artikels.

Insgesamt betrachtet verlangen oder erwarten diese Regelwerke Penetrationstests – keine eigens gebrandete „Web3“-Kategorie. Die Web3-Spezialistenversion ergibt sich aus den erfassten Systemen: Wo diese Kryptowerte autorisieren, signieren, verwahren oder verbuchen, erfordert eine ordnungsgemäße Prüfung dieselbe Signier- und Geldflusskompetenz, die in Teil 1 beschrieben wird.

Das Fazit ist präzise: Eine erhebliche Anzahl lizenzierter Einrichtungen in bestimmten Rechtsordnungen unterliegt bereits einer Anforderung oder aufsichtsrechtlichen Erwartung – nicht überall demselben Mandat. Die Unterschiede bestimmen Geltungsbereich, Taktung, Unabhängigkeit der Tester, Abhilfemaßnahmen, Nachweise und ob die Tests der Lizenzierung, der laufenden Compliance oder einer aufsichtsrechtlich ausgelösten Übung dienen.

Fazit: Die beiden Säulen laufen zusammen

Risikoherkunft sowie regulatorische Anforderungen oder Erwartungen führen zur selben Schlussfolgerung: Für Institutionen im Geltungsbereich sind Blockchain-Penetrationstests eine notwendige Sicherungsebene. Sie validieren erreichbare Pfade über Zugang, Genehmigung, Signierung und Gelder hinweg und ergänzen dabei bestehende Kontrollen. Sie können keine Verhinderung garantieren, nicht belegen, dass sie einen bestimmten vergangenen Vorfall gestoppt hätten, und nicht jeden ausnutzbaren Pfad finden. Ziel ist eine fortlaufende Absicherung über Einführung, Betrieb, Erkennung, Reaktion und regulatorische Nachweise hinweg – kein einmaliger Bericht.

Weiter in der Serie:

• Teil 2: Was ist Blockchain-Penetrationstesting? 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 Signiersicherheit: Web, dApps und
• Teil 6: Cloud- und CI/CD-Sicherheit: Angriffsflächen automatisierter Betriebsabläufe
• Teil 7: Sicherheit der Treasury-Kontrollebene: Signier- und Abhebungsgenehmigungen
• Teil 8: Sicherheit von Exchange-Ledgern: Diebstahlspfade und Logik der Datenebene

BlockSec unterstützt Institutionen dabei, diese Ebene präzise einzuordnen: Kartierung von Vermögenswerten, Geldflüssen, Vertrauensgrenzen und bestehender Absicherung; Bestätigung der geltenden Verpflichtungen gemäß rechtlicher Beratung; anschließend Definition von Testziel, Geltungsbereich, Zugang, Produktionsschutzmaßnahmen, Nachweisen zur Behebung und Retest-Plan. Um Ihre Sicherungslücke zu identifizieren, sprechen Sie mit unserem Blockchain-Penetrationstest-Team; Umfang und Preisgestaltung des Einsatzes sind auf Anfrage erhältlich. Beginnen Sie dort, wo die Gelder bewegt werden.

Referenzen

Nummeriert in der Reihenfolge des ersten Auftretens.

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, Part I, Section E.
14. Hong Kong Securities and Futures Commission, Circular 24EC65 (18. Dezember 2024, PDF).
15. Europäische Union, Regulation (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).