El hackeo de Binance: cómo robaron 6.360 millones en 20 minutos

·

El hackeo de Binance: 6.360 M$ robados en unos 20 minutos en 10 blockchains

El jueves 29 de octubre, a las 20:05 UTC (las 21:05 en la España peninsular), unas carteras de Binance empezaron a vaciarse solas. Veinte minutos después habían desaparecido unos 6.360 millones de dólares repartidos en diez blockchains. Es el mayor robo de criptomonedas de la historia: multiplica por cuatro el de Bybit de febrero de 2025, que hasta ahora tenía el récord.

En este artículo repaso qué se sabe del caso, cómo funciona el truco técnico que se usó en Ethereum (EIP-7702) y qué hipótesis hay sobre cómo entraron. Los datos verificados y las hipótesis aparecen separados, porque Binance aún no ha publicado ningún análisis oficial de la causa.

Las cifras

  • Cantidad robada: unos 6.360 millones de dólares según TRM Labs, 6.400 según Chainalysis y 6.300 según Binance.
  • Duración: el grueso, en unos 20 minutos. Solo el hot wallet llamado «Binance 14» perdió unos 2.500 millones en unos tres minutos y medio.
  • Alcance: diez blockchains (Ethereum, Bitcoin, Tron, XRP Ledger, Solana, Arbitrum, Optimism, Base, Avalanche y Polygon).
  • Congelado: unos 2.700 millones a las cuatro horas, casi todo en stablecoins. Binance y Chainalysis hablaron después de 2.800 a 3.000 millones.
  • Autoría: TRM y Chainalysis lo atribuyen a TraderTraitor, un grupo de piratas informáticos de Corea del Norte.
Cronología del hackeo de Binance del 29 de octubre de 2026, en hora UTC
El atacante se preparó durante al menos 36 horas. La ejecución, en cambio, fue cuestión de minutos.

Lo que se ve en la blockchain

Lo más interesante es que no hay ningún fallo criptográfico ni ningún contrato con un agujero de seguridad. En nueve de las diez cadenas, las carteras de Binance hicieron transferencias normales y correctamente firmadas hacia direcciones del atacante. Técnicamente, la red no tenía forma de distinguirlas de una retirada legítima.

En Ethereum el atacante fue más allá y usó una función relativamente nueva, la EIP-7702, para vaciar una cartera entera, con más de 60 tokens distintos, en una sola operación.

Qué es EIP-7702, explicado fácil

En Ethereum hay dos tipos de cuentas. Las carteras normales (EOA, externally owned accounts) se controlan con una clave privada y solo hacen lo que dice cada transacción firmada. Los contratos inteligentes son programas que pueden aplicar reglas, agrupar operaciones, etc.

La EIP-7702, que llegó con la actualización Pectra de mayo de 2025, permite que una cartera normal «se vista» temporalmente con el código de un contrato. Basta con que la cartera firme una autorización que dice, más o menos: «a partir de ahora, cuando alguien me llame, ejecuta el código de esta dirección». Piensa en ello como en un poder notarial: firmas un documento para que alguien haga operaciones en tu nombre.

Cada autorización lleva un número: el nonce, el contador de transacciones de la cartera. Solo es válida si coincide con el nonce que tiene la cartera en el momento exacto de ejecutarse.

El truco de las 50 autorizaciones

«Binance 14» era un hot wallet que procesaba retiradas continuamente, así que su nonce no paraba de subir. El atacante no podía saber qué número tocaría justo cuando se ejecutara su transacción. La solución, según ha reconstruido Blockaid: llevar 50 autorizaciones firmadas para 50 nonces consecutivos (del 18.914.775 al 18.914.824) dentro de una sola transacción de tipo 4, enviada a las 20:20:59 UTC. Las otras 49 fallaron, pero le bastaba con acertar una.

La autorización buena hizo que Binance 14 delegara en un contrato «escoba» que el propio atacante había desplegado horas antes. Ese contrato tenía una función sweep() que solo podía llamar el atacante: transfería todo el ETH y todos los tokens y dejaba 1 ETH en la cartera para pagar el gas. Resultado: 167.464 ETH, 1.615 millones de USDT y 63 tokens más.

Esquema de cómo se vació el hot wallet Binance 14 con 50 autorizaciones EIP-7702

