Illegale Geldbewegungen Fallstudie: LI.FI-Angriff

Illegale Geldbewegungen Fallstudie: LI.FI-Angriff

Fallstudie zu illegalen Geldflüssen: LI.FI-Angriff

Hintergrund des Falls

Am 16. Juli 2024 erlebte Li.Fi, eine plattformübergreifende Bridge und DEX-Aggregator, eine erhebliche Sicherheitslücke, die den Li.Fi Diamond Contract ausnutzte. Diverse Stablecoins und andere Vermögenswerte im Wert von rund 11,6 Millionen US-Dollar wurden von Nutzern gestohlen. Der Angreifer konnte Gelder von Nutzern abziehen, die dem angegriffenen Vertrag unendliche Genehmigungen erteilt hatten.

Die Schwachstelle lag in der Funktion depositToGasZipERC20() des GasZipFacet-Vertrags. Der GasZipFacet-Vertrag wurde fünf Tage vor dem Angriff vom LI.FI-Team bereitgestellt, um das Auftanken von Gas für Bridge-Transaktionen zu ermöglichen. Die Funktion depositToGasZipERC20() enthielt ein vom Benutzer kontrolliertes Argument _swapData, das später an den Funktionsaufruf LibSwap.swap() weitergegeben wurde. Leider enthielt LibSwap.swap einen Low-Level-Aufruf, der beliebige Funktionen mit dem vom Angreifer kontrollierten Argument _swapData angegebenen Ziel und Aufrufdaten ausführen konnte. Der Angreifer nutzte diese "Schwachstelle für beliebige Aufrufe", um unbefugte Überweisungen von Nutzern auszuführen, die dem Li.Fi Diamond Contract unendliche Genehmigungen erteilt hatten.

Analyse der Geldflüsse

Am 16. Juli 2024 leitete der Angreifer fast hundert Transaktionen ein, die die Schwachstelle für beliebige Aufrufe ausnutzten und innerhalb von 30 Minuten ungefähr 11 Millionen US-Dollar in Stablecoins (USDT, USDC, DAI) an die Adresse 0x8b3c transferierten. Fast alle abgezweigten Stablecoins wurden dann schnell gegen den nativen Ethereum-Token ETH getauscht. Zu den vom Angreifer genutzten DEXs gehörten Uniswap, Metamask Swap und andere. Beispiele für Tauschtransaktionen: 0xdf9b, 0x11d, 0xb4a4.

Ein Beispiel für den Geldfluss innerhalb einer Tauschtransaktion 0x8e27 mit Metamask Swap Spender. Der Angreifer tauschte die illegal erworbenen 333.258 USDT gegen 97,16 ETH. Alle Pools und Proxys sind mit MetaSleuth klar dargestellt.

Innerhalb von zwei Stunden nach dem Angriff wurden alle gestohlenen Vermögenswerte an nachgelagerte Adressen übertragen, die vom Angreifer kontrolliert wurden, und es verblieb nichts auf der ursprünglichen Angreiferadresse. Insgesamt gibt es 32 nachgelagerte Adressen, die direkt mit der Adresse 0x8b3c verbunden sind (d.h. eine Hop-Entfernung von der ursprünglichen Angreiferadresse). Davon erhielten 15 Adressen nur 0,1 ETH von der Angreiferadresse. Zum Stand 22. Oktober 2024 wurden die von diesen 15 Adressen gehaltenen ETH nicht transferiert. Die verbleibenden Adressen verarbeiteten den Rest der großen Mengen illegaler Gelder.

Ein Teil des Geldflusses von den Opferadressen zu den vom Angreifer kontrollierten nachgelagerten Adressen:

Nachdem die illegalen Gelder an die nachgelagerten Adressen eine Hop-Entfernung von der Adresse 0x8b3c entfernt übertragen wurden, begann der Angreifer mit der weiteren gestaffelten Bewegung der Gelder. Der Transfer- (Wasch-) Prozess dauerte fast drei Monate. Fast alle illegalen Gelder wurden schließlich an Tornado Cash (99,9%) transferiert, und ein kleiner Teil wurde an die Börse eXch zum direkten Bargeldbezug gesendet. Insgesamt 114 Transaktionen nutzte der Angreifer zur Interaktion mit dem Tornado Cash Router. Beispiele für Transaktionen, die illegale Gewinne an Tornado Cash übertrugen: 0x07de, 0xfe82, 0x6a47, 0x8ea6. Beispiele für Transaktionen, die illegale Gewinne an eXch übertrugen: 0xaa89, 0x7e65, 0x8572, 0x625c, 0x2dd2, 0xda71.

Ein Teil der Geldflüsse von Layer-2-Adressen (2 Hop-Entfernungen von der ursprünglichen Angreiferadresse 0x8b3c) zu Layer-4-Adressen:

