Analyse von Exploits und Hacks

Wenn ein Protokoll oder eine Börse gehackt wird, werden Analysten innerhalb weniger Stunden dieselben Fragen gestellt: Was ist passiert, wie viel wurde entwendet, wo befindet es sich jetzt und wer war es? Die Antworten ergeben sich aus einer kleinen Anzahl von Transaktionen, die sehr detailliert ausgewertet werden, gefolgt von einer langwierigen Nachverfolgung. Diese Lektion führt die Dekodierungskenntnisse aus diesem und früheren Modulen (Token, Proxys, Swaps, Flash Loans und Bridges) zusammen und wendet sie auf öffentlich bekannte Fälle an.

Der Lebenszyklus eines Exploits in den Daten

Die meisten Vorfälle durchlaufen unabhängig von ihrer eigentlichen Ursache dieselben Phasen, und jede Phase hinterlässt andere Belege:

Die Phasen überschneiden sich, und bei Schlüsselkompromittierungen findet die Vorbereitung off-chain statt. Dennoch verhindert diese Strukturierung der Belege, dass eine Untersuchung direkt bei der auffälligsten Transaktion ansetzt und die Finanzierung übersieht, die den Angreifer identifizieren könnte.

Die Angriffstransaktion auswerten

Beginnen Sie mit dem Trace, nicht mit den Logs. Logs zeichnen auf, was die Verträge bekannt geben wollten; der Trace erfasst jeden Aufruf, dessen Wert und ob er erfolgreich war. Eine praktikable Arbeitsreihenfolge:

1. Listen Sie die Akteure auf: das extern kontrollierte Konto, das die Transaktion gesendet hat, den von ihm aufgerufenen Angriffsvertrag, die betroffenen Verträge und jede Adresse, bei der am Ende ein Gewinn verbleibt.
2. Berechnen Sie die Saldoänderungen je Adresse und Token für die gesamte Transaktion (die Saldierungsabfrage aus der Lektion DEX-Swaps, Soforttauschdienste und Liquiditätsflüsse eignet sich hierfür). Der Nettogewinn des Angreifers und der Nettoverlust des Opfers bilden den Rahmen für alles Weitere.
3. Gehen Sie den Aufrufbaum von oben durch und markieren Sie Flash Loans (unbesicherte Kredite, die zuzüglich einer Gebühr vor Ende der Transaktion zurückgezahlt werden müssen, andernfalls wird die gesamte Transaktion rückgängig gemacht), damit das geliehene Kapital nicht als Verlust gezählt wird.
4. Finden Sie den Schritt, bei dem der Zustand des Protokolls inkonsistent wurde. Dies ist die eigentliche Ursache und in der Regel ein einzelner Funktionsaufruf.

Eine Zusammenfassung der Saldoänderungen einer fiktiven Angriffstransaktion zeigt das Ergebnis von Schritt 2:

{
  "tx_hash": "0x7c0d…e91a",
  "block_number": 21000417,
  "balance_changes": [
    {"address": "0xa77a…c0de", "role": "attack contract",  "token": "DAI", "delta": "+2400000.00"},
    {"address": "0x5af3…71b2", "role": "victim pool",      "token": "DAI", "delta": "-2401000.00"},
    {"address": "0x87f1…4e2a", "role": "flash-loan lender", "token": "DAI", "delta": "+1000.00"},
    {"address": "0x3e9d…02f7", "role": "sender EOA",       "token": "ETH", "delta": "-0.041"}
  ]
}

Der Flash Loan des Kreditgebers über 2.000.000 DAI erscheint überhaupt nicht, weil er innerhalb derselben Transaktion ausgezahlt und zurückgezahlt wurde; nur seine Gebühr von 1.000 DAI (0,05 %) bleibt übrig. Das Opfer verlor 2.401.000 DAI, der Angriffsvertrag behielt 2.400.000, und der Absender zahlte 0,041 ETH an Gasgebühren.

