Volver

2026/11/03

Cómo una sola firma siguió vaciando la hot wallet de Binance: la delegación EIP-7702 detrás del ataque

50 autorizaciones EIP-7702 prefirmadas, una coincidencia y una delegación que sobrevivió a la cartera vacía. Cómo funcionó y qué vigilar.

En nuestro primer artículo sobre el ataque a Binance, vimos cómo empezó el ataque según la información disponible: un portátil de DevOps comprometido y unos atacantes que llegaron a los sistemas que aprueban acciones sensibles. El análisis on-chain de la empresa de seguridad Blockaid ha mostrado desde entonces cómo funcionó la fase final en Ethereum. Se utilizó EIP-7702, una funcionalidad añadida a Ethereum en mayo de 2025, y pone de manifiesto un riesgo que muchos operadores de hot wallets todavía no han tenido en cuenta.

En resumen: una sola autorización firmada convirtió la mayor hot wallet de Ethereum de Binance en una cuenta que el atacante podía controlar. Ese control no terminó cuando la cartera quedó vacía, y tampoco habría terminado con una rotación de claves.

Puntos clave

  • El atacante incluyó 50 autorizaciones EIP-7702 prefirmadas, que cubrían 50 nonces consecutivos, en una sola transacción; exactamente una coincidió y entregó la ejecución de la cartera al contrato del atacante.
  • Una delegación EIP-7702 permanece hasta que la cuenta la sustituye o la elimina. Los depósitos que llegaron después del primer vaciado, más de 200 millones de dólares en un momento dado, se robaron sin ninguna firma nueva.
  • Rotar la clave privada no elimina una delegación, porque esta pertenece a la dirección. Solo una revocación explícita la elimina.
  • Sigue sin aclararse cómo obtuvo el atacante 50 firmas válidas. Binance afirma no haber encontrado indicios de una filtración de la clave privada.
  • Los operadores de hot wallets deben vigilar el estado de delegación, negarse a firmar autorizaciones que no pretendían emitir e incluir la revocación explícita en sus runbooks de respuesta a incidentes.

Introducción rápida a EIP-7702

EIP-7702 permite que una cuenta normal de Ethereum (una externally owned account o EOA) delegue su ejecución en un smart contract. El titular de la cuenta firma una autorización que indica la dirección de un contrato, la cadena y el nonce actual de la cuenta. Una vez procesada una transacción que contiene esa autorización, las llamadas a la cuenta ejecutan el código del contrato, como si la cuenta fuera una smart contract wallet. La funcionalidad existe por motivos legítimos, como agrupar transacciones y pagar comisiones en nombre de un usuario.

Tres detalles de la especificación son importantes en este incidente:

  • Las autorizaciones viajan en un nuevo tipo de transacción, el tipo 4 (0x04), que puede contener una lista de ellas. Cualquiera puede enviar la transacción; la autorización solo necesita una firma válida de la cuenta.
  • Cada autorización solo es válida si su nonce es igual al nonce actual de la cuenta. Si no coincide, esa autorización se omite y la transacción continúa con la siguiente.
  • La delegación es persistente. Se mantiene hasta que la cuenta firma una nueva autorización que apunta a otro sitio, o una que apunta a la dirección cero, lo que la elimina.

Cómo se tomó el control de la cartera Binance 14

La hot wallet de un exchange con mucha actividad envía transacciones constantemente, así que su nonce cambia sin parar. Un atacante que prepara una autorización firmada por adelantado no puede saber qué nonce estará vigente cuando se procese la transacción. Según el análisis de Blockaid, el atacante lo resolvió firmando un rango en lugar de un único valor.

Hora (UTC, 29 de octubre)Qué ocurrió
15:59El atacante despliega un contrato “sweeper”. No está verificado y solo la dirección operadora del atacante puede llamarlo.
20:20:59Una única transacción de tipo 4 contiene 50 autorizaciones EIP-7702, todas firmadas con la clave de la hot wallet Binance 14, para 50 nonces consecutivos. Exactamente una coincide con el nonce vigente de la cartera, que queda delegada en el sweeper.
20:24:23Una sola llamada al sweeper saca de la cartera unos 167.464 ETH, 1.615 millones de USDT y decenas de otros tokens, y deja 1 ETH para comisiones.
20:41Todavía delegada, la cartera se usa para mover unos 823 millones de USDC desde una smart account independiente que controlaba Binance 14.
21:04 a 23:56La cartera se vacía cuatro veces más a medida que llegan nuevos fondos. Solo a las 21:44 se roban más de 200 millones de dólares en depósitos nuevos sin ninguna firma nueva.
00:10 (30 de octubre)Se revoca la delegación, según la cronología de Hypernative.

El paso de USDC muestra un segundo efecto. Una cuenta delegada conserva todos los roles que tiene en otros contratos: propietario, ejecutor, spender aprobado. Quien controla su ejecución puede usarlos todos.

Por qué una cartera vacía seguía siendo peligrosa

