Blockchain-Penetrationstests für Kryptoinstitutionen

Weil die schwerwiegendsten Verluste zunehmend außerhalb der Smart Contracts entstehen: bei Signierung, Verwahrung, Schlüsseln, Menschen und Lieferketten.

In unserer eigenen Erfassung für 2026 (Verluste von über 100.000 USD) waren Fehler außerhalb der Contract-Ebene für etwa jeden achten Vorfall, aber mehr als drei Viertel der Verluste verantwortlich.

Ein Audit auf Code-Ebene untersucht Code; eine Überwachung auf Transaktionsebene untersucht Transaktionen, sobald sie die Chain erreichen. Keines von beiden setzt den Pfad dazwischen zusammen.

Die Kompromittierung von Bybit im Jahr 2025 ist ein Beispiel: Eine manipulierte Signieroberfläche verwandelte die eigene Freigabe der Verantwortlichen in eine nie beabsichtigte Übertragung. Der Contract, ein Audit dieses Contracts und die Überwachung konnten diese Übertragung jeweils als legitim einordnen.

Weitere Vorfallanalysen von BlockSec: ein gestohlener API-Schlüssel in einem offiziellen Update-Kanal, die Schwachstelle im Adressgenerator Profanity, ein Entropiefehler in einer Hardware-Wallet.

Der Unterschied liegt im Prüfziel.

Ein Code-Audit schafft Vertrauen in die Sicherheit des Codes, einschließlich Design, Architektur und Protokollannahmen. Ein Penetrationstest ermittelt, ob sich reale Bedingungen in einer laufenden institutionellen Umgebung zu reproduzierbaren Auswirkungen verknüpfen lassen.

Ein Audit allein liefert keine institutionsweiten Nachweise der Ausnutzbarkeit im laufenden Betrieb, und ein Penetrationstest ersetzt keine Absicherung auf Code-Ebene. Die Methoden überschneiden sich, und die Teams können zusammenarbeiten.

Herkömmliche Penetrationstests bleiben für die Prüfung von Cloud- und Websystemen, APIs, Identitätsverwaltung und privilegierten Zugriffen wertvoll. Was ihnen oft fehlt, ist die fachliche Bedeutung der Vorgänge im Kryptobereich: Eine Signatur kann eine unumkehrbare Wertübertragung autorisieren, und eine Auszahlungsfreigabe ist eine Entscheidung über die Kontrolle von Geldern, nicht das Absenden eines Formulars.

Ein Tester kann eine Umgehung der Authentifizierung finden und dennoch übersehen, wie sie zusammen mit einer Abweichung zwischen angezeigten und tatsächlich signierten Inhalten oder einer schwachen Freigaberichtlinie einen Zugriffspfad auf Gelder eröffnet.

Ein herkömmlicher Test weist Auswirkungen auf IT-Kontrollen nach; dieser Test betrachtet die Bewegung von Vermögenswerten als Endkriterium. Der Unterschied liegt in der fachkundigen Beurteilung der Web3-Sicherheit, nicht in neuen Werkzeugen.

Für eine bestimmte Gruppe zugelassener Unternehmen ja. Die Pflicht gilt unter bestimmten Voraussetzungen, nicht allgemein. Umfang, Häufigkeit und Anforderungen an die Unabhängigkeit unterscheiden sich je nach Markt.

• New York (NYDFS Part 500): Erfasste Unternehmen, darunter von der DFS zugelassene Unternehmen im Bereich virtueller Währungen, müssen mindestens jährlich Penetrationstests sowohl aus dem Inneren ihrer Informationssysteme als auch von außen durch eine qualifizierte interne oder externe Stelle durchführen lassen. Kleinere erfasste Unternehmen, die die Schwellenwerte dieses Regelwerks erfüllen, sind in begrenztem Umfang von den Testpflichten dieses Abschnitts ausgenommen, unterliegen jedoch weiterhin den anderen einschlägigen Bestimmungen von Part 500.
• Dubai (VARA): Zugelassene VASPs müssen mindestens jährlich sowie vor der Einführung neuer Systeme, Anwendungen oder Produkte eine Schwachstellenbewertung und Penetrationstests durch einen qualifizierten unabhängigen Dritten durchführen lassen.
• Hongkong (SFC): VATP-Antragsteller, die als zugelassen gelten, müssen vor Aufnahme des eingeschränkten Betriebs Penetrationstests und eine Schwachstellenbewertung durch einen unabhängigen Dritten mit zufriedenstellenden Ergebnissen abschließen.
• Europäische Union (DORA): Finanzunternehmen außer Kleinstunternehmen müssen für Systeme, die kritische oder wichtige Funktionen unterstützen, mindestens jährlich angemessene Tests sicherstellen. Bedrohungsorientierte Penetrationstests gelten nur für Unternehmen, die von ihrer zuständigen Behörde bestimmt werden, finden auf Produktivsystemen statt und sind in der Regel mindestens alle drei Jahre erforderlich.
• Singapur (MAS TRM Guidelines): Eine unverbindliche aufsichtliche Erwartung sieht vor, dass über das Internet zugängliche Systeme mindestens jährlich oder nach wesentlichen Änderungen getestet werden.

