On June 21, Jaredfromsubway.eth, one of the most active MEV Bots on the Ethereum network, fell victim to a meticulously orchestrated "honeypot attack," resulting in the loss of over $7.5 million worth of crypto assets. The following is Beosin Security Team's analysis of this attack and tracking of the stolen fund flow.
Attack Process Analysis
Attack Contract Family
- Coordinator Contract (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): Responsible for recording whether the current block is in an 'armed' state and, in the final stage, cyclically calling sub-contracts to drain funds.
- Trigger Contract (0x4de8c729a064ff6087cc84a4152969349e4feb98): Responsible for setting the state of fake trading pairs within the same block, making the arbitrage path appear executable.
- Sub-contract / Fake Token Contract: Disguised as a normal ERC-20 token, used to obtain genuine approvals.
- Hub Contract: Responsible for paying out a small amount of real profit, making the MEV Bot believe the opportunity is profitable.
- Ring V2 Pair: Fake Uniswap v2 trading pair.
- Fake Intermediate Token Contract: Used to construct multi-hop arbitrage paths, such as fCAP, fUSDC.
The Key to the Attack: Deceiving Approvals
By analyzing on-chain transactions, the attacker constructed multiple sets of bait transactions:
- Large USDC: The bot profited about 36.997120 USDC, but left behind an approval for 20 USDC.
- Large USDT: The bot profited about 37.053440 USDT, but left behind an approval for 20 USDT.
- Large WETH: The bot profited about 0.0179 WETH, but left behind an approval for 16 WETH.
- Small transactions behaved normally, with the approval consumed within the same transaction to reduce suspicion.
In small transactions, after the bot authorized a real token allowance, the sub-contract would immediately transfer the real tokens away. The approval was consumed, appearing completely normal.
In large transactions, however, the sub-contract would not call `transferFrom` to move the real tokens. Instead, it would directly mint fake tokens via the fake trading pair. The bot thought it had completed the normal pre-swap steps, but the real token approval remained intact.
This is the core of the entire attack: small transactions normally consume approvals, while large transactions preserve them.
Attack Procedure
Taking the attack transaction targeting USDC as an example:
(1) The attacker calls the coordinator to set the current block as 'armed'.
(2) The attacker calls the trigger to update the state of multiple fake Ring V2 pairs.
(3) The MEV Bot detects the arbitrage opportunity and executes the transaction.
The internal process of the MEV Bot transaction is roughly as follows:
(1) The MEV Bot contract approves a large USDC allowance to a specific sub-contract.
(2) The MEV Bot calls the `wrapTo`/`wrap` function of the sub-contract.
(3) Because the current state is 'armed', the sub-contract does not consume real USDC. Instead, it mints fake tokens to the pair, and the USDC approval is preserved.
(4) The MEV Bot continues by calling the `swap` function on the fake pair.
(5) The second-hop pair sends the tokens to the MEV Bot.
(6) The hub contract pays a small amount of real USDC profit to the MEV Bot.
approval example
tx hash: 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb
The result seen by the MEV Bot: A successful arbitrage transaction yielding real USDC profit. However, the USDC approval was retained by the sub-contract.
This process was repeated for USDC, USDT, and WETH, ultimately accumulating numerous approvals.
The attack transaction hash is:
0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65
The attacker calls the `drain loop` function of the coordinator contract. The calldata contains 66 sub-contract addresses and the MEV Bot contract address. For any sub-contract to which the MEV Bot contract had previously left an allowance, that sub-contract could directly transfer the corresponding real tokens to the attacker.
Final Result:
- The entire 20 USDC large allowance was drained.
- The entire 16 WETH large allowance was drained.
- Part of the USDT allowance still exists, but the USDT balance is insufficient.
Fund Flow Analysis
After succeeding, the attacker's address (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0) received $2.87M USDC, $2.04M USDT, and 1,474 WETH. Subsequently, the attacker exchanged the stablecoins for ETH and transferred it to the following 4 addresses:
- 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (approx. 1,000 ETH)
- 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1,001 ETH)
- 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1,001 ETH)
- 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1,423 ETH)
Among these, 0xe3Da3 has transferred 1,000 ETH to Tornado Cash. The ETH at the other three addresses has not seen further movement. The fund flow chart is shown below:
Conclusion
This attack demonstrates a highly sophisticated method: instead of directly attacking contract code, the attacker, based on the business logic of MEV Bots, constructed corresponding arbitrage scenarios to mislead the MEV Bot into making seemingly harmless approvals, and then transferred its assets. For arbitrage bots and MEV Bots, relying solely on simulated profits to judge the safety of a route is insufficient. Especially when an arbitrage path involves unfamiliar contracts, fake tokens, or custom wrappers, caution is essential. Consider enforcing checks on allowance changes after transactions.
View Original Article