Der Exploit gegen Euler Finance vom 13. März 2023 veranschaulicht die Methode. Veröffentlichte Analysen von Sicherheitsforschern reduzieren eine der Angriffstransaktionen auf diese Schritte:

Angriffsvertrag, eine von mehreren Angriffstransaktionen (DAI-Pool)
  1. Flash Loan über 30.000.000 DAI von Aave
  2. 20.000.000 DAI bei Euler einzahlen        -> Sicherheitentoken (eDAI)
  3. mint(): Selbsthebelung                    -> 200.000.000 dDAI Schulden, 195.600.000 eDAI
  4. 10.000.000 DAI zurückzahlen               -> 10.000.000 dDAI verbrannt
  5. Erneut mint()                            -> weitere 200.000.000 dDAI und 195.600.000 eDAI
  6. donateToReserves(100,000,000 eDAI)         -> keine Solvenzprüfung: Konto jetzt insolvent
  7. Zweiter Angriffsvertrag liquidiert den ersten mit einem Abschlag von 20 %
  8. 38.900.000 DAI abheben, Flash Loan zuzüglich Gebühr zurückzahlen, Rest behalten

Schritt 6 ist die eigentliche Ursache: eine Funktion, die die Sicherheiten reduzierte, ohne den Deckungszustand des Kontos zu prüfen. Die Schritte 1 und 8 gleichen das geliehene Kapital aus. Über mehrere Pools hinweg wiederholt, erbeutete der Angriff etwa 197 Millionen $ in DAI, WETH, WBTC, stETH und USDC. Der Angreifer tauschte den Großteil davon in ETH und DAI, sendete 100 ETH an einen Mixer, verhandelte anschließend über On-Chain-Nachrichten mit dem Protokoll und gab bis zum 3. April 2023 alle rückgewinnbaren Mittel zurück. Es lohnt sich, On-Chain-Nachrichten zu dekodieren: Sie bestehen aus Text in den Eingabedaten einfacher Überweisungen und sind Teil der Beweisdokumentation.

Finanzierung, Vorbereitung und Nachahmer

Die Finanzierung einer Angreiferadresse ist häufig der beste Ansatzpunkt für eine Zuordnung. Häufige Quellen sind Auszahlungen aus Mixern (Tornado-Cash-Pools verwendeten feste Stückelungen wie 0,1, 1, 10 und 100 ETH), Bridges von einer anderen Chain, Soforttauschdienste und gelegentlich eine Auszahlung von einer Börse, die sich auf dem Rechtsweg weiterverfolgen lässt (siehe die Lektion Nachverfolgung über Börsen und Verwahrdienste). Prüfen Sie außerdem:

• Den Bereitsteller jedes Angriffsvertrags und andere von ihm bereitgestellte Verträge, einschließlich Testversionen auf anderen Chains.
• Bytecode-Ähnlichkeiten mit früheren Angriffsverträgen, die Vorfälle miteinander verknüpfen können.
• Fehlgeschlagene Versuche vor dem erfolgreichen Angriff: Ihre Revert-Gründe zeigen, was der Angreifer getestet hat und wann er damit begonnen hat.

Nicht jede Adresse, die einen Gewinn erzielt, gehört dem ursprünglichen Angreifer. MEV-Bots kopieren profitable ausstehende Transaktionen, und manche White-Hat-Gruppen kommen Angriffen durch Front-Running zuvor, um Mittel zu retten. Im Euler-Fall leitete eine Adresse, deren Betreiber behauptete, sein Bot habe den ersten Angriff versehentlich kopiert, die DAI letztlich dennoch an den Angreifer weiter, weil dessen Adresse im kopierten Vertrag fest einprogrammiert war. Beim Vorfall mit der Nomad-Bridge im August 2022 wiederholten Hunderte von Adressen einfach die Transaktion des ersten Angreifers und setzten dabei ihre eigene Adresse ein. Kennzeichnen Sie diese Akteure getrennt und mit Angabe des Konfidenzgrads, und veröffentlichen Sie niemals allein aufgrund solcher Verknüpfungen die Identität einer Privatperson (siehe die Lektion Von der Adresse über die Entität zur Person: Zuordnung und Kennzeichnung).

