Rubén Planes LlinaresPerito judicial informático

El exploit de KelpDAO explicado para abogados

Publicado por , perito judicial informático (AEPEJU nº 1556), el .

Soy coautor del análisis forense de este ataque. Aquí lo cuento sin jerga: qué falló, cómo se reconstruyó cada paso en la cadena y qué enseña a víctimas, protocolos y despachos.

Desliza

¿Qué pasó en KelpDAO?

Un atacante consiguió que el puente entre cadenas que usaba KelpDAO aceptara un mensaje que nunca se había enviado. Con ese mensaje falso, el contrato que custodiaba los tokens rsETH en Ethereum liberó 116.500 rsETH, unos 294 millones de dólares según el análisis publicado.

KelpDAO emite rsETH, un token de restaking líquido. Cuando un usuario lleva rsETH a otra red, los tokens originales quedan bloqueados en un contrato de custodia en Ethereum (el OFT Adapter) y en la red de destino circula una representación. Ese contrato solo debe liberar tokens cuando llega una orden legítima desde la otra red. El atacante fabricó esa orden.

Lo explicamos con detalle en el artículo de investigación Forensic Analysis of the KelpDAO rsETH Exploit and Cascade Effects on DeFi Lending Markets, publicado por MigaLabs, del que soy coautor.

El fallo no estaba en el código del contrato, sino en la verificación

La causa raíz fue de infraestructura y de configuración, no un error de programación. El mensaje entre cadenas lo verifica una red de verificadores (DVN) que consulta nodos de la red de origen. KelpDAO tenía configurado un único verificador: si ese verificador se equivocaba o era engañado, nada lo impedía.

Según el análisis, el atacante comprometió nodos RPC internos del proveedor del puente y, a la vez, lanzó un ataque de denegación de servicio contra los proveedores externos de respaldo. El verificador acabó consultando solo nodos manipulados, que le enseñaron un evento que no existe en la cadena real, y firmó una atestación falsa.

Para un abogado esto importa mucho: la pregunta de quién responde no se contesta mirando solo el contrato inteligente. Hay que reconstruir qué componente falló, quién lo operaba y qué configuración había elegido cada parte.

  • Hecho comprobable: el contrato de custodia liberó los tokens tras recibir una atestación firmada.
  • Hecho comprobable: el evento que esa atestación daba por enviado no existe en la cadena de origen (prueba de no existencia).
  • Inferencia razonada: los nodos que consultó el verificador estaban manipulados, porque devolvían un evento que la cadena real no contiene.
  • Lección de configuración: con varios verificadores independientes (por ejemplo, dos de tres), el mensaje falso no habría alcanzado el umbral.

Cómo se convirtió un robo de tokens en ETH

El atacante no vendió los rsETH robados en el mercado: los depositó como garantía en protocolos de préstamo y pidió prestado ETH contra ellos. Así extrajo 75.700 ETH, unos 175 millones de dólares, en un día y medio, todos enviados a una sola dirección colectora.

Usó Aave v3 y Compound v3 con el máximo porcentaje de préstamo permitido. Como el rsETH depositado ya no tenía respaldo real, esas posiciones nunca se podían liquidar con normalidad. El efecto en cadena dejó la reserva de WETH de Aave v3 al 100 % de uso: según el análisis, unos 10.800 millones de dólares de depositantes quedaron temporalmente sin poder retirarse.

Esto enseña algo útil para cualquier caso: el daño de un ataque no siempre está en el contrato atacado. Puede aparecer en terceros que aceptaban ese token como garantía, y eso abre preguntas de responsabilidad distintas.

Diagrama del flujo de fondos del exploit de KelpDAO: el distribuidor reparte 116.500 rsETH entre siete direcciones, que depositan rsETH como garantía en Aave v3 y Compound v3, piden prestado WETH y lo envían a una dirección colectora que acumula unos 75.701 ETH.
Flujo de fondos: reparto de los 116.500 rsETH entre siete direcciones, depósitos como garantía en Aave v3 y Compound v3, préstamos de WETH y envío a la dirección colectora (unos 75.701 ETH). Fuente: Forensic Analysis of the KelpDAO rsETH Exploit and Cascade Effects on DeFi Lending Markets (MigaLabs).

Cómo se siguieron los fondos hasta Bitcoin

El rastreo se hizo salto a salto, con datos públicos de la cadena y marcando en cada paso qué es un hecho registrado y qué es una inferencia. Esa separación es la que hace que un informe aguante el escrutinio de la otra parte.

