Über Krypto-Hacker wird oft so gesprochen, als übten sie alle dieselbe Tätigkeit aus und unterschieden sich nur in ihren Motiven. In der Praxis wird die Grenze zwischen einem Whitehat-Sicherheitsforscher und einem Blackhat-Angreifer ebenso sehr durch Autorisierung, Umfang und den Verbleib der Gelder bestimmt wie durch technisches Können. Beide Typen können Smart Contracts, Bridges, Wallets, Validatoren, private Schlüssel und Protokolllogik auf Expertenniveau verstehen. Was sie trennt, ist die Art, wie dieses Wissen eingesetzt wird.

Whitehat-Hacker suchen nach Schwachstellen, damit diese behoben werden können, bevor Nutzer Geld verlieren. Blackhats nutzen Schwächen für Diebstahl, Erpressung, Marktmanipulation, den Zugang zu privaten Informationen oder die Kontrolle über Infrastruktur aus. Krypto erschwert diese Unterscheidung, weil ein Notfall-Whitehat während eines laufenden Angriffs manchmal gefährdete Gelder bewegen kann, während ein Blackhat gestohlene Vermögenswerte später zurückgeben und darum bitten kann, einen Teil der Beute als Bounty behalten zu dürfen.

Diese Grauzone ist zunehmend sichtbar geworden, da DeFi-Protokolle große Vermögenspools in Code halten, den jeder einsehen kann. Branchenstatistiken wie die jährlichen Krypto-Kriminalitätsberichte von Chainalysis verzeichnen in jedem der letzten Jahre weit über eine Milliarde Dollar an Diebstählen von Krypto-Plattformen, wodurch die Frage, wer ein Protokoll testet – und zu welchen Bedingungen – im Mittelpunkt der Sicherheitsdebatte bleibt. Den Unterschied zu verstehen erfordert, über das Etikett hinauszuschauen, das sich ein Hacker selbst gibt, und zu fragen, ob die Aktivität autorisiert war, ob Nutzer einem Risiko ausgesetzt wurden und ob Bounty-Bedingungen existierten, bevor Gelder bewegt wurden.

Was ist ein Krypto-Whitehat-Hacker?

Ein Krypto-Whitehat-Hacker ist ein Sicherheitsforscher, der Schwachstellen findet und innerhalb eines autorisierten Disclosure- oder Wiederherstellungsprozesses arbeitet. Zu seinen Zielen können Smart Contracts, Bridges, Wallets, Börseninfrastruktur, Frontends, APIs, Validatorensysteme, Multisig-Setups und andere Komponenten gehören, die digitale Vermögenswerte offenlegen können.

Die meiste Whitehat-Arbeit findet vor einem Exploit statt. Ein Projekt veröffentlicht eine Krypto-Bug-Bounty mit definierten Zielen, Ausschlüssen, Schweregraden, Melderegeln und Auszahlungsgrenzen. Forscher prüfen den Code, reproduzieren eine Schwachstelle sicher, reichen Beweise privat ein und geben dem Team Zeit zur Behebung.

Der Forscher muss kein echtes Geld entnehmen, um die Existenz des Bugs zu belegen. Große Web3-Bounty-Plattformen verlangen in der Regel Proof-of-Concepts, verbieten aber Tests, die Live-Verträge, öffentliche Netzwerke, Nutzer oder Drittsysteme gefährden. Die aktuellen Whitehat-Regeln von Immunefi untersagen beispielsweise unter ihrem Standard-Rahmenwerk Tests gegen Mainnet- und öffentliche Testnet-Verträge. Plattformen wie Immunefi, Sherlock, Code4rena und Hats Finance haben diese Pipeline zu einem Standardbestandteil der Launch-Vorbereitung von Protokollen gemacht, mit kompetitiven Audits und laufenden Bounties neben traditionellen Sicherheitsüberprüfungen.

Technisches Bounty-Hunting ist daher eher adversariale Qualitätssicherung als sanktionierter Diebstahl. Forscher denken wie Angreifer, aber die Arbeit bleibt innerhalb der vom Projekt gesetzten Grenzen. Interessierte können über einen strukturierten Krypto-Bounty-Hunter-Workflow, der auf sicherem Testen, Beweisen und verantwortungsvoller Disclosure basiert, von allgemeiner Bounty-Arbeit in die Sicherheitsforschung wechseln.

