This attack showcases a highly sophisticated method: the attacker does not directly target the contract code, but instead misleads the MEV Bot into making seemingly problem-free authorizations by constructing corresponding arbitrage scenarios based on the MEV Bot's business logic, ultimately transferring its assets.

Written by: Beosin

On June 21, one of the most active MEV Bots on the Ethereum network, Jaredfromsubway.eth, encountered a meticulously designed "honeypot attack," losing over $7.5 million in cryptocurrency assets. Below is the analysis from the Beosin security team regarding this attack and the tracking of the stolen funds.

Attack Process Analysis

Attack Contract Family

• Coordinator Contract (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): Responsible for recording whether the current block is in an armed state and looping calls to subcontracts to extract funds in the final phase.
• Trigger Contract (0x4de8c729a064ff6087cc84a4152969349e4feb98): Responsible for setting up a fake trading pair status within the same block, making the arbitrage path appear executable.
• Subcontract / Fake Token Contract: Disguised as a normal ERC-20 token to gain real authorizations.
• Hub Contract: Responsible for paying a small amount of real profits to make the MEV Bot perceive it as profitable.
• Ring V2 pair: A forged Uniswap v2 trading pair.
• Fake Intermediate Token Contract: Used to construct multi-hop arbitrage paths, such as fCAP, fUSDC.

Key to the Attack: Deceiving Authorizations

By analyzing on-chain transactions, the attacker constructed multiple sets of bait transactions:

• Large USDC: The bot profits about 36.997120 USDC but leaves behind an authorization of 20 USDC.
• Large USDT: The bot profits about 37.053440 USDT but leaves behind an authorization of 20 USDT.
• Large WETH: The bot profits about 0.0179 WETH but leaves behind an authorization of 16 WETH.
• Small transactions behave normally, with authorizations consumed within the same transaction to reduce suspicion.

In small transactions, after the bot authorizes the real token amount, the subcontract immediately transfers the real tokens away, and the authorizations are consumed, appearing completely normal.

In large transactions, however, the subcontract does not call transferFrom to transfer the real tokens but instead mints fake tokens directly through the forged trading pair. The bot believes it has completed the normal swap pre-step, but the authorization for the real tokens remains intact.

This is the core of the entire attack: small transactions consume authorizations normally, while large transactions retain authorizations.

Attack Process

Taking the attack transaction targeting USDC as an example:

(1) The attacker calls the coordinator to set the current block to armed.

(2) The attacker calls the trigger to update the states of multiple forged Ring V2 pairs.

(3) The MEV Bot discovers arbitrage opportunities and executes trades.

The internal process of the MEV Bot transaction is roughly as follows:

(1) The MEV Bot contract authorizes a large amount of USDC to a subcontract.

(2) The MEV Bot calls the wrapTo/wrap function of the subcontract.

(3) Since the current state is armed, the subcontract does not consume the real USDC but instead mints fake tokens to the pair, retaining the USDC authorization.

(4) The MEV Bot continues to call the swap of the forged pair.

(5) The second hop pair sends 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, acquiring real USDC profits. However, the USDC authorization was retained by the subcontract. This process executed repeatedly for USDC, USDT, and WETH, ultimately forming a large number of authorizations.

The hash of the attack transaction is:

0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65

The attacker called the drain loop of the coordinator contract, with the calldata containing 66 subcontract addresses and the MEV Bot contract address. As long as the MEV Bot contract previously left a limit authorization for the subcontract, the subcontract can directly transfer the corresponding real tokens to the attacker.

Final results:

• 20 large USDC authorizations were completely consumed.
• 16 large WETH authorizations were completely consumed.
• Some authorization amounts of USDT still exist, but the USDT balance is insufficient.

Fund Flow Analysis

After the attack, the attacker address (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0) received $2.87M USDC, $2.04M USDT, and 1,474 WETH. The attacker subsequently converted the stablecoins into ETH and transferred them to the following four addresses:

• 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (approximately 1,000 ETH)
• 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1,001 ETH)
• 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1,001 ETH)
• 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1,423 ETH)

Among them, 0xe3Da3 has transferred 1,000 ETH to Tornado Cash, while the ETH in the other three addresses has not been further transferred. The fund flow chart is shown below:

Conclusion

This attack demonstrates a highly sophisticated method: the attacker does not directly attack the contract code, but misleads the MEV Bot into making seemingly problem-free authorizations by constructing corresponding arbitrage scenarios based on the MEV Bot's business logic, ultimately transferring its assets. For arbitrage bots and MEV Bots, reliance solely on simulated profits to assess route safety is insufficient, especially when unfamiliar contracts, forged tokens, or custom wrappers exist within the arbitrage path; caution should be exercised, and consideration should be given to implementing forced checks on changes in allowance after transactions.