La dirección colectora mantuvo los ETH quietos unos días. Después los envió a dos direcciones intermedias, que los fragmentaron en más de mil transferencias hacia un grupo de direcciones con prefijos y sufijos casi idénticos, generadas con una herramienta de direcciones personalizadas (Profanity) cuya debilidad se conoce públicamente desde hace años. Ese patrón compartido sirvió para vincular todas esas direcciones a una misma operación.

Algunas de esas cuentas usaban delegación EIP-7702, una función reciente de Ethereum que permite a una cuenta normal ejecutar el código de un contrato. Todas apuntaban al mismo contrato orquestador, que solo obedecía a una cuenta maestra concreta. Desde ahí, los fondos pasaron por THORChain, un protocolo de intercambio entre cadenas: entraron 44.126 ETH y salieron 1.329 BTC nativos repartidos en más de 30 direcciones de Bitcoin.

  • Salida del contrato de custodia hacia las direcciones del atacante.
  • Depósito como garantía y préstamo de ETH en los protocolos de préstamo.
  • Concentración de 75.700 ETH en una única dirección colectora.
  • Fragmentación en un grupo de direcciones vinculadas por un patrón común.
  • Intercambio de ETH por BTC nativo a través de THORChain y dispersión en Bitcoin.

Parte de los fondos se congeló en Arbitrum

Sí: según el comunicado público del Consejo de Seguridad de Arbitrum, se inmovilizaron unos 30.766 ETH, alrededor de 71 millones de dólares, que el atacante había llevado a esa red. Los fondos se movieron a una cuenta a la que solo se puede acceder mediante una nueva decisión de gobernanza.

Medios especializados como CoinDesk y Decrypt informaron de la congelación, y Arbitrum indicó que actuó con información de las autoridades. Es un buen ejemplo de por qué el rastreo rápido importa: los fondos que todavía están en un punto con alguien capaz de actuar (un exchange, un emisor de stablecoins o una red con gobernanza) a veces se pueden bloquear; los que ya salieron, casi nunca.

Qué enseña este caso a víctimas, protocolos y despachos

La lección principal es que un buen informe separa hechos, inferencias y límites. Ningún tribunal necesita que el perito sea categórico en todo; necesita saber qué puede comprobar cualquiera y qué se deduce con cierto grado de certeza.

Si eres víctima de un hackeo o de una estafa, lo que más ayuda es actuar pronto y conservar los hashes de las transacciones. Si eres un protocolo o una aseguradora, el valor está en la causa raíz y en el mapa de responsabilidades. Si eres un despacho, el informe te dice dónde están los fondos y a quién se puede pedir información o bloqueo.

  • Para víctimas: rastrear no es recuperar, pero sin rastreo nadie sabe a quién dirigirse. Lo explico en rastreo de criptomonedas.
  • Para protocolos y aseguradoras: la reconstrucción del ataque transacción a transacción y su causa raíz. Lo explico en peritaje de exploits DeFi.
  • Para despachos: un informe que el juzgado pueda entender, con el grado de certeza declarado en cada salto.

Preguntas frecuentes

Respuestas cortas a las dudas habituales.

¿Quién robó los fondos de KelpDAO?

No lo afirmo en el informe porque no es algo que se pueda probar solo con la cadena. Varias fuentes públicas lo atribuyen a un grupo estatal norcoreano; el análisis se limita a lo comprobable: direcciones, transacciones y patrones que vinculan la operación.

¿Se puede rastrear algo que pasa por THORChain?

Sí, con matices. Las entradas y salidas de THORChain se pueden consultar públicamente y emparejar por importes y tiempos; el informe indica en ese salto un grado de certeza menor que en una transferencia directa.

¿Qué es una prueba de no existencia?

Es demostrar que algo que se dio por ocurrido no está en la cadena. Aquí se comprobó que el evento que la atestación daba por enviado no existe en el historial real de la red de origen, lo que prueba que la orden era falsa.

¿Sirve este tipo de análisis para un caso pequeño?

Sí. La metodología es la misma para un robo de unos miles de euros: se reconstruye cada salto, se separan hechos de inferencias y se llega hasta el punto donde alguien puede identificar o bloquear. Los precios orientativos están en precios.

Cuéntame tu caso

Consulta gratuita de 30 minutos y presupuesto gratis en 24 h laborables.

No incluyas datos sensibles. Los detalles del caso se piden después por un canal seguro.

Consulta gratis WhatsApp