MEV-Bot fällt Honeypot zum Opfer: Über 7,5 Mio. US-Dollar verloren – Analyse und Nachverfolgung der Gelder

Am 21. Juni ist einer der aktivsten MEV-Bots im Ethereum-Netzwerk, Jaredfromsubway.eth, Opfer eines ausgeklügelten Honeypot-Angriffs geworden. Dabei gingen Krypto-Assets im Wert von über 7,5 Mio. US-Dollar verloren. Im Folgenden: Analyse des Angriffsablaufs und Tracking der entwendeten Mittel durch das Beosin-Security-Team. Angriffsablauf: Struktur der eingesetzten Vertragsfamilie • Coordinator Contract (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): Protokolliert, ob der aktuelle Block "scharf" (armed) ist, und ruft in der Endphase iterativ Unterverträge auf, um Gelder abzuziehen. • Trigger Contract (0x4de8c729a064ff6087cc84a4152969349e4feb98): Erzeugt innerhalb desselben Blocks manipulierte Trading-Pair-Zustände, sodass Arbitrage-Routen ausführbar wirken. • Child Contract / Fake Token Contract: Gibt sich als Standard-ERC20 aus, um echte Approvals zu erhalten. • Hub Contract: Zahlt kleine reale Profite aus, damit MEV-Bots die Gelegenheit als profitabel einstufen. • Ring V2 Pair: Gefälschtes Uniswap-V2-Trading-Pair. • Fake Intermediate Token Contract: Dient dem Aufbau von Multihop-Arbitragepfaden, etwa fCAP und fUSDC. Kern des Angriffs: Täuschende Autorisierung (Approval) Onchain-Analysen zeigen, dass der Angreifer mehrere Gruppen von Ablenkungs-Transaktionen konstruierte: • Große USDC-Trades: Der Bot verdiente ca. 36,997120 USDC, ließ aber ein Approval über 20 USDC stehen. • Große USDT-Trades: Der Bot verdiente ca. 37,053440 USDT, ließ aber ein Approval über 20 USDT stehen. • Große WETH-Trades: Der Bot verdiente ca. 0,0179 WETH, ließ aber ein Approval über 16 WETH stehen. Kleinere Trades liefen "normal" ab. Dabei wurde die Autorisierung im selben Vorgang verbraucht, was den Verdacht reduzierte: Nach dem Approval transferierte der Child-Contract die echten Tokens sofort per transferFrom, sodass die Allowance aufgebraucht war. Bei großen Trades verhielt es sich anders: Der Untervertrag rief transferFrom nicht auf, um echte Tokens zu bewegen. Stattdessen wurden Vorgänge manipuliert, um Fake-Tokens zu "minten". Der Bot ging davon aus, die Voraussetzungen für einen regulären Swap erfüllt zu haben, tatsächlich blieb das Approval für den realen Tokenbestand jedoch bestehen. Genau das ist der zentrale Mechanismus: Kleine Transaktionen verbrauchen Approvals, große Transaktionen lassen sie stehen. Beispielprozess: Angriff auf USDC (1) Der Angreifer ruft den Coordinator auf und setzt den aktuellen Block auf "armed". (2) Der Angreifer ruft den Trigger auf und aktualisiert die Zustände mehrerer gefälschter Ring-V2-Paare. (3) Der MEV-Bot erkennt eine Arbitragechance und führt den Trade aus. Typischer Ablauf innerhalb einer MEV-Bot-Transaktion: (1) Der MEV-Bot-Contract genehmigt (approve) dem Child-Contract eine große USDC-Allowance. (2) Der MEV-Bot ruft die wrapTo/wrap-Funktion des Child-Contracts auf. (3) Im "armed"-Zustand verbraucht der Child-Contract keine echten USDC, sondern mintet Fake-Tokens an das Pair; das USDC-Approval bleibt erhalten. (4) Der MEV-Bot setzt den Swap auf dem gefälschten Pair fort. (5) Das Second-Hop-Pair sendet Tokens an den MEV-Bot. (6) Der Hub-Contract zahlt dem MEV-Bot einen kleinen Betrag echter USDC als Profit. Beispiel-Approval-Transaktion (Tx-Hash): 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb Aus Sicht des MEV-Bots sah dies nach einer erfolgreichen Arbitrage mit realem USDC-Gewinn aus. Das USDC-Approval blieb jedoch beim Child-Contract bestehen. Dieses Muster wurde getrennt für USDC, USDT und WETH wiederholt und führte zu einer Vielzahl nutzbarer Allowances. Abzugsphase (Drain) Angriffs-Transaktion (Tx-Hash): 0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65 Der Angreifer startet über den Coordinator eine Drain-Schleife. Die calldata enthält 66 Child-Contract-Adressen sowie die MEV-Bot-Contract-Adresse. Sobald der MEV-Bot diesen Child-Contracts zuvor eine Spending-Autorisierung erteilt hatte, können die Child-Contracts die entsprechenden echten Tokens direkt an den Angreifer transferieren. Endergebnis: • Sämtliche 20-USDC-Groß-Approvals wurden vollständig ausgeschöpft. • Sämtliche 16-WETH-Groß-Approvals wurden vollständig ausgeschöpft. • Eine teilweise USDT-Autorisierung existiert noch, der USDT-Bestand reicht dafür aber nicht aus. Analyse des Geldflusses Nach dem Angriff erhielt die Angreiferadresse 0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0 2,87 Mio. USDC, 2,04 Mio. USDT sowie 1.474 WETH. Anschließend tauschte der Angreifer die Stablecoins in ETH und verteilte die Mittel auf vier Adressen: • 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (ca. 1.000 ETH) • 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1.001 ETH) • 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1.001 ETH) • 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1.423 ETH) Von diesen Adressen hat 0xe3Da3 1.000 ETH an Tornado Cash weitergeleitet. Die übrigen drei Adressen zeigen bislang keine weiteren Abflüsse. Fazit Der Vorfall zeigt eine besonders raffinierte Vorgehensweise: Statt direkt den Contract-Code anzugreifen, nutzte der Angreifer die Geschäftslogik des MEV-Bots aus. Über gezielt konstruierte Arbitrage-Szenarien wurde der Bot dazu gebracht, scheinbar legitime Approvals zu erteilen, die später zum Abzug der Assets verwendet wurden. Für Arbitrage- und MEV-Bots reicht es nicht, Routen ausschließlich anhand simulierter Returns zu bewerten. Besonders riskant sind Pfade mit unbekannten Contracts, gefälschten Tokens oder Custom-Wrappern. Strengere Prüfungen sind erforderlich; in Betracht gezogen werden sollten verpflichtende Checks, ob sich Allowances nach einer Transaktion unerwartet verändern. Originaltext ansehen