Was ist ein Krypto-Blackhat-Hacker?

Ein Blackhat-Hacker nutzt ein System ohne Erlaubnis und zu einem Zweck aus, der dem Eigentümer oder den Nutzern schadet. Im Kryptobereich ist das Ziel oft der direkte finanzielle Gewinn, weil Smart Contracts, Bridges, Börsen und Wallets Vermögenswerte halten können, die innerhalb weniger Minuten nach einer erfolgreichen Kompromittierung übertragbar sind.

Blackhat-Angriffe folgen keinem einzigen technischen Muster. Ein Smart-Contract-Angreifer kann fehlerhafte Buchführung, Zugriffskontrollen, Oracle-Annahmen, Reentrancy oder einen Logikfehler ausnutzen. Andere Gruppen kompromittieren private Schlüssel, manipulieren Mitarbeiter durch Social Engineering, übernehmen Entwicklerinfrastruktur, vergiften Softwareabhängigkeiten oder greifen die Betriebssysteme rund um ein Protokoll statt dessen Verträge an.

Auf Nutzer zielende Angreifer gehen oft einen einfacheren Weg. Krypto-Wallet-Drainer können legitime Mints, Airdrops, Staking-Seiten oder Support-Portale imitieren und ein Opfer dazu bringen, eine gefährliche Transaktion zu signieren. Manche Angriffe beruhen auf bösartigen Token-Genehmigungen, die einem Angreifer die Erlaubnis geben, Vermögenswerte später zu bewegen, ohne je die Seed-Phrase zu erfahren.

Sobald die Vermögenswerte unter der Kontrolle des Angreifers sind, beginnt die zweite Phase. Gelder können auf mehrere Wallets aufgeteilt, in liquide Assets getauscht, zwischen Chains über Bridges verschoben, über dezentrale Börsen geleitet oder an Dienste gesendet werden, die die Zuordnung erschweren. Öffentliche Blockchains legen einen Großteil dieser Bewegungen offen, doch sichtbare On-Chain-Transaktionen offenbaren nicht automatisch die Person, die eine Adresse kontrolliert. Blockchain-Analysefirmen und Sicherheitsteams verfolgen diese Geldflüsse regelmäßig und haben in großen Fällen Beschlagnahmungen durch Strafverfolgungsbehörden ermöglicht – ein Grund, warum verhandelte Rückgaben ein wiederkehrendes Merkmal großer Vorfälle geworden sind.

Whitehat- vs. Blackhat-Krypto-Hacker

Die technischen Methoden können sich fast vollständig überschneiden. Ein Whitehat und ein Blackhat können denselben Buchführungsfehler bemerken und einen nahezu identischen Proof of Concept erstellen. Der Unterschied zeigt sich darin, was sie mit diesem Wissen tun dürfen und wie sie sich verhalten, sobald die Schwachstelle bestätigt ist.

Deshalb braucht ein Projekt mit starker Smart-Contract-Sicherheit weiterhin klare Disclosure-Kanäle und Vorfallverfahren. Audits können Bugs übersehen, Integrationen können sich ändern, und neue wirtschaftliche Bedingungen können Annahmen offenlegen, die beim Start des Systems harmlos waren.

Wie Whitehat-Hacker vorgehen

Whitehat-Forschung beginnt üblicherweise mit dem Umfang. Der Forscher ermittelt, welche Verträge, Domains, Apps oder Infrastrukturen berechtigt sind, und untersucht dann, wie Vermögenswerte und Berechtigungen durch das System fließen. In DeFi kann das bedeuten, Einzahlungen, Abhebungen, Liquidierungslogik, Oracle-Abhängigkeiten, Upgrade-Pfade, Admin-Rechte und contract-übergreifende Aufrufe nachzuverfolgen.

Ein vielversprechender Bug wird in einer kontrollierten Umgebung reproduziert. Der Forscher dokumentiert die Bedingungen, die zu seiner Auslösung erforderlich sind, die wahrscheinliche Auswirkung, betroffene Assets und einen sicheren Proof of Concept. Eine gute Einreichung gibt Ingenieuren genug Informationen, um das Problem zu reproduzieren, ohne dass der Forscher es an echten Nutzern demonstrieren muss.

