MEV-бот Jaredfromsubway.eth потерял свыше $7,5 млн из-за honeypot-атаки: разбор схемы и трассировка средств

21 июня один из самых активных MEV-ботов в сети Ethereum — Jaredfromsubway.eth — стал жертвой тщательно спланированной honeypot-атаки и лишился криптоактивов на сумму более $7,5 млн. Ниже — анализ механики инцидента и маршрута вывода средств, подготовленный командой Beosin. Как была устроена атака Злоумышленник развернул набор взаимосвязанных контрактов: - Coordinator Contract (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): фиксировал, находится ли текущий блок в состоянии "armed", и на финальной стадии последовательно вызывал дочерние контракты для вывода средств. - Trigger Contract (0x4de8c729a064ff6087cc84a4152969349e4feb98): в пределах одного блока формировал поддельные состояния торговых пар, чтобы арбитражные маршруты выглядели исполнимыми. - Child Contract / Fake Token Contract: маскировался под стандартный ERC20 для получения реальных approvals. - Hub Contract: выплачивал небольшую реальную прибыль, чтобы MEV-бот воспринимал сделку как выгодную. - Ring V2 Pair: поддельная торговая пара по модели Uniswap V2. - Fake Intermediate Token Contract: применялся для построения многошаговых арбитражных маршрутов (например, fCAP и fUSDC). Ключевая идея: обман через "правдоподобные" approvals По данным ончейн-анализа, атакующий собрал несколько наборов отвлекающих транзакций, где бот действительно получал небольшую прибыль, но при этом оставлял активными крупные разрешения на списание: - Large USDC: бот заработал примерно 36.997120 USDC, но оставил approval на 20 USDC. - Large USDT: бот заработал примерно 37.053440 USDT, но оставил approval на 20 USDT. - Large WETH: бот заработал примерно 0.0179 WETH, но оставил approval на 16 WETH. Мелкие сделки выглядели корректно: после выдачи разрешения дочерний контракт сразу вызывал transferFrom и забирал реальные токены — approval в рамках той же транзакции "сгорал", что снижало подозрения. В крупных сделках механизм менялся. Дочерний контракт не вызывал transferFrom для реальных токенов, а вместо этого подделывал ход операции: выпускал фейковые токены и отправлял их в пару. В результате бот считал, что prerequisites для swap выполнены, но реальный approval на списание оставался активным. На этом и держалась вся схема: маленькие операции "съедали" разрешение, большие — оставляли его. Сценарий атаки (пример с USDC) 1) Атакующий через coordinator переводил текущий блок в состояние armed. 2) Через trigger обновлял статусы нескольких поддельных Ring V2 пар. 3) MEV-бот обнаруживал "арбитраж" и исполнял сделку. Типовая последовательность внутри транзакции MEV-бота: 1) Контракт бота выдавал дочернему контракту большой allowance по USDC. 2) Бот вызывал wrapTo/wrap у дочернего контракта. 3) В состоянии armed дочерний контракт не тратил реальный USDC, а минтил фейковые токены для пары, сохраняя approval по USDC. 4) Бот продолжал свопы на поддельной паре. 5) Пара второго шага отправляла токены на адрес бота. 6) Hub выплачивал боту небольшую реальную прибыль в USDC. Пример транзакции с approval (tx hash): 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb С точки зрения бота это выглядело как успешный арбитраж с реальной прибылью в USDC, хотя критически важно, что разрешение на списание USDC оставалось у дочернего контракта. Процедуру повторили отдельно для USDC, USDT и WETH, что в итоге дало атакующему набор активных разрешений на списание. Финальный слив Транзакция атаки (hash): 0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65 Злоумышленник запустил drain loop coordinator-контракта. В calldata были указаны 66 адресов дочерних контрактов и адрес контракта MEV-бота. При наличии ранее выданных approvals дочерние контракты могли напрямую перевести соответствующие реальные токены атакующему. Итог по разрешениям: - все 20 крупных approvals по USDC были полностью использованы; - все 16 крупных approvals по WETH были полностью использованы; - по USDT частичный approval сохранялся, но баланса USDT оказалось недостаточно. Трассировка средств После инцидента адрес атакующего 0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0 получил $2.87M USDC, $2.04M USDT и 1,474 WETH. Затем стейблкоины были обменяны на ETH и распределены на четыре адреса: - 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (примерно 1,000 ETH) - 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1,001 ETH) - 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1,001 ETH) - 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1,423 ETH) Из них адрес 0xe3Da3 перевел 1,000 ETH в Tornado Cash. По трем остальным адресам дальнейших исходящих переводов не зафиксировано. Вывод Случай демонстрирует высокоуровневую тактику: вместо прямой эксплуатации кода контрактов атакующий сыграл на бизнес-логике MEV-бота, создав арбитражные сценарии, которые вынуждали бота выдавать внешне легитимные approvals. В итоге активы были списаны через ранее выданные разрешения. Для арбитражных и MEV-ботов одной оценки маршрута по симулированной доходности недостаточно, особенно когда цепочка включает незнакомые контракты, поддельные токены или кастомные обертки. Критично усиливать проверки и, в частности, рассматривать обязательный контроль изменений allowance после выполнения транзакции. См. оригинальный текст