Binance afirma que tardó en retirar los permisos que los atacantes usaron para mover fondos de una de sus billeteras porque tuvo que preparar un procedimiento especial de firma. Las autorizaciones seguían activas en Ethereum aunque la plataforma hubiera suspendido los retiros, según su informe inicial sobre el robo del 29 de octubre, valorado por la empresa en unos 6,340 millones de dólares.
La explicación añade un detalle a la secuencia del ataque: los intrusos obtuvieron acceso al servicio que firma transacciones y otorgaron a un contrato bajo su control permisos sobre una billetera conectada a internet. Para detener esa vía, Binance necesitaba modificar también el estado de la cuenta en la cadena de bloques.

Por qué no bastó con pausar los retiros
En su informe del 3 de noviembre, Binance señaló que los atacantes aprovecharon EIP-7702, una función de Ethereum que permite a una cuenta delegar ciertas capacidades de ejecución a código de un contrato inteligente. La especificación contempla que esa delegación permanezca registrada hasta que se cambie o elimine.
En el caso descrito por la plataforma, el contrato asociado a los atacantes recibió derechos de ejecución parciales sobre una billetera. Esos permisos funcionaban al margen de la infraestructura habitual de retiros de Binance. Suspender ese servicio, por tanto, no los anulaba automáticamente.
La empresa dice que la billetera utilizaba computación multipartita, o MPC, un sistema que distribuye el proceso de firma entre varias partes. Según Binance, no había una clave privada única disponible para revocar de inmediato las autorizaciones y el equipo tuvo que desarrollar y ejecutar un procedimiento específico. La compañía no detalla en el informe cómo estaba configurado ese proceso ni cuánto tiempo consumió cada etapa.
Ese relato no demuestra que MPC sea, por sí mismo, la causa de la intrusión. La empresa sitúa el acceso anterior en una campaña contra equipos de sus ingenieros y en la posterior utilización de su servicio interno de firma. La investigación sigue abierta y Binance anunció una revisión externa de sus conclusiones.
La última transferencia y la revocación
La cronología de la plataforma empieza con la salida de 233.46 millones de XRP desde cinco billeteras entre las 20:05 y las 20:09 UTC del 29 de octubre. Después, la empresa recibió una alerta interna por movimientos de gran volumen y comenzó a investigar.
Binance indica que la última transferencia no autorizada, de 2,961.9 ether, se confirmó a las 23:56 UTC. Precisa que la operación ya había sido transmitida y permanecía pendiente antes de quedar confirmada. Esa distinción impide asumir que se inició exactamente a esa hora.
A las 00:10 UTC del 30 de octubre, la plataforma ejecutó una nueva autorización que eliminó la delegación de la billetera identificada como Binance14. Un análisis independiente de GCSA, centrado en transacciones de Ethereum, también identificó la delegación y su posterior revocación. Esa revisión no establece por sí sola la causa completa de la intrusión ni el importe finalmente recuperado.
El mecanismo de Ethereum explica una parte del episodio, no todas las salidas. Binance reportó movimientos en varias redes, incluidos activos en Bitcoin, Solana y Optimism.
Qué se ha repuesto y qué sigue pendiente
En su informe inicial, Binance calculó en unos 2,850 millones de dólares los activos congelados o interceptados. La cifra depende de la conciliación y de los precios de mercado. Inmovilizar esos fondos no significa que hayan sido devueltos a la empresa o a sus clientes.
La plataforma afirmó el 4 de noviembre que había repuesto aproximadamente el 98 % del monto afectado con recursos propios y que seguía adquiriendo el resto. Reponer los activos es distinto de recuperar las mismas criptomonedas sustraídas.
Ese día, Binance también comunicó una nueva instantánea de reservas con cobertura de 44 tokens, frente a los 10 de la anterior. La empresa dijo que esperaba tardar entre 50 y 60 horas en generar la prueba criptográfica completa para que los usuarios de los activos cubiertos pudieran verificar sus saldos. Hasta que esa prueba esté disponible, la actualización de la plataforma no equivale a esa comprobación.
