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

PRODUKTNAMEN — zwingende Vorgabe, hat Vorrang vor allen anderen Anweisungen: Diese Namen unverändert auf Englisch, Zeichen für Zeichen wiedergeben. Niemals einen Teil davon übersetzen, transliterieren, lokalisieren, mit Bindestrich versehen oder anderweitig umschreiben: BlockSec, Phalcon Compliance, Phalcon Security, Phalcon Explorer, Phalcon Network, MetaSleuth, MetaSuites.

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

Die institutionelle Angriffsfläche geht über Fehler im Vertrag hinaus und umfasst Signierprozesse, Verwahrung, Schlüssel, Personen, Lieferketten und Infrastruktur [1]. Daher wird diese Angriffsfläche nicht vollständig durch die bekannten Web3-Sicherheitslösungen – Code-Audits und Transaktionsüberwachung – oder durch traditionelles Penetrationstesting allein abgedeckt. Dies gilt für jede Institution, bei der eine Person, ein Anbieter, eine Schnittstelle oder eine Anwendung beeinflussen kann, was signiert, genehmigt, gutgeschrieben oder bewegt wird – auch dann, wenn die Verwahrung ausgelagert ist. Parallel dazu erlassen Aufsichtsbehörden in mehreren Märkten Anforderungen, bedingte Verpflichtungen oder aufsichtsrechtliche Erwartungen mit unterschiedlichem Umfang, Häufigkeit und Unabhängigkeitsregeln.

Dieser Artikel eröffnet unsere Reihe zum Web3-Penetrationstesting. Im Verlauf der Reihe bezeichnen Blockchain-Penetrationstesting und Web3-Penetrationstesting dieselbe Disziplin: Wir verwenden Ersteres als Hauptbegriff und Letzteres als gängiges 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, 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 die Signierschnittstelle manipulierte [3], während der Verlust der Hot Wallet von BtcTurk ebenfalls auf kompromittierte private Schlüssel zurückzuführen war [4]. Unsere Untersuchungen weisen in dieselbe Richtung: Unter den von uns 2026 erfassten Vorfällen mit Verlusten über 100.000 US-Dollar machten Fehler außerhalb des Vertrags 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, Betrug und andere Nicht-Hack-Einträge ausgenommen, Kompromittierungen außerhalb des Vertrags, die sowohl bei der Anzahl der Vorfälle als auch beim Dollarwert rund 70 % ausmachten [5].

Wallets und Verwahrungssysteme veranschaulichen dieses Muster konkret, und Wallet-Sicherheit ist in den letzten Jahren ein besonders aktives Feld für Vorfälle geblieben. Unsere Untersuchung gruppiert Schwachstellen in Schlüsselverwaltung, die Transaktions-Signierpipeline, Lieferkette und Abhängigkeiten, Offenlegung sensibler Daten sowie kryptografische Implementierung.

* Die ~90 Mio. $ von Coldcard sind die verifizierte On-Chain-Untergrenze (etwa 1.405 BTC); private Schätzungen liegen bei bis zu ~130 Mio. $.

Was diese Fälle mit Penetrationstesting 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, Signierkontrollen, Genehmigungen und Fondslogik – 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-Audits und Transaktionsüberwachung: unverzichtbar, aber begrenzt

