El artículo original es de la empresa de seguridad Web3 blockaid
Compilado por Expressman@Odaily Planet Daily
Resumen del incidente
El 29 de octubre de 2026, según estadísticas públicas, las carteras calientes de Binance en seis cadenas—Ethereum, Arbitrum, Avalanche, Optimism, Bitcoin y Tron—fueron robadas de al menos 5.5 mil millones de dólares, el mayor robo de criptomonedas registrado públicamente. El ataque se centró en Binance 14 (Binance 14)—una de las carteras calientes más grandes y activas de Binance en Ethereum.
A partir de las 20:24 UTC, el atacante primero vació Binance 14 con una transacción de aproximadamente 2.5 mil millones de dólares. Solo minutos antes, una autorización EIP-7702 firmada con una copia de la clave privada de la cartera dirigió la delegación de la cartera a un contrato sweeper desplegado por el atacante. Dentro de los 12 minutos posteriores al primer barrido, otras 10 carteras calientes de Binance en cuatro cadenas enviaron fondos a la misma dirección; posteriormente, el atacante utilizó Binance 14, que seguía delegada, para vaciar una cuenta inteligente bajo el nombre de Binance. Binance dijo que está investigando y no ha confirmado si los fondos de los usuarios se vieron afectados. Hasta ahora, los barridos suman 5.5 mil millones de dólares, y el exploit sigue en curso.
La detección de Blockaid marcó el barrido dentro de los dos minutos posteriores a su ocurrencia, antes de cualquier informe público, y el análisis automatizado confirmó la filtración de la clave privada y el mecanismo de delegación en 11 minutos. En una hora, Blockaid marcó las direcciones del atacante como maliciosas en su red, notificó a todos los clientes del incidente a través del Ecosystem Incidents Feed y rastreó todo el proceso de dispersión, intercambio y uso de los fondos como colateral para préstamos. Tether y Circle congelaron aproximadamente 1.8 mil millones de dólares en la dirección receptora principal; Tether declaró posteriormente que el total de USDT que congeló superó los 1.5 mil millones de dólares. ETH, AVAX, OP y ARB que no pudieron congelarse permanecen en manos del atacante.
Este informe cubre el proceso de preparación del atacante, la delegación y el barrido mediante EIP-7702, la firma paralela de claves privadas en cuatro cadenas, las rutas de lavado de dinero y la congelación. Está escrito para exchanges, custodios e instituciones financieras que mantienen claves de firma a escala, señalando los dos puntos de control que determinan el éxito o fracaso de este tipo de ataques: la aplicación de políticas antes de que se produzcan las firmas, y el monitoreo continuo después de que los fondos comienzan a moverse.
Antecedentes: carteras calientes, claves de firma y delegación EIP-7702
Las carteras calientes de los exchanges son cuentas en línea utilizadas por los exchanges para procesar retiros de clientes y transferir fondos entre sus propias carteras. Mantienen grandes cantidades de capital de trabajo, firman continuamente, a menudo firmando miles de transferencias al día; y las claves privadas detrás de estas firmas son la única línea de defensa entre el saldo y cualquiera que tenga una copia de la clave privada. En Ethereum y otras cadenas EVM, dichas carteras han sido históricamente cuentas de propiedad externa (EOA)—direcciones ordinarias sin código, donde una sola firma válida puede mover fondos, y nada más se verifica en la cadena.
EIP-7702 permite que una EOA ejecute código de contrato inteligente. La cuenta firma una autorización que especifica un contrato; una vez que una transacción de tipo 4 empaqueta esta autorización en un bloque, cualquier llamada a esa cuenta ejecutará la lógica de ese contrato con acceso completo al saldo de la cuenta. La autorización está vinculada al nonce de la cuenta, y la delegación permanece efectiva hasta que la cuenta firme una nueva autorización para reemplazarla o borrarla. Para las carteras minoristas, esto permite transacciones por lotes y patrocinio de gas; para las carteras calientes, una sola firma filtrada que aterrice en el nonce correcto equivale a entregar el control continuo a nivel de código de la cuenta al atacante, incluido cada depósito posterior.
Blockaid verificó 4 incidentes de EIP-7702 en el primer semestre de 2026, que involucraron un total de aproximadamente 1.08 millones de dólares, cada uno abusando de un aspecto diferente de la delegación; su "H1 2026 Onchain Security Report" predijo que el primer caso de siete cifras aparecería antes de fin de año. Este incidente es el cumplimiento de esa predicción, y tres órdenes de magnitud superior a lo previsto.
La ruta de transferencia directa es más antigua y sencilla: una clave privada robada firma transferencias ordinarias, que en una billetera que envía miles de retiros al día parecen rutinarias hasta que el destinatario, el monto y el momento se examinan en conjunto. Ambas rutas descansan en última instancia en claves privadas, y por eso la detección de este tipo de ataque depende de características de comportamiento, no de patrones de firma conocidos ni de vulnerabilidades de contratos.
El proceso completo del exploit
Todas las horas a continuación corresponden al 29 de octubre de 2026 UTC; el incidente seguía en evolución en el momento de la publicación.
1. Preparación
La dirección del operador 0x7C8601d4645b93cea45F71e118A729332e6B5CA0 fue financiada mediante tres retiros de Tornado Cash a partir del 28 de octubre. El 29 de octubre, ensayó el proceso completo de «delegar—barrer» en tres billeteras de su propiedad, transfiriendo solo de $2 a $6 cada vez; a las 15:59 de ese día, desplegó el contrato sweeper 0x63e842B054Bd624a465454D533C33F573e9c6fAe que luego se usaría contra Binance. El contrato no está verificado, enumera al operador como único llamador autorizado y contiene una función sweep (que transfiere todos los tokens listados y ETH de la cuenta a un destinatario especificado) y una función de reenvío (que permite a la cuenta delegada llamar a otros contratos).
2. Rociado de nonces: 50 autorizaciones, un acierto
A las 20:20:59, el operador envió una transacción de tipo 4 a Binance 14 (0x28C6c06298d514Db089934071355E5743bf21d60), que llevaba 50 autorizaciones EIP-7702 firmadas con la clave privada de Binance 14, una por cada nonce desde 18.914.775 hasta 18.914.824, cada una delegando la billetera al contrato sweeper. En ese momento, Binance 14 seguía procesando retiros de clientes, y el atacante no podía saber qué nonce era válido en ese instante, así que simplemente firmó una ventana completa. 49 fueron inválidas, 1 acertó, y la delegación surtió efecto de inmediato, mientras las propias transacciones de Binance seguían enviándose desde la misma billetera como de costumbre.
3. Barrido: una transacción se lleva $2.500 millones
A las 20:24:23, tres minutos y veinticuatro segundos después, el operador llamó a sweep en Binance 14, transfiriendo 167.464 ETH, 1.615 millones de USDT y alrededor de otros 60 tokens a una dirección receptora previamente sin historial 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c. A Binance 14 solo le quedó 1 ETH. A los precios de entonces, esta canasta de activos valía aproximadamente $2.500 millones.
4. Otras diez claves privadas en cuatro cadenas
24 segundos después del barrido, Binance 16 envió 28.005,6 ETH, 55,7 millones de USDT, 25,9 millones de RLUSD, 84,5 WBTC y otros cinco tokens a la misma dirección. En 12 minutos, Binance 55 en Optimism envió 44,2 millones de OP, cuatro billeteras calientes en Arbitrum enviaron 74,6 millones de ARB y 8.426 ETH, y cuatro billeteras calientes en Avalanche enviaron 1,81 millones de AVAX y 8,41 millones de USDT.
Ninguna de estas billeteras tenía código. Cada transferencia fue una transacción ordinaria firmada con la propia clave privada de la billetera, enviada en medio de retiros rutinarios. Las estadísticas públicas también atribuyen al mismo actor 18.270 BTC en la cadena de Bitcoin y aproximadamente $630 millones en la cadena de Tron (esta parte está marcada en el original como pendiente de confirmación de inteligencia de amenazas; véase la nota del traductor).
5. Cuenta inteligente y drenaje continuo
A las 20:41:23, el operador usó la aún delegada Binance 14 —que contenía una cuenta inteligente de Circle, Binance Hot Wallet 34— para transferir 780 millones de USDC desde esa cuenta de vuelta a la dirección receptora, seguidos de otros 43 millones de USDC. A las 21:44, barrió Binance 14 de nuevo, llevándose 200 millones de USDT y otros 13 tokens que habían llegado después del primer barrido. A las 22:00, la delegación seguía vigente, y cualquier fondo enviado a Binance 14 podía ser tomado sin otra firma.
Por qué el monitoreo onchain y la exposición al riesgo importan por igual cuando los fondos robados se están moviendo
Las instituciones pueden controlar sus propias claves y procesos de firma, pero no pueden controlar los lugares por los que fluyen los fondos, las contrapartes que les depositan dinero ni al atacante que ya ha movido $3.000 millones a través de cuatro cadenas. Es precisamente esta superficie de riesgo externa la que cae dentro del alcance del Monitoreo Onchain y la Exposición al Riesgo; y en este incidente, ambos comenzaron a funcionar en cuestión de segundos después de la primera transferencia.
La monitorización on-chain detecta comportamiento, no firmas. Las señales en este incidente fueron: el código de una hot wallet cambió de vacío a un puntero de delegación; una dirección de bóveda movió una cantidad del tamaño del inventario a una dirección sin historial; la misma nueva dirección recibió fondos de 11 wallets marcadas en cuatro cadenas en 12 minutos. Ninguna de estas requiere un patrón de ataque conocido ni una vulnerabilidad de contrato, por lo que los detectores de Blockaid se activaron 1 minuto 55 segundos después del barrido, y en 7 segundos para cada transferencia entre cadenas. La delegación en sí fue visible on-chain durante 3 minutos 24 segundos—cualquier institución que monitorice los cambios de estado de su propia dirección tuvo esa ventana para actuar. Cuando se dispara la alerta de monitorización, el flujo de respuesta de Blockaid puede enviar directamente una transacción de "barrer el saldo" o "limpiar la delegación" a la plataforma de custodia de la institución, con la respuesta y la detección comenzando dentro del mismo minuto.
Risk Exposure aborda el otro lado del mismo incidente: todos los que están a punto de recibir este dinero. Dentro de los 90 minutos posteriores al barrido, los fondos robados tocaron Permit2, LI.FI, Uniswap, UniswapX y Aave, seguidos de puentes entre cadenas y operaciones de agregadores. Cada pool, mercado de préstamos, puente entre cadenas, creador de mercado y exchange a lo largo de esta ruta ahora posee o ha procesado estos fondos robados, y el riesgo de cumplimiento recayó sobre ellos en el momento en que llegaron los fondos. Risk Exposure proporciona a estas instituciones señales en tiempo real.
Cómo EIP-7702 convierte una clave privada filtrada en control permanente
Antes de EIP-7702, una clave privada de hot wallet robada significaba una carrera contra el tiempo: el atacante tenía que completar cada firma antes de que la otra parte pudiera mover el saldo, y una vez que el exchange rotaba a una nueva dirección, la clave privada quedaba sin valor. Una clave privada que puede firmar delegaciones cambia esto.
Una autorización, válida en un único nonce, convirtió a Binance 14 en un programa propiedad del atacante. El primer barrido tomó el saldo a las 20:24 UTC, y la delegación permaneció intacta; a las 21:44 UTC, el atacante tomó más de $200 millones en nuevos depósitos sin que la wallet firmara otra transacción. Rotar a una nueva clave privada no la elimina, porque la delegación pertenece a la dirección, no a la clave privada. Solo firmando otra autorización con la clave privada filtrada que apunte la cuenta a la dirección cero se puede restablecer; hasta entonces, cada fondo enviado a Binance 14 es alcanzable.
Para los equipos que operan grandes EOA, los pasos accionables son concretos: tratar las autorizaciones EIP-7702 como operaciones privilegiadas y gestionarlas bajo la misma política que las transferencias de cold wallet; monitorizar los cambios de código en cada dirección de hot wallet y preparar transacciones de revocación con antelación; no mantener inventario en ninguna dirección cuyo estado de delegación sea incierto; tras una filtración, limpiar primero la delegación, luego rotar las claves y recargar la wallet; y en cada transacción de delegación, reenviar la lista de autorizaciones a la capa de cribado—porque, despojada de esa lista, una delegación parece una llamada vacía a una dirección de confianza. El motor de Blockaid ya evalúa esta lista, y Cosigner ya la reenvía; la brecha expuesta por este incidente radica en los flujos de firma que no lo hacen.
Conclusión
Las filtraciones de claves privadas siguen siendo la mayor fuente de pérdidas on-chain. Si se mantienen las estimaciones públicas, este será el mayor robo de la historia, más de tres veces los aproximadamente $1.500 millones robados a Bybit en febrero de 2025. Las claves privadas de 11 hot wallets de Binance firmaron transferencias a una dirección creada solo minutos antes, y una de ellas también firmó una autorización EIP-7702, convirtiendo su wallet en infraestructura permanente del atacante. Los emisores de stablecoins congelaron alrededor de $2.400 millones en dos horas, mientras que los activos nativos como ETH permanecen en manos del atacante.
Una firma válida producida por una clave privada filtrada no se ve diferente on-chain de una firma legítima. El éxito o fracaso de este tipo de ataque se decide en el momento de la firma mediante políticas—políticas que verifican lo que esta clave privada está a punto de firmar; y en los minutos siguientes, mediante la monitorización—rastreando fondos que aún pueden ser interceptados.