Die erste groß angelegte Charge von Überweisungen erfolgte in der ersten Woche nach dem Angriff, zwischen dem 16. und 22. Juli. Der Angreifer transferierte rund 500.000 US-Dollar an illegalen Vermögenswerten von der Adresse 0x6a6d an Tornado Cash. Die Übertragung illegaler Gelder durch den Angreifer zeigte deutliche Merkmale: Er verlegte die Gelder zu nachgelagerten Adressen, die weit von der Angreiferadresse entfernt waren (Risikoadresse), und schleuste schrittweise einen Teil davon in Tornado Cash. In der ersten Charge erreichte der längste Übertragungspfad bis zu 20 Hops. Der Angreifer nutzte extrem tiefe Waschpfade, um die illegalen Geldflüsse zu verschleiern. Zwischen August und Oktober wurden die restlichen illegalen Gelder schrittweise in Transferchargen mit denselben Merkmalen an Tornado Cash transferiert.

Ein Beispiel für eine Transfercharge, die Gelder von der Adresse 0x8e85 (ein Hop von 0x8b3c) an den Tornado Cash Router übertrug:

Wie die Abbildung zeigt, transferierte der Angreifer zwischen dem 13. und 16. August 2024 schrittweise 206 ETH über einen 12-Hop-Pfad nach Tornado Cash. An der Adresse 0xe9f7 teilte der Angreifer 204 ETH in zwei Transaktionen auf: 100 ETH wurden an Tornado Cash gesendet, während 104 ETH an weitere Waschadressen weitergeleitet wurden. Dieses Aufteilungsmuster war während des gesamten Übertragungsprozesses konstant. Das heißt, der Angreifer verwendete eine neue, tiefere Adresse bei jeder Interaktion mit Tornado Cash.

Bekämpfungsbemühungen

Zwei Tage nach dem Angriff veröffentlichte LI.FI offiziell einen Bericht über den Vorfall und erklärte, dass sie die anfällige Vertragsfacetten auf allen Chains erfolgreich deaktiviert und weitere unbefugte Zugriffe verhindert hätten. LI.FI initiierte einen Kompensationsplan und erstattete den betroffenen Nutzern die vollen Beträge zurück. Zur Wiederbeschaffung der abgezweigten Vermögenswerte gaben sie an, weiterhin mit Strafverfolgungsbehörden und relevanten Drittparteien, einschließlich Sicherheitsteams aus der Branche, zusammenzuarbeiten, um die abgezweigten Gelder zu verfolgen und zu versuchen, sie zurückzuerlangen. Zum Stand 22. Oktober 2024 wurden fast alle illegalen Gelder an Tornado Cash transferiert, und Li.Fi hat noch keine Rückverfolgungsberichte veröffentlicht.

Einige relevante Adressen und Transaktionen

Adressen Transaktionen Illegale Geldflüsse
0x8e85eace2fa757c1d97c5ebfb8b0622e5f23c5a1 0xe237, 0x0d23 206,49 ETH
0xcb7c341dc6172b642dcf4a14015be70a27e5b31e 0x050c, 0x37d4 873.568 USDT + 36,48 ETH
0x7b93fa16c04cdcf91949d4f5f893f740992ae57e 0x57ea, 0x52ac 332,02 ETH
0x3462d2523cded523ad47c14111aa1dcbe7773675 0xc66d, 0xc0ff 120,55 ETH
0xd0be9c4c84068a9964c3781f540f703c300db268 0x0c3b, 0x1670 275,38 ETH

Der Überblick über den Geldfluss:

Mehr erfahren Sie in MetaSleuth: https://metasleuth.io/result/eth/0x14c1597cc833783ed8ac08ecc9b704b0a398201d?source=c8cd3609-0402-45eb-bb9e-2f710bd66554

Sign up for the latest updates
Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

During the week of February 9 to February 15, 2026, three blockchain security incidents were reported with total losses of ~$657K. All incidents occurred on the BNB Smart Chain and involved flawed business logic in DeFi token contracts. The primary causes included an unchecked balance withdrawal from an intermediary contract that allowed donation-based inflation of a liquidity addition targeted by a sandwich attack, a post-swap deflationary clawback that returned sold tokens to the caller while draining pool reserves to create a repeatable price-manipulation primitive, and a token transfer override that burned tokens directly from a Uniswap V2 pair's balance and force-synced reserves within the same transaction to artificially inflate the token price.

Top 10 "Awesome" Security Incidents in 2025

Top 10 "Awesome" Security Incidents in 2025

To help the community learn from what happened, BlockSec selected ten incidents that stood out most this year. These cases were chosen not only for the scale of loss, but also for the distinct techniques involved, the unexpected twists in execution, and the new or underexplored attack surfaces they revealed.

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

On August 29, 2025, Panoptic disclosed a Cantina bounty finding and confirmed that, with support from Cantina and Seal911, it executed a rescue operation on August 25 to secure roughly $400K in funds. The issue stemmed from a flaw in Panoptic’s position fingerprint calculation algorithm, which could have enabled incorrect position identification and downstream fund risk.