Exploits und Hacks analysieren

Wenn ein Protokoll oder eine Börse gehackt wird, stellen Analysten innerhalb weniger Stunden dieselben Fragen: Was ist passiert, wie viel wurde entwendet, wo befindet es sich jetzt und wer war dafür verantwortlich? Die Antworten ergeben sich aus einer kleinen Zahl von Transaktionen, die sehr genau untersucht werden, gefolgt von einer langen Nachverfolgung. Diese Lektion führt die Entschlüsselungsfähigkeiten des Moduls (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 Ursache dieselben Phasen, und jede Phase hinterlässt unterschiedliche Belege:

Die Phasen überschneiden sich, und bei kompromittierten Schlüsseln findet die Vorbereitung off-chain statt. Die Belege auf diese Weise zu ordnen, verhindert dennoch, dass eine Untersuchung direkt zur sichtbarsten Transaktion springt und die Finanzierung übersieht, die möglicherweise den Angreifer identifizieren könnte.

Die Angriffstransaktion untersuchen

Beginnen Sie mit dem Trace, nicht mit den Logs. Logs halten fest, was Verträge mitzuteilen beschlossen haben; der Trace zeichnet jeden Aufruf, seinen Wert und seinen Erfolg auf. Eine praktische Reihenfolge:

1. Erfassen Sie die Beteiligten: das extern verwaltete Konto, das die Transaktion gesendet hat, den Angriffskontrakt, den es aufgerufen hat, die Opferkontrakte und alle Adressen, die am Ende einen Gewinn erzielen.
2. Berechnen Sie für die gesamte Transaktion die Saldoänderungen je Adresse und Token (die Netting-Abfrage aus der Lektion DEX-Swaps und Liquiditätsflüsse eignet sich dafü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 (siehe die Lektion Kreditvergabe, Bridges und Protokollbuchhaltung), damit geliehenes Kapital nicht als Verlust gezählt wird.
4. Finden Sie den Schritt, bei dem der Zustand des Protokolls inkonsistent wurde. Das ist die Grundursache und meist ein einzelner Funktionsaufruf.

Eine Zusammenfassung der Saldoänderungen für eine fiktive Angriffstransaktion zeigt, was Schritt 2 ergibt:

{
  "tx_hash": "0x7c0d…e91a",
  "block_number": 21000417,
  "balance_changes": [
    {"address": "0xa77a…c0de", "role": "Angriffskontrakt",  "token": "DAI", "delta": "+2400000.00"},
    {"address": "0x5af3…71b2", "role": "Opferpool",          "token": "DAI", "delta": "-2401000.00"},
    {"address": "0x87f1…4e2a", "role": "Flash-Loan-Geber",   "token": "DAI", "delta": "+1000.00"},
    {"address": "0x3e9d…02f7", "role": "Sender-EOA",         "token": "ETH", "delta": "-0.041"}
  ]
}

Der Flash Loan über 2.000.000 DAI des Kreditgebers erscheint überhaupt nicht, weil er in derselben Transaktion ausgezahlt und zurückgezahlt wurde; übrig bleibt nur die Prämie von 1.000 DAI (0,05 %). Das Opfer verlor 2.401.000 DAI, der Angriffskontrakt behielt 2.400.000, und der Sender zahlte 0,041 ETH an Gas.

Der Euler-Finance-Exploit vom 13. März 2023 veranschaulicht die Methode. Veröffentlichte Analysen von Sicherheitsforschern zu einer der Angriffstransaktionen reduzieren sie auf folgende Schritte:

Angriffskontrakt, eine von mehreren Angriffstransaktionen (DAI-Pool)
  1. Flash Loan über 30.000.000 DAI von Aave
  2. 20.000.000 DAI bei Euler einzahlen           -> Sicherheiten-Token (eDAI)
  3. mint(): Eigenverschuldung                    -> 200.000.000 dDAI Schulden, 195.600.000 eDAI
  4. 10.000.000 DAI zurückzahlen                  -> 10.000.000 dDAI verbrannt
  5. mint() erneut aufrufen                       -> weitere 200.000.000 dDAI und 195.600.000 eDAI
  6. donateToReserves(100.000.000 eDAI)            -> keine Bonitätsprüfung: Konto nun zahlungsunfähig
  7. Zweiter Angriffskontrakt liquidiert den ersten mit 20 % Abschlag
  8. 38.900.000 DAI abheben, Flash Loan plus Prämie zurückzahlen, Rest behalten

Schritt 6 ist die Grundursache: Eine Funktion verringerte die Sicherheiten, ohne die Gesundheit des Kontos zu prüfen. Die Schritte 1 und 8 gleichen das geliehene Kapital aus. Über mehrere Pools hinweg nahm der Angreifer DAI, WETH, WBTC, stETH und USDC im Wert von etwa 197 Millionen US-Dollar an sich. Der Angreifer tauschte den größten Teil davon gegen ETH und DAI, schickte 100 ETH an einen Mixer, verhandelte anschließend über On-Chain-Nachrichten mit dem Protokoll und gab bis zum 3. April 2023 alle wiederherstellbaren Gelder zurück. On-Chain-Nachrichten sollten entschlüsselt werden: Es handelt sich um Text in den Eingabedaten einfacher Überweisungen, der Teil der Aufzeichnungen ist.

Finanzierung, Vorbereitung und Nachahmer

Die Finanzierung einer Angreiferadresse ist häufig der beste Ansatzpunkt für eine Zuordnung. Übliche Herkunftsquellen sind Abhebungen aus Mixern (bei Tornado-Cash-Pools kamen feste Stückelungen wie 0,1, 1, 10 und 100 ETH zum Einsatz), Bridges von einer anderen Chain, Soforttauschdienste und gelegentlich eine Abhebung von einer Börse, der mit rechtlichen Schritten nachgegangen werden kann (siehe die Lektion Wertflüsse über Börsen und Dienste nachverfolgen). Prüfen Sie außerdem:

• Den Deployer jedes Angriffskontrakts und andere von ihm bereitgestellte Verträge, einschließlich Testversionen auf anderen Chains.
• Bytecode-Ähnlichkeiten mit früheren Angriffskontrakten, 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 begann.

Nicht jede Adresse, die einen Gewinn erzielt, gehört dem ursprünglichen Angreifer. MEV-Bots kopieren profitable ausstehende Transaktionen, und manche White-Hat-Gruppen führen Angriffe durch Front-Running ab, um Gelder zu retten. Im Fall Euler behauptete eine Adresse, ihr Bot habe den ersten Angriff versehentlich kopiert. Am Ende leitete sie die DAI trotzdem an den Angreifer weiter, weil in den kopierten Vertrag die Adresse des Angreifers fest einprogrammiert war. Beim Nomad-Bridge-Vorfall im August 2022 spielten Hunderte von Adressen einfach die Transaktion des ersten Angreifers erneut ab und ersetzten dabei dessen Adresse durch ihre eigene. Kennzeichnen Sie diese Akteure getrennt und geben Sie den Grad der Sicherheit an. Veröffentlichen Sie niemals die Identität einer Privatperson allein aufgrund solcher Verbindungen (siehe die Lektion Zuordnung und Kennzeichnung).

Wenn der Fehler nicht im Code liegt

Einige der größten Diebstähle gingen ganz ohne Fehler in Smart Contracts vonstatten. Beim Diebstahl über die Ronin-Bridge im März 2022 kontrollierten Angreifer fünf der neun erforderlichen Validierungsschlüssel der Bridge – genug, um Abhebungen von etwa 173.600 ETH und 25,5 Millionen USDC zu signieren. Der Vorfall blieb sechs Tage lang unbemerkt. US-Behörden ordneten den Diebstahl im April 2022 der nordkoreanischen Lazarus Group zu. On-chain waren die Abhebungen gültig signiert; nur der Kontext (ungewöhnliche Höhe, Empfänger und Zeitpunkt) ließ den Betrug erkennen.

Der Bybit-Diebstahl vom 21. Februar 2025 in Höhe von etwa 1,5 Milliarden US-Dollar war zum Zeitpunkt des Vorfalls der größte bekannte Krypto-Diebstahl und ist ein Lehrstück darin, zu untersuchen, 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 den Rechner eines Entwicklers beim Wallet-Anbieter kompromittiert worden war. Dadurch sahen die Unterzeichner eine routinemäßige Überweisung, während ihre Hardware-Wallets etwas anderes signierten. Entschlüsselt sieht die signierte Transaktion so aus:

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

Da ein Safe-Proxy seinen Implementierungszeiger in Speicher-Slot 0 hält (siehe die Lektion Interaktionen mit Smart Contracts entschlüsseln), übergibt ein Delegatecall, der Slot 0 überschreibt, die gesamte Wallet. Die anschließenden Abflusstransaktionen bewegten etwa 401.346 ETH, 90.375 stETH, 15.000 cmETH und 8.000 mETH. Am 26. Februar 2025 ordnete das FBI den Diebstahl nordkoreanischen Akteuren zu, die es TraderTraitor nennt, veröffentlichte eine Liste von Adressen und meldete, dass die Gelder in Bitcoin umgewandelt und über Tausende von Adressen auf mehreren Chains verteilt würden. Die wichtigsten Erkenntnisse 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 Implementierungs-Slots von Proxys mit hohem Vermögenswert.

Nachverfolgung nach einem Vorfall

Die ersten Stunden entscheiden darüber, wie viel eingefroren oder markiert werden kann. Ein typischer Ablauf:

1. Erstellen Sie die Seed-Menge: alle vom Angreifer kontrollierten Adressen, die anhand der Angriffstransaktionen, der Finanzierung und der Verbindungen zum Deployer gefunden wurden.
2. Achten Sie auf einfrierbare Vermögenswerte. Manche Stablecoin-Emittenten können Guthaben einfrieren. Deshalb tauschen Angreifer diese zuerst um; melden Sie die Adressen umgehend.
3. Teilen Sie Adressen und Transaktions-Hashes über die etablierten Meldekanäle mit Börsen, Bridges und anderen Diensten, bei denen die Gelder eingehen könnten.
4. Verfolgen Sie Konsolidierung und Verteilung vorwärts, Schritt für Schritt und über Chains hinweg (siehe die Lektionen Geldflüsse vorwärts und rückwärts nachverfolgen, Chain-übergreifende Nachverfolgung und Mixer, CoinJoin und Verschleierung in Graphen).

-- Die ersten beiden Sprünge ab den Seed-Adressen eines Vorfalls, größte Geldflü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_time) 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_time >= h.first_seen
GROUP BY h.to_address, t.to_address
ORDER BY usd DESC;

Die Abfrage setzt eine value_transfers-Tabelle voraus, die native Überweisungen aus Traces bereits mit Token-Überweisungen kombiniert und jede zum Zeitpunkt der Überweisung bewertet. Die erste CTE ermittelt Adressen, die Gelder von den Seeds erhalten haben (Überweisungen zwischen Seeds ausgenommen); der letzte Schritt verfolgt für jede dieser Adressen einen weiteren Sprung und zählt nur Überweisungen nach dem ersten Eingang. Bei großen Geldflüssen zum zweiten Sprung an bekannte Dienste könnten off-chain Aufzeichnungen vorliegen.

Einen Vorfall dokumentieren

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

Bewerten Sie Verluste anhand der Preise zum Block jeder Angriffstransaktion, listen Sie jede Angriffstransaktion mit ihrer Blockhöhe auf und führen Sie zurückgewonnene Beträge getrennt vom Verlust auf. Die Lektionen Den Analysebericht verfassen und Datenschutz, Ethik und verantwortungsvolle Offenlegung behandeln, wie solche Erkenntnisse präsentiert und weitergegeben werden.

Prüfungsschwerpunkt: die fünf Phasen eines Exploits und die Belege, die jede hinterlässt; die Angriffstransaktion anhand des Traces untersuchen, Saldoänderungen berechnen und das Kapital des Flash Loans herausrechnen; die Schritte des Euler-Angriffs und seine Grundursache (donateToReserves ohne Gesundheitsprüfung); Finanzierungsquellen, Verbindungen über Deployer 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 (Seed-Menge, einfrierbare Vermögenswerte, Dienste benachrichtigen); Abfragen von Geldflüssen über kombinierte native und Token-Überweisungen; Klassen von Grundursachen und Bewertung von Verlusten anhand der Blockpreise.