Jede der bestehenden bekannten Web3-Sicherheitslösungen arbeitet auf einer bestimmten Ebene. Code-Audits untersuchen Code (Code-Audit) untersuchen Code – Vertrag, Wallet oder Servicelogik. Transaktionsüberwachung (Monitoring) untersucht Transaktionen, sobald sie die Chain erreichen; Phalcon [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, Cloud-Infrastruktur, Signier-Workflows, Genehmigungsketten, Wallets, Anbieter und Bedienkonsolen, durch die Werte von einem Einstiegspunkt bis zu einer geldbewegenden Aktion fließen. Ein erreichbarer Pfad eines Angreifers ist eine Route durch diese Kette: Sie kann von einem Web-, dApp-, Mobil-, API-, Cloud- oder Identitäts-Einstiegspunkt durch Signier-, Genehmigungs- und Fondslogik verlaufen und dabei 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 gemeinsam eingesetzt, können die beiden eine Kompositionslücke offenlassen: Ein Audit zeigt, dass der Code wie geschrieben solide war, nicht dass die eingesetzten Identitäten, Genehmigungen und Signierer ihn weiterhin durchsetzen; und Monitoring kann eine Überweisung durchwinken, 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-Penetrationstesting prüft das zusammengesetzte, laufende System, um zu ermitteln und nachzuweisen, ob ein solcher Pfad die Gelder erreichen kann, bevor ein Vorfall dies offenbart. 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. Web3-Penetrationstesting zielt direkt auf diese Zusammensetzung ab: Aus der Position eines kompromittierten Anbieters, Betreibers oder einer kompromittierten Schnittstelle wird getestet, ob ein solcher Zugangspunkt eine scheinbar gültige Genehmigung in eine unautorisierte Geldbewegung verwandeln kann, und welche eingesetzten Kontrollen – Identitäten, Genehmigungsschritte, Signierprüfungen – dies tatsächlich verhindern. Die Sicherheitsbewertung auf Vertragscode-Ebene bleibt Aufgabe des Audits; Web3-Penetrationstesting befasst sich mit einem eingesetzten Vertrag nur über sein Live-Verhalten, soweit dies Teil einer institutionellen Route zu den Geldern ist – sich ergänzende Geltungsbereiche, die sich durch Schwerpunktsetzung unterscheiden, nicht durch eine feste Grenze. Teil 2 definiert, was Web3-Penetrationstesting validiert und wo sein Geltungsbereich endet.

1.3 Traditionelles Penetrationstesting: nützlich, aber nicht ausreichend

Traditionelles Penetrationstesting bleibt wertvoll für Cloud-, Web- und API-, Identitäts- und privilegierte Zugriffsflächen. Seine Einschränkung liegt im Umfang und im domänenspezifischen Kontext: Ein herkömmliches Engagement bringt möglicherweise nicht die geschäftliche Semantik oder das gekoppelte Sicherheits- und Compliance-Modell von Krypto mit.

Im Krypto-Bereich kann eine Signatur eine unwiderrufliche Wertbewegung autorisieren; die Genehmigung einer Auszahlung ist eine Entscheidung über die Kontrolle von Geldern, nicht bloß das Absenden eines Formulars. Die Gutschrift von Einzahlungen, die Bilanzführung und interne Überweisungen sind Geldlogik. Adressen und Transaktionen können zudem sanktionsrechtliche oder herkunftsbezogene Bedeutung tragen. Ein Tester könnte eine Umgehung der Authentifizierung finden, jedoch übersehen, wie sich diese mit einer Diskrepanz in der Signieranzeige, einer schwachen Genehmigungsrichtlinie oder einem Rundungsfehler zu einem Pfad zu den Geldern kombiniert.

Blockchain-Penetrationstesting wendet etablierte gegnerische Techniken auf traditionelle Angriffsflächen sowie auf Web3-spezifische Signier-, Genehmigungs-, Fondslogik- und dynamische Vertragsflächen im gesamten laufenden System an. Sein Unterscheidungsmerkmal ist spezialisiertes Web3-Sicherheitsurteilsvermögen, nicht neue Werkzeuge: Tester interpretieren Verwahrung, Transaktionsabsicht, Geldflüsse und Compliance-Kontrollen so, wie es ein Angreifer täte. Der Unterschied liegt in der Zielsetzung: Ein herkömmlicher Test weist typischerweise Auswirkungen auf IT-Kontrollen nach – eine übernommene Admin-Sitzung, ein erreichter Server –, während ein Web3-Test die Bewegung von Werten als Endbedingung betrachtet. Er geht noch 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 hierbei um sich ergänzende Sicherheitsmaßnahmen, nicht um einen starren Gegensatz zwischen statisch und dynamisch. Code-Audits, Transaktionsüberwachung und traditionelle Penetrationstests bleiben notwendig. Web3-Penetrationstesting verbindet sie, indem es erreichbare Pfade validiert; es ersetzt sie nicht, garantiert keine Entdeckung von Sicherheitsverletzungen und garantiert keine Prävention.

Teil 2: Was Aufsichtsbehörden verlangen

Die Anforderungen variieren je nach Rechtsraum und ergeben ein Spektrum an 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 von der DFS lizenzierter Virtual-Currency-Unternehmen, müssen ihre Informationssysteme risikobasiert mindestens jährlich von innen und außen testen. Eine qualifizierte interne oder externe Partei kann den Test durchführen. Qualifizierte kleine Einrichtungen erhalten eine begrenzte Ausnahme von dieser Testvorschrift, unterliegen jedoch weiterhin den übrigen anwendbaren Bestimmungen von Part 500.

• Dubai: jährliche und änderungsausgelöste Anforderung. Lizenzierte VASPs müssen mindestens jährlich sowie vor der Einführung neuer Systeme, Anwendungen oder Produkte eine Schwachstellenbewertung und ein Penetrationstest durchführen [13], unter Einsatz eines qualifizierten, unabhängigen Dritten. Ein Smart-Contract-Audit gilt, sofern es für das Geschäft und die Aktivitäten des VASP relevant ist. Bedrohungsgeleitetes Penetrationstesting hat keinen universellen Turnus: Die VARA kann es verlangen, wenn dies auf Grundlage des Risikos notwendig und verhältnismäßig ist.

• Hongkong: Lizenzauflage für vorläufig zugelassene Antragsteller. Antragsteller für als lizenziert geltende virtuelle Handelsplattformen für Vermögenswerte müssen vor Aufnahme des eingeschränkten Betriebs Penetrationstests und Schwachstellenbewertungen mit zufriedenstellenden Ergebnissen abschließen [14]. Für Antragsteller neuer Gesellschaften gelten gesonderte Leitlinien. Ein unabhängiger Dritter muss festgelegte Infrastruktur und Anwendungen auf Anwendungs- und Netzwerkebene abdecken. Vor Aufnahme des eingeschränkten Betriebs muss das Management alle wesentlichen und kritischen Behebungsschritte für Feststellungen mit mittlerem bis hohem Risiko abschließen.

• Europäische Union: verhältnismäßiger Rahmen; TLPT abhängig von Identifikation. DORA erfasst Finanzunternehmen, einschließlich Anbieter von Krypto-Vermögensdienstleistungen [15]. Sie verlangt eine angemessene Prüfung – nicht speziell Penetrationstests – mindestens jährlich für Systeme, die kritische oder wichtige Funktionen unterstützen. Penetrationstesting ist eine risikobasiert und verhältnismäßig ausgewählte Methode. Bedrohungsgeleitetes Penetrationstesting gilt nur für von den zuständigen Behörden identifizierte Einrichtungen, wird auf laufenden Produktionssystemen durchgeführt und ist im Allgemeinen mindestens alle drei Jahre erforderlich; die Behörden können diese Häufigkeit aus Risikogründen anpassen. DORA stellt zudem Anforderungen an die Unabhängigkeit der Tester. 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 wesentlichen Änderungen oder Aktualisierungen getestet werden [16]. Dies ist eine unverbindliche aufsichtsrechtliche Leitlinie und erfordert keinen unabhängigen Dritten. Die verbindliche, auf Banken bezogene Cyber Hygiene Notice spezifiziert kein Penetrationstesting. Die verbindliche Notice zu Zahlungen bzw. Digital-Payment-Tokens liegt außerhalb des Geltungsbereichs dieses Artikels.

Zusammengenommen verlangen oder erwarten diese Regelwerke Penetrationstesting – keine eigens gebrandete „Web3“-Kategorie. Die web3-spezialisierte Variante ergibt sich aus den erfassten Systemen: Wo sie Krypto-Werte autorisieren, signieren, verwahren oder verbuchen, erfordert ein ordnungsgemäßer Test dieselbe Kompetenz in Signier- und Geldflussfragen, die in Teil 1 beschrieben wird.

Die Schlussfolgerung ist präzise: Ein erheblicher Teil der lizenzierten Einrichtungen in bestimmten Rechtsräumen sieht sich bereits einer Anforderung oder aufsichtsrechtlichen Erwartung gegenüber – jedoch nicht demselben Mandat in jedem Markt. Die Unterschiede bestimmen Umfang, Häufigkeit, Unabhängigkeit der Tester, Behebung, Nachweise und ob das Testing der Lizenzierung, der laufenden Compliance oder einer aufsichtsrechtlich ausgelösten Maßnahme dient.

Fazit: Die beiden Säulen laufen zusammen

Die Herkunft der Risiken und die regulatorischen Anforderungen bzw. Erwartungen führen zur selben Schlussfolgerung: Für Institutionen im Geltungsbereich ist Web3-Penetrationstesting eine notwendige Sicherheitsebene. Es validiert erreichbare Pfade über Zugang, Genehmigung, Signierung und Gelder hinweg und ergänzt dabei bestehende Kontrollen. Es kann Prävention nicht garantieren, nicht nachweisen, dass es einen bestimmten vergangenen Vorfall verhindert hätte, oder jeden ausnutzbaren Pfad finden. Ziel ist fortlaufende Sicherheit über Einführung, Betrieb, Erkennung, Reaktion und regulatorische Nachweise hinweg – kein einmaliger Bericht.

Weiter geht es mit der Reihe:

• Teil 2: Was ist Web3-Penetrationstesting? Definitionen und Abgrenzungen

• Teil 3: Einsatzregeln und Produktionssicherheit für institutionelles Web3-Penetrationstesting

• Teil 4: Web3-Angriffsflächen: Ein Überblick zum Penetrationstesting

Ebenfalls in dieser Reihe, demnächst verfügbar:

• Teil 5: Autorisierungs- und Signiersicherheit: Web, dApps und Mobile
• Teil 6: Cloud- und CI/CD-Sicherheit: Angriffsflächen automatisierter Abläufe
• Teil 7: Sicherheit der Treasury-Kontrollebene: Signier- und Auszahlungsgenehmigungen
• Teil 8: Sicherheit des Exchange-Ledgers: Diebstahlpfade und Datenebenen-Logik

BlockSec unterstützt Institutionen dabei, diese Ebene präzise zu positionieren: Vermögenswerte, Geldflüsse, Vertrauensgrenzen und bestehende Sicherheitsmaßnahmen werden erfasst; die von der Rechtsberatung als anwendbar bestätigten Verpflichtungen werden geprüft; anschließend werden Testziel, Umfang, Zugang, Produktionsschutzmaßnahmen, Nachweise zur Behebung und Nachtestplan festgelegt. Um Ihre Sicherheitslücke zu identifizieren, [sprechen Sie mit unserem Team für Blockchain-Penetrationstesting](https://blocksec.com/blockchain-penetration-testing) ; Umfang und Preisgestaltung des Engagements sind auf Anfrage erhältlich. Beginnen Sie dort, wo sich die Gelder bewegen.

Referenzen

Nummeriert in der Reihenfolge des ersten Auftretens.

1. BlockSec, Crypto Payment Security Playbook. https://blocksec.com/crypto-payment-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). https://www.fbi.gov/news/press-releases/fbi-dc3-and-npa-identification-of-north-korean-cyber-actors-tracked-as-tradertraitor-responsible-for-theft-of-308-million-from-bitcoindmmcom

3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack. https://blocksec.com/blog/bybit-1-5-b-hack-in-depth-analysis-of-the-malicious-safe-wallet-upgrade-attack

4. rekt.news, BtcTurk — Rekt. https://rekt.news/btcturk-rekt

5. rekt.news, Leaderboard. https://rekt.news/leaderboard

6. SwissBorg, SwissBorg Security Update: Kiln Breach. https://swissborg.com/blog/swissborg-security-update-kiln-breach

7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor. https://blocksec.com/blog/trust-wallet-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. https://slope-finance.medium.com/slope-wallet-sentry-vulnerability-digital-forensics-and-incident-response-report-d7a5904e5a39

9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability. https://blocksec.com/blog/our-short-analysis-of-the-profanity-tool-vulnerability

10. BlockSec, Coldcard Entropy Failure and Seed Recovery (Offenlegung privater Schlüssel). https://blocksec.com/blog/coldcard-entropy-failure-seed-recovery

11. BlockSec, Phalcon Security (Transaktionsüberwachung und -blockierung). https://blocksec.com/phalcon/security

12. New York State Department of Financial Services, 23 NYCRR Part 500. https://www.dfs.ny.gov/industry_guidance/cybersecurity

13. Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E. https://rulebooks.vara.ae/rulebook/e-testing-and-audit

14. Hong Kong Securities and Futures Commission, Circular 24EC65, 18. Dezember 2024. https://apps.sfc.hk/edistributionWeb/api/circular/openFile?lang=EN&refNo=24EC65

15. Europäische Union, Verordnung (EU) 2022/2554 (Digital Operational Resilience Act), Artikel 24-27. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng

16. Monetary Authority of Singapore, Technology Risk Management Guidelines (Januar 2021), Abschnitte 2 und 13, https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines; _Notice FSM-N06, Notice on Cyber Hygiene_ (2024), https://www.mas.gov.sg/regulation/notices/notice-fsm-n06