Nach der Erstsichtung entscheidet das Projekt, ob der Bericht gültig ist, wie schwerwiegend er ist und ob er unter die Bounty-Bedingungen fällt. Die Zahlung hängt vom Programm ab. Eine kritische Schwachstelle, die ein Protokoll leeren könnte, kann weit mehr einbringen als ein Frontend-Problem mit geringer Auswirkung, während doppelte oder außerhalb des Umfangs liegende Funde nichts erhalten können. Spitzenzahlungen für kritische Berichte auf großen Plattformen haben historisch Millionen Dollar betragen, was das Ausmaß der Verluste widerspiegelt, die ein einzelner Bug verursachen kann.

Wie Blackhat-Hacker vorgehen

Auch Blackhats beginnen mit Aufklärung, aber es gibt keine vertragliche Grenze für das, was sie untersuchen können. Sie können öffentlichen Code prüfen, Governance-Upgrades beobachten, Multisig-Teilnehmer studieren, nach geleakten Zugangsdaten suchen, privilegierte Wallets überwachen, Mitarbeiteridentitäten kartieren und externe Abhängigkeiten testen, bis sie den schwächsten Punkt finden.

Einige der größten Krypto-Hacks der Geschichte stammten nicht aus exotischen Kryptografie-Fehlern. Kompromittierung privater Schlüssel, Bridge-Schwächen, Validatorkontrolle, Smart-Contract-Fehler und Versagen der operationellen Sicherheit haben alle Verluste in Höhe von Hunderten Millionen Dollar verursacht. Fälle wie die Ronin-Bridge- und Cross-River-(Euler-Finance)-Episoden folgten sehr unterschiedlichen technischen Pfaden und unterstreichen, dass die Angriffsfläche Menschen und Infrastruktur ebenso umfasst wie Code.

Die Ausführung ist normalerweise auf Geschwindigkeit ausgelegt. Sobald eine Schwachstelle ausgenutzt wird, muss ein Angreifer womöglich mehrere Verträge leeren, Sicherheiten beschlagnahmen, einen Preis-Feed manipulieren, ungedeckte Assets minten oder Gelder bewegen, bevor die Betreiber das System pausieren können. Danach steht der Angreifer vor einem anderen Problem: transparente On-Chain-Transaktionen in Assets zu verwandeln, die gehalten oder ausgegeben werden können, ohne wiedererlangt oder eingefroren zu werden.

Warum manche Whitehats zuerst hacken und eine Bounty behalten

Unter dieser Frage werden oft zwei sehr unterschiedliche Situationen vermischt.

Die erste ist eine echte Notfallrettung. Ein Exploit läuft bereits, das Protokoll hat die Intervention vorab autorisiert, und ein anderer Sicherheitsforscher bewegt gefährdete Vermögenswerte, bevor der Blackhat sie nehmen kann. Das SEAL Whitehat Safe-Harbor-Rahmenwerk existiert genau für dieses Szenario. Teilnehmende Protokolle definieren geschützte Assets, Wiederherstellungsadressen, Identitätsanforderungen und Bounty-Bedingungen, bevor ein Vorfall eintritt. Ein Whitehat kann dann während eines aktiven Exploits eingreifen und gerettete Gelder unter diesen veröffentlichten Bedingungen zurückgeben.

Manche Safe-Harbor-Konfigurationen erlauben dem Whitehat sogar, die erlaubte Bounty direkt einzubehalten, bevor er den Rest zurückgibt. Das ist nicht dasselbe, wie zuerst Geld zu nehmen und hinterher eine Belohnung zu erfinden – die Autorisierung und die Zahlungsformel existieren bereits.

Die zweite Situation beginnt mit einem nicht autorisierten Exploit. Der Angreifer entnimmt Assets, behauptet später, ein Whitehat zu sein, bietet die Rückgabe des Großteils der Gelder an und bittet darum, einen Prozentsatz behalten zu dürfen. Ein Projekt kann das Angebot annehmen, weil die Wiedererlangung von 90 % besser ist als nichts, aber eine Vereinbarung nach dem Exploit macht den ursprünglichen Angriff nicht rückwirkend zu einer autorisierten Bug-Bounty.

