Fallstudie: eine durchgängige Untersuchung

In den vorangegangenen 41 Lektionen wurde jeweils eine Fertigkeit behandelt. Bei realen Untersuchungen kommen alle gleichzeitig zum Einsatz – unter Zeitdruck, mit unvollständigen Daten und während Leser auf Antworten warten. In diesem Fall wird ein fiktiver Exploit vom ersten Alarm bis zum Abschlussbericht verfolgt. Dabei wird bei jedem Schritt gezeigt, welche Fertigkeit zum Einsatz kommt und wie die Analystin oder der Analyst entscheidet, wie sehr den einzelnen Ergebnissen zu trauen ist. Alle Namen, Adressen, Hashes, Blockhöhen und Beträge in diesem Fall sind erfunden.

Der Hinweis und die Fragestellung

Am 14. März 2026 um 09:58 UTC stellt Corvane Finance, ein fiktives Kreditprotokoll auf Ethereum, fest, dass sein USDC-Markt geleert wurde. Das Team sendet einem unabhängigen Analyseteam den Hash der Exploit-Transaktion, 0x9c4e…a71b, und eine einzeilige Anfrage: „Verfolgen Sie das Geld.“

Die Analystin oder der Analyst formuliert daraus eine analytische Fragestellung, wie in der Lektion Von der Fragestellung zur Hypothese beschrieben:

Wohin flossen die in der Transaktion 0x9c4e…a71b abgezogenen Vermögenswerte bis zu den Stichtagsblöcken; welche Verwahrungsdienste erhielten davon etwas, und wie sicher ist jede einzelne Verbindung?

Die Abgrenzung legt die Ausgangspunkte (die Exploit-Transaktion), die Chains (Ethereum, ein Rollup, Bitcoin), den Zeitraum (Ethereum-Blöcke 24.790.112 bis 24.812.000 und der entsprechende Bitcoin-Bereich), eine Grenze von 10 Hops für Bitcoin-Peel-Chains und eine Abbruchregel bei jedem Verwahrungsdienst fest. Sie wird in die Fallakte aufgenommen, bevor die erste Abfrage ausgeführt wird.

Schritt 1: Die Exploit-Transaktion lesen

Die Analystin oder der Analyst ruft die Transaktion, ihren Beleg und ihre Traces von einem Archiv-Node ab (siehe Node-APIs und Datenzugriff) und hält den Block-Hash als Herkunftsnachweis fest. Der Status des Belegs ist 1 (Erfolg), und die dekodierten Logs zeigen, was das Protokoll verlassen hat:

{
  "transactionHash": "0x9c4e…a71b",
  "blockNumber": 24790112,
  "status": "0x1",
  "decodedLogs": [
    {"token": "USDC", "event": "Transfer", "from": "0x5Fd0…3C2a",
     "to": "0x7aE3…b19C", "value": "1912400000000"},
    {"token": "WETH", "event": "Transfer", "from": "0x5Fd0…3C2a",
     "to": "0x7aE3…b19C", "value": "210000000000000000000"}
  ]
}

0x5Fd0…3C2a ist der Corvane-USDC-Markt und 0x7aE3…b19C der Vertrag des Angreifers. Nach der Normalisierung der Einheiten (siehe Datenqualität, Normalisierung und Herkunftsnachweis): USDC hat 6 Dezimalstellen, daher entsprechen 1.912.400.000.000 1.912.400 USDC; WETH hat 18, daher entspricht der zweite Wert 210 WETH. Die Traces zeigen einen Flash Loan, eine Preismanipulation in einem dünnen Pool und die Abschöpfung – die klassische Anatomie, die in der Lektion Exploits und Hacks analysieren behandelt wird. Eine spätere Transaktion verschiebt alles vom Vertrag auf das Konto des Deployers, das extern verwaltete Konto 0xE7c1…44aD.

Dieses Konto wurde zwei Tage zuvor erstellt: Seine erste eingehende Überweisung, die es erhielt, bevor es eine Transaktion gesendet hatte (Nonce noch 0), war 1,0 ETH, die von einem Smart-Contract-Mixer abgehoben wurden. Wie die Lektion Mixer, CoinJoin und Verschleierung in Graphen erklärt, sagt diese Finanzierung fast nichts darüber aus, wer dahintersteht. Die Analystin oder der Analyst hält sie daher als Sackgasse und nicht als Hinweis fest.