Un matiz importante: EIP-7702 no está «roto». Como dice Derek Chiang (Ethlabs), la función solo hizo el robo más rápido y eficiente. Sin ella, el atacante habría tenido que mover cada token con una transacción distinta, compitiendo con las retiradas legítimas por el siguiente nonce. Pero las 50 autorizaciones eran válidas: tenía que firmarlas la clave de Binance 14 o el sistema que firma en su nombre. Esa es la gran pregunta.

Hipótesis: ¿cómo consiguieron las firmas?

Esta parte es especulativa. Combina lo que ha dicho Binance, el análisis de las firmas que siguen la blockchain y mi propio razonamiento.

La investigación preliminar de Binance apunta al portátil comprometido de un ingeniero DevOps. Desde ese portátil, el atacante habría accedido a un contenedor de un servicio interno capaz de enviar retiradas. Binance dice que no ha encontrado ninguna prueba de que se hayan filtrado claves privadas. Su co-CEO, Richard Teng, añadió que el atacante «no usó simplemente los permisos de un ingeniero» y que no fue «una acción de un solo clic»: se han encontrado otros puntos de brecha.

Hipótesis de la cadena de ataque: portátil DevOps, contenedor interno, sistema de firma y transferencias

Hipótesis 1: control del sistema de firma (la más probable)

Es la que defiende TRM Labs: el atacante consiguió que la infraestructura que firma las transacciones de los hot wallets firmara lo que él quería, en todas las cadenas. Es la única explicación que encaja con todo: transferencias «normales» en nueve cadenas, autorizaciones EIP-7702 en Ethereum y un ritmo que solo es posible con automatización. Las autorizaciones se firmaron antes del ataque (por eso había 50 preparadas), lo que hace pensar que el atacante tuvo acceso durante horas sin que nadie se diera cuenta.

Los exchanges no guardan las claves en un fichero. Usan sistemas de firma (HSM, MPC, servicios internos) que reciben peticiones de otros servicios y las firman si cumplen unas reglas. Si el atacante controlaba un servicio que ese sistema consideraba de confianza, no le hacía falta robar ninguna clave: bastaba con pedir firmas. Encaja con lo que dice Binance: ninguna clave filtrada, pero sí acceso a un contenedor que podía enviar retiradas.

Hipótesis 2: autorizaciones obtenidas con engaño

Los primeros indicios apuntaban a un phishing de autorizaciones: alguien de dentro firma algo que cree inofensivo. El problema, como señala TRM, es que eso solo explicaría lo que pasó en Ethereum, no en las otras nueve cadenas. Además, un primer mensaje de Blockaid hablaba de una «clave robada», algo que Binance de momento desmiente.

Hipótesis 3: alguien de dentro

Siempre sale en un caso así, pero de momento no hay ninguna prueba pública de que fuera un trabajo interno. El patrón (financiación por Tornado Cash, pruebas en carteras pequeñas, ensayo general horas antes) es el de TraderTraitor en ataques anteriores.

Comparación con Bybit (febrero de 2025)

El paralelismo es evidente. En Bybit, el mismo grupo comprometió el ordenador de un desarrollador de Safe{Wallet}, el proveedor de la cartera multifirma, e inyectó JavaScript malicioso en su interfaz web. Los responsables de Bybit aprobaron lo que parecía una transferencia rutinaria, pero en realidad era una operación que cambiaba la lógica de la cartera y daba el control al atacante. Se perdieron 1.500 millones.

En ambos casos, la criptografía funcionó perfectamente. El ataque fue contra lo que hay alrededor de la firma: la estación de trabajo de un técnico y la cadena de software que decide qué se firma. En Bybit engañaron a personas; en Binance, si se confirma la hipótesis 1, engañaron a máquinas.

Qué se llevaron

Gráfico de barras: valor robado por blockchain, con Ethereum (3.790 M$) y Bitcoin (1.470 M$) en cabeza

Ethereum se lleva el 60% del botín, entre ETH y stablecoins (1.875 millones de USDT, 823 millones de USDC y 88,5 millones de RLUSD). Los 18.270 BTC se trocearon inmediatamente en bloques de 1.000 y de 100 BTC dentro del mismo bloque, una técnica clásica para dificultar el rastreo.

Una carrera contra las congelaciones

Las stablecoins tienen una particularidad que el atacante conocía: el emisor puede congelarlas. Por eso la primera fase del blanqueo fue una carrera para cambiarlas por activos que nadie puede bloquear:

  • UniswapX: vendió 325 millones de USDT a creadores de mercado a cambio de unos 122.300 ETH. Aceptó perder más de un 10% respecto al precio de mercado para ganar velocidad.
  • Aave: depositó 60 millones de USDT como garantía y pidió prestados unos 19.760 ETH, que no tiene ninguna intención de devolver. Aave congeló los mercados afectados.
  • Tron: 300 millones de USDT a JustLend y otros 200 millones a través de carteras intermedias.
  • RLUSD: vendió 48 millones en 19 minutos antes de que Ripple congelara el resto.