Wenn der Fehler nicht im Code liegt

Einige der größten Diebstähle beruhten überhaupt nicht auf einer Schwachstelle in einem Smart Contract. Beim Diebstahl über die Ronin-Bridge im März 2022 kontrollierten die Angreifer fünf der neun von der Bridge benötigten Validator-Schlüssel. Das reichte aus, um Auszahlungen von etwa 173.600 ETH und 25,5 Millionen USDC zu signieren; der Diebstahl blieb sechs Tage lang unbemerkt. US-Behörden schrieben ihn im April 2022 der nordkoreanischen Lazarus Group zu. On-chain waren die Auszahlungen gültig signiert; nur der Kontext (ungewöhnlicher Umfang, Empfänger und Zeitpunkt) ließ sie auffallen.

Der Bybit-Diebstahl vom 21. Februar 2025 mit einem Umfang von etwa 1,5 Milliarden $ war zum damaligen Zeitpunkt der größte dokumentierte Kryptodiebstahl und verdeutlicht, wie wichtig es ist, zu prüfen, was Unterzeichner tatsächlich genehmigt haben. Die Cold Wallet der Börse war ein Safe-Multisig-Proxy. Die Ermittler stellten fest, dass die Wallet-Oberfläche über einen Entwicklerrechner beim Wallet-Anbieter kompromittiert worden war, sodass die Unterzeichner eine routinemäßige Überweisung sahen, während ihre Hardware-Wallets etwas anderes signierten. Dekodiert sieht die signierte Transaktion so aus:

SafeProxy.execTransaction(...)                   -- Selektor 0x6a761202, drei gültige Signaturen
    to        = Angreifervertrag
    data      = transfer(...)                    -- harmlos wirkender Funktionsname
    operation = 1                                -- DELEGATECALL, nicht CALL
  DELEGATECALL Angreifervertrag.transfer(...)    -- wird mit dem Speicher des Proxys ausgeführt
    SSTORE slot 0 := bösartige Implementierung   -- Safe-Singleton-Zeiger ersetzt
Danach: sweepETH(...) und sweepERC20(...) auf dem Proxy aufgerufen, keine Signaturen erforderlich

Da ein Safe-Proxy seinen Implementierungszeiger im Speicher-Slot 0 ablegt (siehe die Lektion Interaktionen mit Smart Contracts dekodieren), übergibt ein Delegatecall, der Slot 0 überschreibt, die Kontrolle über die gesamte Wallet. Die anschließenden Entleerungstransaktionen bewegten etwa 401.346 ETH, 90.375 stETH, 15.000 cmETH und 8.000 mETH. Am 26. Februar 2025 schrieb das FBI den Diebstahl nordkoreanischen Akteuren zu, die es als TraderTraitor bezeichnet, veröffentlichte eine Adressliste und berichtete, dass die Mittel in Bitcoin umgewandelt und auf Tausende von Adressen auf mehreren Chains verteilt würden. Die Schlussfolgerungen für Analysten: Dekodieren Sie jedes operation-Feld in Multisig-Transaktionen, lösen Sie bei jedem Delegatecall an einen unbekannten Vertrag einen Alarm aus und überwachen Sie die Implementierungs-Slots von Proxys mit hohen Vermögenswerten.

Nachverfolgung nach dem Vorfall

Die ersten Stunden entscheiden darüber, wie viel eingefroren oder markiert werden kann. Eine typische Abfolge:

