Full Report
This is a classic horror story on MEV bots in Ethereum. Read at your own discretion (and craziness). While on Discord, the author of this post received a question on Uniswap: "is it possible to recover the LP tokens that are sent to the pair contract itself?" Initially, they thought no but it's recoverable - by anyone! When somebody calls the burn function on the Uniswap core contract, the contract measures its own LP balance and burns it. Then, the withdrawn tokens are outputted to the caller of the function. Within the contract was 12K worth of liquidity tokens just waiting for somebody to take it. This is a ticking time bomb, since anybody could burn their LP tokens and accidentally receive the funds. There is a pros and a cons to the decentralized nature of blockchain. One of these cons is that if there is a contract that can be exploited for a profit, then it will be; this is a battlefield. However, this isn't even close to how bad the mempool is, where unconfirmed/pending transactions lay. If the chain is a battle ground, the mempool is the much worse dark forest. The mempool is filled with bots that exploit the ordering of transactions currently in the mempool in order to turn a profit. This is why recovering the funds is a complicated task! If a bot sees what we're trying to do, they frontrun the swap and use their own address to receive the money instead. The name of the game here is obfuscation. We need to make the call to the contract without the bots being able to detect the pattern. Their obfuscation plan was to use two separate calls: a getter and a setter contract that will make these calls instead of a call from an EOA. This way, a simple modification to the transaction wouldn't be possible to perform. Their hope was to deploy these contracts in the same block but separate transactions. If an attacker only executed the get, then the contract would revert. The thought was that by the time the set and get had both been executed, the bot wouldn't know what hit them. When trying the recovery, the get call was rejected by Infura even with manual gas overrides. Oh gosh... this means that the set had been done and the get was getting ready to go. The transaction slipped into the next block... they got a INSUFFICIENT_LIQUIDITY_BURNED error from Uniswap, meaning that somebody had performed the call and stolen the funds. What can we take away from this? The monsters are real. Their are real generalized frontrunning bots out in the world who will steal funds. Don't get sloppy. Have a plan and execute it. Don't rely on normal infrastructure. The reason the getfailed was because it should have failed for the current blockchain state but not what they were updating it with. Or, know a private miner. Overall, an extremely scary situation that's only going to get worse over time. The mempool is the reason for this unique bug class being possible. A product called VeeDo from Starkware has created a Verifiable Deploy Function to make Ethereum applications immune to these types of attacks.
Analysis Summary
# Tool/Technique: Generalized Frontrunning (MEV Bots)
## Overview
Generalized frontrunning is a sophisticated technique used by automated arbitrage bots in the Ethereum mempool (pending transaction pool). These "predators" monitor unconfirmed transactions and attempt to identify any that would result in a profit. Upon detection, the bot copies the transaction logic, replaces the recipient's address with its own, and submits the modified transaction with a higher gas fee to ensure it is processed by miners first.
## Technical Details
- **Type**: Automated MEV (Maximal Extractable Value) Tool / Exploitation Technique
- **Platform**: Ethereum Blockchain (Mempool & Smart Contracts)
- **Capabilities**: Transaction monitoring, execution trace analysis, internal transaction replication, and gas price manipulation.
- **First Seen**: Historically active; documented in detail by "Flash Boys 2.0" (April 2019) and "Ethereum is a Dark Forest" (August 2020).
## MITRE ATT&CK Mapping
- **[TA0002 - Execution]**
- **[T1204]** - User Execution (Triggering the bot via a public mempool submission)
- **[TA0006 - Credential Access / Privilege Escalation]**
- **[T1557]** - Adversary-in-the-Middle (Mempool frontrunning)
- **[TA0040 - Impact]**
- **[T1496]** - Resource Hijacking (Stealing transaction value/MEV)
- **[T1565.001]** - Data Manipulation: Transaction Manipulation
## Functionality
### Core Capabilities
- **Mempool Sniffing**: Continuous monitoring of the broadcasted, unconfirmed transactions across the Ethereum network.
- **Transaction Simulation**: Running a "dry run" of pending transactions to see if they result in a net balance increase for the caller.
- **Address Replacement**: Automatically swapping the original sender’s address with the bot’s address in the transaction data.
- **Priority Fee Escalation**: Dynamically setting higher priority fees (gas) to ensure miners include the bot's transaction before the victim's.
### Advanced Features
- **Generalized Logic Capture**: Unlike simple arbitrage bots, generalized frontrunners do not need to understand a specific protocol (like Uniswap). They analyze the *execution trace* to see if any call—regardless of the contract—results in profit.
- **Obfuscation Bypassing**: Highly sophisticated bots can decode internal transactions and sub-calls within a complex "wrapper" contract to identify the underlying profitable action.
## Indicators of Compromise
- **File Hashes**: N/A (Blockchain-resident/Server-side scripts)
- **Network Indicators**:
- Connections to high-speed Ethereum nodes (e.g., Infura, Alchemy, or private nodes).
- Use of private RPC endpoints (e.g., Flashbots) to avoid public mempool detection.
- **Behavioral Indicators**:
- `INSUFFICIENT_LIQUIDITY_BURNED` or `Reverted` errors on legitimate transactions immediately following a successful identical transaction by a different address.
- Transactions appearing in blocks with identical input data but different `to` addresses.
## Associated Threat Actors
- **MEV Searchers**: Anonymous developers and high-frequency trading (HFT) firms specializing in decentralized finance (DeFi).
- **Dark Forest "Predators"**: Generalized bots that act as automated scavengers within the mempool.
## Detection Methods
- **Behavioral Detection**: Monitoring for "sandwich attacks" or frontrunning patterns where a bot’s transaction is ordered immediately before a victim's profitable transaction.
- **Mempool Analysis**: Identifying transactions that appear to be mutations of existing pending transactions.
## Mitigation Strategies
- **Private Transaction Relays**: Use services like Flashbots or Eden Network to send transactions directly to miners, bypassing the public mempool.
- **Obfuscation**: Using "Getter/Setter" contract patterns or multi-stage execution to hide the ultimate intent of the transaction (though this is often ineffective against generalized frontrunners).
- **Sub-calls and Checks**: Implementing `require` statements that check the `msg.sender` or specific state conditions that are only true for the intended user.
- **VDFs (Verifiable Delay Functions)**: Using cryptographic tools like StarkWare’s VeeDo to prevent exploiters from acting on information before it is finalized.
## Related Tools/Techniques
- **Sandwich Attacks**: A variant where a bot buys before and sells immediately after a user’s trade to profit from slippage.
- **Backrunning**: Placing a transaction immediately after a target transaction (e.g., to liquidate a loan).
- **Miner Extractable Value (MEV)**: The broader category of profit-seeking behaviors in blockchain transaction ordering.