Schritt 2: Token-Flüsse in SQL

Um alle Token-Bewegungen von den Adressen des Angreifers zu finden, fragt die Analystin oder der Analyst rohe Logs anhand der Event-Signatur ab, wie in der Lektion EVM-Logs und Traces abfragen:

-- ERC-20-Transfers, die vom Exploit-Vertrag oder vom Konto des Angreifers gesendet wurden
SELECT
  l.block_number,
  l.transaction_hash,
  l.contract_address               AS token,
  '0x' || SUBSTR(l.topic2, 27, 40) AS recipient,
  l.data                           AS raw_amount_hex
FROM logs l
WHERE l.block_number BETWEEN 24790112 AND 24812000
  AND l.topic0 = '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef'
  AND SUBSTR(l.topic1, 27, 40) IN ('7ae3…b19c', 'e7c1…44ad')  -- in der Praxis vollständiges Hex in Kleinbuchstaben
ORDER BY l.block_number, l.log_index;

topic0 ist der keccak-256-Hash von Transfer(address,address,uint256). topic1 und topic2 enthalten Absender und Empfänger, auf 32 Byte aufgefüllt. Daher besteht die Adresse aus den letzten 40 Hex-Zeichen, beginnend an Position 27 nach „0x“ und den 24 Auffüllnullen. Der Betrag steht in data als Hexadezimalwert; die Funktion, mit der dieser in eine Zahl umgewandelt wird, unterscheidet sich je nach Datenbank-Engine.

Die Ergebnisse zeigen drei Swaps über einen DEX-Aggregator innerhalb von 15 Minuten, bei denen 1.912.400 USDC in 731,2 ETH umgewandelt werden. Das entspricht durchschnittlich etwa 2.615 USDC pro ETH einschließlich der Preiswirkung (siehe DEX-Swaps und Liquiditätsflüsse). Die 210 WETH werden in ETH umgetauscht. Das Konto des Angreifers verfügt nun über Erlöse in Höhe von 941,2 ETH.

Schritt 3: Chains übergreifend verfolgen

Zwischen 10:31 und 11:05 UTC werden die Mittel auf drei Wege aufgeteilt (siehe Chain-übergreifende Nachverfolgung):

• 600 ETH gehen in sechs Einzahlungen von je 100 ETH an ein Chain-übergreifendes Swap-Protokoll. Jede Einzahlung enthält eine Memo mit einem Bitcoin-Ziel, bc1q…7k3f. Auf Bitcoin belaufen sich die sechs Auszahlungen des Protokolls an diese Adresse auf insgesamt 22,10 BTC. Jede enthält in einem OP_RETURN-Output den zugehörigen eingehenden Ethereum-Hash. Die Verbindung ist in den Daten auf beiden Seiten explizit festgehalten.
• 300 ETH gehen in drei Einzahlungen von je 100 ETH an eine Fast Bridge, deren Einzahlungsereignisse keinen Empfänger nennen; ein Liquiditätsanbieter zahlt auf dem Rollup aus eigenen Mitteln aus. Die Seiten lassen sich nur anhand von Betrag und Zeitpunkt miteinander verbinden. Die Abfrage der Kandidatenanzahl aus der Lektion Konfidenz, Unsicherheit und Ausdrucksweise ergibt für jede Einzahlung genau eine Auszahlung von 99,80 bis 100,00 ETH innerhalb von 20 Minuten. Alle drei gehen an 0x4B9e…07Fd und belaufen sich insgesamt auf 299,82 ETH.
• 41,2 ETH verbleiben im Konto des Angreifers und werden bis zum Stichtag nicht bewegt.

Schritt 4: Die Bitcoin-Peel-Chain und die Börsen

Von bc1q…7k3f gibt die erste Transaktion alle sechs Outputs aus und beginnt eine Peel-Chain: neun Hops, bei denen jeweils eine kleine Zahlung abgeht und ein großer Rest verbleibt. Die Analystin oder der Analyst verfolgt sie mithilfe einer rekursiven Abfrage über die Tabellen inputs und outputs (siehe UTXO-Daten abfragen):