1. Erstellen Sie die Ausgangsadressmenge: alle vom Angreifer kontrollierten Adressen, die Sie anhand der Angriffstransaktionen, der Finanzierung und der Verknüpfungen zu Bereitstellern ermittelt haben.
2. Achten Sie auf einfrierbare Vermögenswerte. Manche Stablecoin-Emittenten können Guthaben einfrieren, weshalb Angreifer diese zuerst tauschen; melden Sie die Adressen schnell.
3. Teilen Sie Adressen und Transaktionshashes über die etablierten Meldekanäle mit Börsen, Bridges und anderen Diensten, die die Mittel möglicherweise erhalten.
4. Verfolgen Sie Konsolidierung und Verteilung Schritt für Schritt über Chains hinweg vorwärts (siehe die Lektionen Nachverfolgung nach beweissichernden Standards, Chain-Hopping und chainübergreifende Nachverfolgung und Mixer mit Verwahrung).

-- Erste zwei Weiterleitungsschritte von den Ausgangsadressen eines Vorfalls, größte Flüsse zuerst
WITH seeds AS (
  SELECT address FROM incident_addresses WHERE incident_id = 'INC-0142'
), hop1 AS (
  SELECT t.to_address, SUM(t.amount_usd) AS usd, MIN(t.block_timestamp) AS first_seen
  FROM value_transfers t JOIN seeds s ON t.from_address = s.address
  WHERE t.to_address NOT IN (SELECT address FROM seeds)
  GROUP BY t.to_address
)
SELECT h.to_address AS hop1, t.to_address AS hop2, SUM(t.amount_usd) AS usd
FROM hop1 h
JOIN value_transfers t
  ON t.from_address = h.to_address AND t.block_timestamp >= h.first_seen
GROUP BY h.to_address, t.to_address
ORDER BY usd DESC;

Die Abfrage setzt eine Tabelle value_transfers voraus, die native Überweisungen aus Traces bereits mit Token-Überweisungen zusammenführt, jeweils zum Zeitpunkt der Überweisung bewertet. Der erste CTE ermittelt Adressen, die Mittel aus der Ausgangsadressmenge erhalten haben (unter Ausschluss von Bewegungen zwischen Ausgangsadressen); der letzte Schritt verfolgt jede dieser Adressen einen weiteren Weiterleitungsschritt und zählt dabei nur Überweisungen nach dem ersten Eingang. Große Flüsse im zweiten Weiterleitungsschritt zu bekannten Diensten weisen auf Stellen hin, an denen Off-Chain-Aufzeichnungen vorhanden sein könnten.

Einen Vorfall dokumentieren

Klassifizieren Sie die eigentliche Ursache, denn sie bestimmt, welche Belege relevant sind:

Bewerten Sie Verluste zu den Preisen im Block der jeweiligen Angriffstransaktion, listen Sie jede Angriffstransaktion mit Blockhöhe auf und weisen Sie zurückgewonnene Beträge getrennt vom Verlust aus. Die Lektionen Den forensischen Bericht verfassen: Konfidenz und Sprache und Ethik, Privatsphäre, Datenschutz und Sicherheit der Ermittler behandeln die Darstellung und Weitergabe solcher Erkenntnisse.

Prüfungsschwerpunkt: die fünf Phasen eines Exploits und die jeweiligen Belege; Auswertung der Angriffstransaktion anhand des Traces, Berechnung von Saldoänderungen und Herausrechnen des Flash-Loan-Kapitals; die Angriffsschritte bei Euler und die eigentliche Ursache (donateToReserves ohne Prüfung des Deckungszustands); Finanzierungsquellen, Verknüpfungen über Bereitsteller und Bytecode, fehlgeschlagene Versuche und Nachahmer als Ansatzpunkte für die Zuordnung; Schlüssel- und Oberflächenkompromittierungen (Ronin, Bybit) und der Safe-Delegatecall, der Slot 0 überschrieb; Prioritäten in den ersten Stunden (Ausgangsadressmenge, einfrierbare Vermögenswerte, Benachrichtigung von Diensten); Abfragen zu Weiterleitungsschritten über zusammengeführte native Überweisungen und Token-Überweisungen; Ursachenklassen und Verlustbewertung zu Blockpreisen.