Más de 7,5 M$ perdidos en un ataque "honeypot" contra un bot MEV: análisis y rastreo de fondos

El 21 de junio, Jaredfromsubway.eth, uno de los bots MEV más activos en la red de Ethereum, fue víctima de un ataque "honeypot" diseñado con gran precisión y perdió más de 7,5 millones de dólares en criptoactivos. A continuación se recoge el análisis del incidente y el seguimiento de los fondos sustraídos elaborado por el equipo de seguridad de Beosin. Análisis del flujo del ataque Familia de contratos implicados - Contrato coordinador (0xb84db016324e8f2bfdd8dd9c260338aee0a8df52): registra si el bloque actual está en estado "armado" y, en la fase final, llama de forma iterativa a contratos hijo para retirar fondos. - Contrato disparador (0x4de8c729a064ff6087cc84a4152969349e4feb98): crea en el mismo bloque estados falsificados de pares de trading para que las rutas de arbitraje parezcan ejecutables. - Contrato hijo / contrato de token falso: se hace pasar por un ERC20 estándar para obtener aprobaciones reales. - Contrato hub: paga pequeñas ganancias reales para que los bots MEV perciban la oportunidad como rentable. - Ring V2 Pair: par de trading falsificado tipo Uniswap V2. - Contrato de token intermedio falso: se utiliza para construir rutas de arbitraje multisalto, como fCAP y fUSDC. Clave del ataque: autorizaciones engañosas El análisis on-chain muestra que el atacante preparó varias series de transacciones señuelo: - Operación grande con USDC: el bot obtuvo aprox. 36,997120 USDC, pero dejó autorizados 20 USDC. - Operación grande con USDT: el bot obtuvo aprox. 37,053440 USDT, pero dejó autorizados 20 USDT. - Operación grande con WETH: el bot obtuvo aprox. 0,0179 WETH, pero dejó autorizados 16 WETH. En las operaciones pequeñas, todo funcionaba con normalidad y la autorización se consumía en la misma transacción, reduciendo sospechas. En esas operaciones, tras autorizar el importe real, el contrato hijo transfería inmediatamente los tokens reales y consumía la aprobación, dando la apariencia de un swap estándar. En las operaciones grandes, el subcontrato no ejecutaba transferFrom para mover los tokens reales. En su lugar, falsificaba el flujo mintiendo tokens falsos. El bot interpretaba que había completado los requisitos previos del swap, pero la aprobación del token real quedaba intacta. Esta asimetría sostiene todo el ataque: las operaciones pequeñas consumen la autorización; las grandes la conservan. Proceso del ataque (ejemplo con USDC) 1) El atacante llama al coordinador para marcar el bloque actual como "armado". 2) Llama al disparador para actualizar el estado de varios Ring V2 Pair falsificados. 3) El bot MEV detecta una oportunidad de arbitraje y ejecuta la operación. Esquema típico observado en la transacción del bot MEV 1) El contrato del bot MEV aprueba una asignación (allowance) grande de USDC a un contrato hijo. 2) El bot MEV llama a la función wrapTo/wrap del contrato hijo. 3) Al estar el bloque "armado", el contrato hijo no consume USDC reales: acuña tokens falsos hacia el par, manteniendo la aprobación de USDC. 4) El bot continúa el swap sobre el par falsificado. 5) El par del segundo salto envía los tokens al bot. 6) El contrato hub paga al bot una pequeña cantidad de USDC reales como "beneficio". Ejemplo de transacción de aprobación (hash): 0x0121e07a916c06eea3e7daf11893f3f0b95b9e1684124545ae14c32aee6029bb Desde la perspectiva del bot MEV, se trataba de un arbitraje exitoso con ganancias reales en USDC. En realidad, la aprobación de USDC permanecía retenida en el contrato hijo. Este patrón se repitió por separado con USDC, USDT y WETH, acumulando un volumen elevado de autorizaciones. Transacción del ataque (hash): 0x2be8704f5a59b69e0b71f64aefdb99eb0e8ae9fb3926147c581910d71bcf3e65 El atacante ejecuta el bucle de drenaje del contrato coordinador. El calldata incluye 66 direcciones de contratos hijo y la dirección del contrato del bot MEV. Siempre que el bot hubiera concedido previamente autorización de gasto a esos contratos, los contratos hijo podían transferir directamente los tokens reales correspondientes al atacante. Resultado final - Se consumieron por completo las 20 grandes autorizaciones en USDC. - Se consumieron por completo las 16 grandes autorizaciones en WETH. - Todavía existía una autorización parcial en USDT, pero el saldo de USDT era insuficiente. Análisis del flujo de fondos Tras el ataque, la dirección del atacante (0x3e37f4A10d771Ba9dE44b6d301410b1BEdeA65d0) recibió 2,87 M$ en USDC, 2,04 M$ en USDT y 1.474 WETH. Posteriormente intercambió los stablecoins por ETH y los transfirió a cuatro direcciones: - 0xe3Da36E4bd1a5738fa5D6Ef4F0e4dF40bDeB5f17 (aprox. 1.000 ETH) - 0x74Dc5b93586D248D5Aec64b3586736FF0A0D0e65 (1.001 ETH) - 0xd8C125efCBc99408eC8723E9BBd81d1E8D39D845 (1.001 ETH) - 0x71d4416A7A85e08a5Fe7227Ca3B44Fc639e94e97 (1.423 ETH) De ellas, 0xe3Da3 ha enviado 1.000 ETH a Tornado Cash. Las otras tres direcciones no registran transferencias adicionales. Conclusión El caso ilustra un enfoque especialmente sofisticado: el atacante no necesitó atacar directamente el código del bot, sino que explotó su lógica operativa, construyendo escenarios de arbitraje a medida para inducir aprobaciones aparentemente legítimas y, más tarde, vaciar los activos. Para bots de arbitraje y bots MEV, basarse únicamente en retornos simulados para evaluar la seguridad de una ruta es insuficiente, sobre todo cuando intervienen contratos desconocidos, tokens falsificados o "wrappers" personalizados. Conviene reforzar la diligencia previa e incorporar comprobaciones obligatorias de cambios en allowances tras la ejecución de cada transacción.