Tras un robo, lo natural es suponer que una cartera vacía ya no tiene nada que perder y que una clave nueva pone fin al acceso del atacante. Con EIP-7702, ambas suposiciones son erróneas. La delegación está vinculada a la dirección, no al saldo ni a una copia concreta de la clave. Mientras siga activa, todo lo que se envíe a la dirección puede ser retirado por el contrato delegado, y el atacante no necesita ninguna firma más.

Eso es lo que ocurrió aquí. Siguieron llegando fondos a Binance 14 después del primer vaciado, y se volvieron a retirar. Rotar la clave no habría servido: como señala Blockaid, eliminar la delegación requiere una nueva autorización de la misma cuenta que apunte a la dirección cero. Hasta que se procese esa revocación, la dirección debe considerarse bajo control del atacante.

Consejo: Ante un incidente, revoque primero y después rote las claves y vuelva a recargar. Detenga todos los procesos automáticos que envían fondos a la dirección afectada hasta confirmar que la delegación ha desaparecido.

Qué sigue sin resolverse

Las 50 autorizaciones tenían firmas válidas de la clave de Binance 14. Hay dos explicaciones generales, y las pruebas públicas todavía no permiten decidir entre ellas:

  • La clave se filtró, y el atacante firmó las autorizaciones directamente.
  • Se abusó de la infraestructura de firma: el atacante consiguió que los propios sistemas de firma de Binance firmaran contenidos elegidos por él sin llegar a extraer la clave.

Binance ha declarado que no ha encontrado indicios de una filtración de la clave privada de la cartera, y su investigación continúa. El CEO de Blockaid dijo a Cointelegraph que la actividad parece un compromiso de la infraestructura de firma más que una clave filtrada, pero se trata de una evaluación externa preliminar. Hasta que Binance publique su post-mortem, consideramos la cuestión abierta.

Qué hacer si opera hot wallets

1. Vigile el estado de delegación

Una cuenta delegada tiene código. Con EIP-7702, su código es el indicador de delegación 0xef0100 seguido de la dirección de 20 bytes del contrato en el que delega. Una EOA normal no tiene código. Puede comprobar cualquier dirección con una llamada JSON-RPC estándar:

curl -s -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYOUR_HOT_WALLET","latest"]}' \
  https://YOUR_RPC_ENDPOINT

Un resultado 0x significa que no hay delegación. Un resultado que empieza por 0xef0100 significa que la dirección está delegada. Compruébelo para cada hot wallet en cada bloque o a intervalos cortos, y genere una alerta inmediata ante cualquier cambio que no haya planificado.

2. Supervise las transacciones de tipo 4 que afecten a sus direcciones

La transacción que delega su cartera no tiene por qué proceder de su cartera. Cualquiera puede enviarla, siempre que contenga una autorización válida firmada con su clave. Supervise las transacciones de tipo 4 cuya lista de autorizaciones contenga una firma de alguna de sus direcciones, no solo las transacciones enviadas desde ellas.

3. Mantenga un inventario de delegaciones

Para cada dirección que opere, registre si debería estar delegada y, en caso afirmativo, en qué contrato auditado. Cualquier delegación fuera de esa lista es un incidente. Si no utiliza EIP-7702, el estado esperado de todas las hot wallets es sencillo: sin código.

4. Rechace autorizaciones inesperadas en el firmante

Una autorización EIP-7702 tiene su propio formato de firma: el hash del byte 0x05 seguido del chain ID, la dirección del contrato y el nonce codificados. Los servicios de firma y las políticas de HSM pueden reconocer este formato. Si no usa delegaciones, bloquee por completo estos contenidos; si las usa, permita solo direcciones de contratos conocidas. Tenga en cuenta también que una autorización con chain ID 0 es válida en todas las cadenas.

5. Incluya la revocación explícita en su runbook de respuesta a incidentes

Documente cómo revocar una delegación para cada cartera: quién firma la autorización a la dirección cero, desde qué sistema y cómo se confirma que ha surtido efecto (el código de la dirección vuelve a ser 0x). Incluya la detención de las transferencias entrantes a la dirección afectada y practique el procedimiento antes de necesitarlo.

Consejo: La misma idea se aplica fuera del mundo cripto. Cualquier concesión que sobreviva a la credencial que la creó, como un refresh token de OAuth, un rol delegado en la nube o un token de CI/CD de larga duración, necesita su propio paso de revocación explícita en la respuesta a incidentes.

Cómo puede ayudar LOGIQ

LOGIQ ayuda a las organizaciones a revisar quién y qué puede actuar con autoridad en sus servidores Linux, cuentas en la nube y pipelines, y a crear mecanismos de supervisión y pasos de respuesta a incidentes que cubran el acceso delegado, no solo contraseñas y claves. Si desea una segunda opinión sobre sus propios controles, lea nuestro primer artículo sobre el ataque citado arriba o póngase en contacto con nosotros a través de nuestro sitio web.

Fuentes