Die jüngste Wiederherstellung im Liquid Network zeigt, wie schwierig diese Grenze werden kann. Selbsternannte Whitehats hoben fast 4.000 BTC ab, wiesen Blockstream an, die Schwachstelle zu beheben, und gaben nach On-Chain-Verhandlungen später 3.400 BTC zurück. Etwa 598,5 BTC blieben am 8. September unter ihrer Kontrolle. Kein öffentlich bekanntes Abkommen hatte diesen Rest als genehmigte Bounty festgelegt, sodass es über die verfügbaren Fakten hinausginge, ihn als bestätigte Whitehat-Belohnung zu bezeichnen.

Sich selbst als Whitehat zu bezeichnen ist daher ohne die umgebende Autorisierung bedeutungslos. Ein echtes Rettungsrahmenwerk erfordert Unabhängigkeit vom ursprünglichen Angreifer, eine aktive Bedrohung, die Einhaltung der Regeln des Protokolls und die Rückgabe der Gelder gemäß dem vereinbarten Prozess. Den Exploit selbst einzuleiten, fällt nicht unter diesen Schutz.

Kann ein Blackhat durch die Rückgabe des Geldes ein Whitehat werden?

Die Rückgabe gestohlener Gelder kann Verluste verringern und zu einer ausgehandelten Einigung führen, ändert aber nicht automatisch die Natur des ursprünglichen Zugriffs. Ein Projekt kann nach einem Exploit eine Bounty anbieten, weil eine praktische Wiedererlangung wertvoller ist als eine langwierige Verfolgung, doch diese Vereinbarung bleibt etwas anderes als verantwortungsvolle Disclosure oder eine vorab autorisierte Rettung.

Forscher, die legale Bounty-Einnahmen anstreben, müssen diese Mehrdeutigkeit nicht schaffen. Formale Programme bieten einen Weg, Schwachstellen zu melden, den Schweregrad festzulegen und Zahlungen zu erhalten, ohne die Custody über Nutzerfonds zu übernehmen. Der Forscher wird für die Entdeckung und die Beweise bezahlt, nicht dafür, Vermögenswerte als Geisel zu halten.

Warum Krypto Whitehat-Hacker braucht

Kryptosysteme sind attraktive Ziele, weil Code direkt liquide Assets kontrollieren kann. Eine Schwachstelle in gewöhnlicher Software kann Daten offenlegen oder einen Dienst unterbrechen. Eine Schwachstelle in einer Bridge, einem Kreditmarkt oder einer Wallet kann zu einer Übertragung von Millionen Dollar werden, bevor ein menschlicher Betreiber reagieren kann.

Whitehats fügen eine dauerhafte adversariale Ebene rund um Audits und interne Sicherheitsteams hinzu. Sie testen Annahmen nach dem Launch weiter, untersuchen neue Integrationen und bringen unabhängige Forscher in Systeme, deren wirtschaftliche Anreize sich ständig ändern. Bug-Bounties machen ein Protokoll nicht allein sicher, aber sie machen es profitabler, manche Schwachstellen zu melden, statt sie auszunutzen.

Abschließendes Urteil

Whitehat- und Blackhat-Krypto-Hacker können über dieselben technischen Fähigkeiten verfüfen, denselben Code studieren und dieselbe Schwachstelle entdecken. Autorisierung und Verhalten trennen sie. Whitehats arbeiten innerhalb von Disclosure-, Bounty-, Audit- oder Rettungsregeln, die Nutzer schützen sollen. Blackhats nutzen Systeme ohne Erlaubnis aus und entscheiden danach, ob sie behalten, verschieben, lösen oder zurückgeben, was sie genommen haben.

Notfall-Rettungen durch Whitehats sind der ungewöhnliche Fall, in dem das Bewegen von Live-Geldern legitim sein kann – aber nur, wenn die Autorisierung und die Wiederherstellungsbedingungen bereits existieren. Ein Hacker, der zuerst angreift und später eine Bounty aushandelt, kann zur Wiedererlangung von Assets beitragen, doch das ist nicht dasselbe wie verantwortungsvolle Whitehat-Forschung.