Un ladrón cibernético perdió $371,000 de su botín en segundos por no ajustar un parámetro básico en Uniswap

Pero lo que parecía un golpe perfecto se desmoronó en cuestión de segundos. Horas después, el atacante intentó convertir los USDC robados a ETH en Uniswap V4. Y ahí cometió un error garrafal: no configuró ningún límite de deslizamiento (slippage) .

Un bot automatizado de extracción de valor máximo (MEV) detectó la transacción pendiente en el mempool público y ejecutó un clásico "ataque sandwich". El bot compró ETH justo antes de la orden del atacante (elevando el precio), permitió que la compra del atacante se ejecutara a ese precio inflado, y luego vendió inmediatamente sus ETH para embolsarse la diferencia .

El resultado: el bot extrajo aproximadamente $371,000 de los fondos robados, después de pagar unos 3.5 ETH en comisiones de gas para asegurar el orden de las transacciones. El atacante terminó con apenas 67 WETH (~$129,000) — una pérdida neta de más del 74% del botín .

Cómo funcionó el ataque sandwich

El ataque sandwich es una forma de explotación MEV que se aprovecha del orden en que se procesan las transacciones en una blockchain pública. Aquí los pasos que siguió el bot :

1. Monitoreo del mempool: Los bots MEV escanean constantemente el mempool público en busca de transacciones grandes con poca tolerancia al deslizamiento.
2. Front-running: El bot detecta la transacción del atacante (comprar ETH con USDC) y envía su propia orden de compra de ETH justo antes.
3. La víctima paga el pato: La transacción del atacante se ejecuta al precio más alto, recibiendo menos ETH por la misma cantidad de USDC.
4. Back-running: Inmediatamente después, el bot vende sus ETH y se beneficia de la diferencia de precio.

En este caso, el atacante usó Uniswap V4 sin establecer un límite de slippage, lo que le dio al bot un margen casi ilimitado para manipular el precio de ejecución .

Qué revela esto sobre la seguridad en DeFi

• Los bots MEV son oportunistas imparciales. No distinguen entre un trader legítimo y un criminal. Cualquier transacción visible en el mempool público con parámetros débiles es un blanco, sin importar quién la envió .
• La protección contra deslizamiento no es negociable. El atacante no puso un límite de slippage, permitiendo que el bot manipulara el precio libremente. Un límite pequeño (ej. 0.5%) habría evitado la mayor parte de la pérdida .
• La transparencia de DeFi es una espada de doble filo. El mismo mempool abierto que hace posible el comercio sin permisos también facilita que los bots se adelanten a transacciones grandes y mal configuradas .
• El phishing sigue siendo el vector de ataque más común. El robo inicial no explotó un fallo en un contrato inteligente, sino una billetera comprometida. La seguridad del lado del usuario —aprobaciones, firmas e higiene de la wallet— sigue siendo el eslabón más débil .

Lecciones clave para los usuarios

1. Siempre establece un límite de deslizamiento ajustado — generalmente entre 0.5% y 1% para intercambios grandes en pares líquidos. Nunca uses "automático" o slippage infinito .
2. Usa endpoints RPC protegidos contra MEV o servicios de mempool privado (como Flashbots Protect o BloxRoute) para mantener tus transacciones fuera del mempool público .
3. Revoca las aprobaciones de tokens que no uses periódicamente. La víctima en este caso había firmado un permiso de phishing que permitió al atacante drenar los USDC directamente .
4. Prueba los intercambios grandes con montos pequeños primero — especialmente si acabas de obtener el control de los fondos de una fuente sospechosa.
5. Entiende que la transparencia de la blockchain puede jugar en tu contra — tener las claves privadas no garantiza una ejecución segura si la transacción es visible públicamente y está mal parametrizada .

El incidente es un recordatorio brutal de que en DeFi, la sofisticación técnica importa en cada paso. Incluso los criminales pueden perder frente a adversarios mejor automatizados cuando ignoran las reglas básicas de higiene en las transacciones.