-- Der Peel-Chain folgen: Bei jedem Hop den größeren Output als Wechselgeld beibehalten
WITH RECURSIVE chain (hop, txid, vout, value_sat) AS (
  SELECT 1, transaction_hash, output_index, value FROM outputs
  WHERE transaction_hash = 'e2d9…5a10' AND output_index = 1   -- Wechselgeld von Hop 1
  UNION ALL
  SELECT c.hop + 1, o.transaction_hash, o.output_index, o.value
  FROM chain c
  JOIN inputs i  ON i.spent_transaction_hash = c.txid
                AND i.spent_output_index = c.vout
  JOIN outputs o ON o.transaction_hash = i.transaction_hash
  WHERE c.hop < 9 AND o.value = (SELECT MAX(value) FROM outputs
                                 WHERE transaction_hash = i.transaction_hash)
)
SELECT hop, txid, value_sat / 1e8 AS value_btc FROM chain ORDER BY hop;

Im rekursiven Schritt wird jeder Wechselgeld-Output mit der Transaktion verknüpft, die ihn ausgibt. Anschließend wird der größere Output dieser Transaktion beibehalten, also der Rest einer Peel-Chain. Die Unterstützung für WITH RECURSIVE und ihre Beschränkungen unterscheiden sich je nach Datenbank-Engine. „Größter Output“ ist nur eine Faustregel. Daher prüft die Analystin oder der Analyst jeden Hop anhand der Signale aus der Lektion Heuristiken zur Erkennung von Wechselgeld: Das Wechselgeld geht stets an eine frische P2WPKH-Adresse, die zum Eingabetyp passt; die Zahlungen sind runde Beträge (0,75, 0,95, 1,00 BTC), während das Wechselgeld kein runder Betrag ist; und jede Transaktion weist dieselben Muster für Version, Gebührenrate und Locktime auf – ein konsistenter Wallet-Fingerabdruck.

Die Zeilen summieren sich auf die eingegangenen 22,10 BTC. Die Zuordnungen zu den Börsen stützen sich auf die nachfolgenden Vorgänge: Jede Einzahlungsadresse wurde später gemeinsam mit mehr als 100 weiteren Adressen in eine einzelne Hot Wallet verschoben – das Sweep-Muster, das in den Lektionen Die Heuristik gemeinsamer Eingaben zur Eigentumszuordnung und Werte über Börsen und Dienste hinweg verfolgen beschrieben wird. Die Hot Wallet der Börse K erscheint in einer von der Börse K selbst veröffentlichten Liste von Reserveadressen – eine selbst zugeordnete Kennzeichnung. Die Hot Wallet der Börse O beruht dagegen nur auf einem Tag eines Drittanbieters (siehe Zuordnung und Kennzeichnung).

Schritt 5: Hypothesen prüfen und Konfidenz angeben

Wer kontrolliert bc1q…7k3f? Die Analystin oder der Analyst erstellt eine kleine ACH-Matrix mit drei Hypothesen: der Angreifer (H1), eine Adresse des Swap-Protokolls selbst (H2) oder ein Dritter, etwa ein vom Angreifer bezahlter außerbörslicher Handelstisch (H3). Die OP_RETURN-Verweise sind mit allen drei Hypothesen vereinbar: Sie belegen, dass die Mittel dorthin geflossen sind, nicht aber, wer die Adresse kontrolliert. Zu den diagnostischen Indizien gehören die vom Angreifer gesetzte Memo (spricht gegen H2), die Tatsache, dass die Adresse zuvor keine Transaktionshistorie aufweist (spricht gegen eine langjährig genutzte Protokolladresse), und die unmittelbare Peel-Chain zu kleinen Einzahlungen bei Börsen (spricht gegen einen Handelstisch, der einen Handel über seine eigenen etablierten Wallets abwickelt). H1 bleibt bestehen; H3 beruht auf einem einzelnen Verhaltensargument. Daher wird H3 bei der Sensitivitätsprüfung als Minderheitenposition beibehalten.

Die wesentlichen Einschätzungen gemäß der ICD-203-Skala, die im Methodenteil des Berichts angegeben ist:

1. Fakt: 1.912.400 USDC und 210 WETH verließen den Corvane-Markt in Transaktion 0x9c4e…a71b, Block 24.790.112.
2. Es ist fast sicher, dass 600 ETH der Erlöse zu 22,10 BTC wurden, die an bc1q…7k3f gezahlt wurden. Die Konfidenz ist hoch: Die Verbindung ist in den Daten beider Chains festgehalten.
3. Es ist sehr wahrscheinlich, dass 2,95 BTC bei Einzahlungsadressen der Börse K eingingen. Die Konfidenz ist mittel: Die Kennzeichnung stammt von der Börse selbst, aber der Pfad stützt sich auf die Erkennung von Wechselgeld über bis zu sieben Hops.
4. Es ist wahrscheinlich, dass 1,80 BTC bei Einzahlungsadressen der Börse O eingingen. Die Konfidenz ist niedrig, da die Kennzeichnung nur eine Quelle eines Drittanbieters hat.
5. Es ist wahrscheinlich, dass der Angreifer 0x4B9e…07Fd auf dem Rollup kontrolliert. Die Konfidenz ist mittel: Es gibt drei separate Übereinstimmungen von Betrag und Zeitpunkt, jeweils mit einem einzigen Kandidaten.

Die nicht bewegten Guthaben (41,2 ETH, 299,82 ETH, 3,10 BTC und 14,248 BTC) werden als Fakten ausgewiesen, die für die Stichtagsblöcke gelten.

Schritt 6: Bericht, Visualisierungen und Offenlegung

Der Bericht folgt der Lektion Den Analysebericht verfassen: eine einseitige Zusammenfassung mit den fünf Einschätzungen, dem Untersuchungsumfang, der Methode, je einem Befund pro Einschätzung, Alternativen und Einschränkungen sowie einem Anhang mit 35 Transaktionen samt vollständigen Hashes, Blockhöhen und Block-Hashes, die per Abfrage erzeugt wurden. Gemäß Flüsse und Graphen visualisieren enthält er zwei Sankey-Diagramme – eines in ETH und eines in BTC, statt eines, das Einheiten vermischt –, ein Flussdiagramm mit gestrichelter Verbindung zur Bridge und eine Zeitleiste mit einer Spur pro Chain, die zeigt, dass die erste Einzahlung bei einer Börse weniger als fünf Stunden nach dem Exploit erfolgte.

Die Offenlegung folgt der Lektion Datenschutz, Ethik und verantwortungsvolle Offenlegung. Die Börsen K und O werden innerhalb einer Stunde über ihre Compliance-Kanäle benachrichtigt. Jede erhält ausschließlich die ihr eigenen Einzahlungsadressen, Transaktions-Hashes und Beträge sowie die Wahrscheinlichkeit und Konfidenz der Verbindung. Die Rollup-Adresse wird dem Bridge-Betreiber als wahrscheinliche, nicht als bestätigte Verbindung gemeldet. Eine nicht geclusterte Peel-Adresse lässt sich über einen Namensdienst auflösen und verweist auf etwas, das wie der Name einer Person aussieht: Sie wird aus allen gemeinsam genutzten Dokumenten herausgehalten und kommt ausschließlich in den zugriffsbeschränkten Anhang für rechtliche Verfahren. Die Analystin oder der Analyst findet außerdem zwei Forks des Corvane-Codes mit derselben anfälligen Preisorakel-Konfiguration, in denen sich noch Mittel befinden. Beide Teams werden vertraulich informiert. Die öffentliche Fassung des Berichts, in der keine Privatpersonen und keine nicht geclusterten Adressen genannt werden, wird erst veröffentlicht, nachdem sie eine Behebung bestätigt haben.

Prüfungsschwerpunkt: „Verfolgen Sie das Geld“ in eine analytische Fragestellung mit klarer Abgrenzung umwandeln; den Status eines Belegs und dekodierte Transfer-Logs lesen, Logs nach topic0 filtern, Adressen aus aufgefüllten Topics extrahieren und USDC (6 Dezimalstellen) sowie WETH (18 Dezimalstellen) normalisieren; verstehen, warum eine Memo zusammen mit einer OP_RETURN-Verbindung stärker ist als eine Übereinstimmung von Betrag und Zeitpunkt; eine Peel-Chain rekursiv verfolgen und das Wechselgeld mithilfe mehrerer Heuristiken bestätigen; Einzahlungsadressen anhand von Sweeps zuordnen und verstehen, warum eine selbst zugeordnete Kennzeichnung einem Tag eines Drittanbieters vorzuziehen ist; Wahrscheinlichkeit und Konfidenz für jede Einschätzung getrennt angeben; jede Werteinheit, einschließlich Gebühren und nicht bewegter Guthaben, abstimmen; Offenlegung auf das Notwendige beschränken, Identitäten in einem zugriffsbeschränkten Anhang aufführen und gefährdete Forks vertraulich benachrichtigen.