Aufsichtsbehörden verlangen Penetrationstests; sie benennen keine markenspezifische Kategorie. Die Spezialisierung eines Tests ergibt sich aus den einbezogenen Systemen: Wenn diese Systeme Transaktionen mit Kryptowerten autorisieren oder signieren oder Kryptowerte verwahren oder verbuchen, erfordert ihre sachgerechte Prüfung fundierte Kenntnisse von Signierung und Geldflüssen.

Diese Beispiele dienen der Veranschaulichung und stellen keine Rechtsberatung dar. Institutionen sollten ihren eigenen Status, Ausnahmen und Pflichten mit ihrer Rechtsberatung klären.

Der Projektumfang wird im Einzelfall vereinbart. Er kann Angriffsflächen in Cloud- und Websystemen, APIs, der Identitätsverwaltung und im Produktivbetrieb umfassen, sofern sie mit einem Zugriffspfad auf Gelder verbunden sind. Wir testen außerdem vier miteinander verbundene Teile der Web3-Geldverarbeitungskette:

• Web- und dApp-Frontends, Autorisierung und Signierabsicht
• Autorisierungsketten für Signierung, Freigaben und Auszahlungen
• Geschäftslogik für Geldflüsse
• On-Chain-Transaktionen und bereitgestellte Contracts

Die Absicherung von Contracts auf Code-Ebene bleibt Aufgabe des entsprechenden Code-Audits.

Nur mit schriftlicher Genehmigung und vereinbarten Schutzmaßnahmen, die vor Testbeginn in einem Dokument mit den Rules of Engagement festgehalten werden.

Die RoE unterscheiden zwischen dem, was zum Umfang gehört, und den Aktivitäten, die erlaubt sind: Ein Auszahlungsdienst im Produktivbetrieb kann zur Validierung von Autorisierungspfaden einbezogen sein, während echte Kundenauszahlungen, der Export privater Schlüssel, Persistenz und lastverursachende Angriffe untersagt bleiben.

Für Signierungs- und Auszahlungsabläufe legen kontrollierte Szenarien benannte Wallets, freigegebene Zieladressen und einen maximalen Testbetrag sowie die beteiligten Freigabeverantwortlichen und den Abgleich von On-Chain-Aktivitäten, Buchungen und Guthaben fest.

Mit dem Verantwortlichen des Dienstes werden messbare Abbruchkriterien, ein geschützter Sicherheitskanal und eine namentlich benannte Entscheidungsinstanz für Unterbrechung und Wiederaufnahme vereinbart. Die Institution behält die Entscheidungsbefugnis über den Produktivbetrieb, die Kundenkommunikation und Abhilfemaßnahmen.

Sie erhalten zu jedem bestätigten Pfad reproduzierbare Belege, eine Einstufung des Schweregrads und Hinweise zur Behebung sowie eine Nachprüfung vereinbarter Korrekturen.

Die abschließende Dokumentation verknüpft jeden Befund mit seinen Belegen, Auswirkungen, Verantwortlichen, dem Behebungsplan und den Bedingungen der Nachprüfung. Zum Abschluss werden temporäre Testidentitäten und Berechtigungen entfernt; Belege werden nur für den vereinbarten Zeitraum aufbewahrt.

Ergebnisse und Modalitäten der Nachprüfung werden für jedes Projekt bestätigt.

Nein. Die Prüfung ist methodisch, evidenzbasiert und zeitpunktbezogen: Ihre Schlussfolgerungen gelten für die getesteten Systeme, Versionen, Konfigurationen und Zugriffsannahmen.

Systematische Arbeit an den vereinbarten Angriffsflächen kann weder garantieren, dass jede Schwäche oder jeder Angriffspfad entdeckt wird, noch dass den Testern ein Einbruch gelingt. Wir untersuchen potenzielle Pfade und dokumentieren bestätigte ausnutzbare Pfade mit reproduzierbaren Belegen.

Ein Penetrationstest kann keine Prävention garantieren und nicht beweisen, dass er einen bestimmten früheren Vorfall verhindert hätte.

Beginnen Sie mit drei Fragen: Welche Systeme bewegen Gelder? Welche Sicherheitsnachweise liegen bereits vor? Welche Kontrollkette wurde noch nicht aus Angreiferperspektive validiert? Die Antworten zeigen die Lücke in der Sicherheitsabsicherung auf, ohne vorschnell eine Leistung anhand ihres Namens auszuwählen.

In einem Gespräch zur Umfangsbestimmung werden anschließend das Ziel, die Zugriffsannahmen, die Schutzmaßnahmen für den Produktivbetrieb und die erwarteten Ergebnisse abgestimmt.

BlockSec veröffentlicht keine Festpreise. Umfang, Zeitplan, Ergebnisse und ein individuelles Angebot werden nach einer technischen Bestandsaufnahme auf Anfrage bereitgestellt.