Tether congeló 971 millones de USDT 37 minutos después del vaciado principal, y Circle, 823 millones de USDC tres minutos más tarde. Es una ironía que da que pensar: lo que más ha limitado el robo es justamente la parte centralizada del mundo cripto. Incluso el Security Council de Arbitrum forzó la salida de 8.426 ETH y 74,6 millones de ARB de la cartera del atacante, una intervención que abrirá debate sobre hasta dónde llega la descentralización de estas redes.

Gráfico: unos 2.700 M$ congelados (42%) por Tether, Circle, Ripple y otros

Según TRM, el atacante aún controla más de 420.000 ETH y los 18.270 BTC, unos 2.400 millones de dólares. Por ahora no ha usado tantos puentes entre cadenas como después de Bybit, pero TRM prevé que la siguiente fase pasará por puentes, servicios de intercambio y brokers OTC.

Quién hay detrás

TRM Labs lo atribuye «con un alto grado de confianza» a TraderTraitor, la unidad de Corea del Norte que, según el FBI, cometió el robo de Bybit. Chainalysis llega a la misma conclusión por una prueba muy concreta: fondos robados a Binance se han mezclado con fondos del robo a Bitget del mes pasado (unos 388 millones, según el investigador ZachXBT), que ya se había atribuido a Corea del Norte. Corea del Norte siempre niega estas acusaciones.

En perspectiva

Gráfico comparativo de los mayores robos de cripto: Binance (6.360 M$) frente a Bybit (1.500 M$)

Para hacernos una idea: el robo de Binance es mayor que todos los demás de la lista juntos. Y no es la primera vez que Binance aparece: en 2019 le robaron 7.000 BTC (unos 40 millones de entonces) de un hot wallet, y en 2022 se perdieron unos 570 millones por una vulnerabilidad en el puente de su cadena BNB.

¿Y ahora qué?

  • En principio, los clientes no pierden nada. Binance asegura que cubrirá todas las pérdidas con su fondo de emergencia SAFU (unos 1.200 millones, según Fundstrat) y con fondos propios. «Vuestro dinero está seguro y cubrimos cada pérdida», ha dicho Richard Teng.
  • Retiradas: la cofundadora Yi He dijo el 30 de octubre que esperan reanudarlas «en las próximas 48 horas».
  • Informe oficial: Binance ha prometido un análisis detallado de la causa y una prueba de reservas actualizada, pero sin fecha.
  • Mercado: el bitcoin ha caído por debajo de los 78.000 dólares.

Lecciones para quien administra sistemas

No hace falta gestionar miles de millones en cripto para que este caso enseñe cosas. Esta es mi lectura:

  • El portátil de un DevOps es infraestructura crítica. Si desde una estación de trabajo se puede llegar a producción, hay que protegerla como un servidor de producción: equipos dedicados para tareas privilegiadas, sin correo ni navegación, y acceso con credenciales de corta duración.
  • Quien firma no debería fiarse de quien pide. Un sistema de firma debe tener reglas propias e independientes: destinos permitidos, límites de importe y de velocidad, y aprobación humana para todo lo que se salga de lo normal. Si un servicio interno comprometido puede hacer firmar cualquier cosa, el problema es de diseño.
  • Bloquear lo que no hace falta. Un hot wallet de retiradas no tiene ningún motivo para firmar autorizaciones EIP-7702. Una regla tan simple como «este tipo de operación no se firma nunca» habría evitado la parte de Ethereum.
  • Detectar rápido no sirve si la respuesta es lenta. Blockaid detectó el robo en menos de dos minutos. Con ataques automatizados que duran 20 minutos, hace falta un «botón rojo» automático que pare las retiradas sin esperar a una reunión.
  • Lo mínimo imprescindible en caliente. Cuanto menos saldo haya en los sistemas conectados, menos se puede perder. Vale para las carteras y también para credenciales, tokens y permisos.

Fuentes

Nota: artículo preparado con ayuda de IA (Claude). Los datos provienen de las fuentes enlazadas y las hipótesis están marcadas como tales. Es una historia en evolución: las cifras pueden cambiar cuando Binance publique su informe.