Hackeo de Binance: cómo salieron 6.360 millones de dólares sin indicios de claves filtradas

En el hackeo de Binance del 29 de octubre de 2026, un atacante sacó unos 6.360 millones de dólares de carteras repartidas en diez blockchains, según el análisis de las transacciones públicas que ha hecho TRM Labs. La mayor parte salió en unos veinte minutos a partir de las 20:05 UTC. Es el mayor robo de criptoactivos registrado, más de cuatro veces el de Bybit en febrero de 2025, y TRM lo atribuye a TraderTraitor, una unidad norcoreana.

Las cifras varían con la fuente y el momento de valoración, con unos 6.300 millones según Binance y 5.912 millones según Chainalysis. Binance se ha comprometido a cubrir las pérdidas con su fondo SAFU y con fondos de la compañía.

La hipótesis de TRM es que el atacante consiguió que el sistema de firma de Binance firmara las transacciones que quería, y ni Binance ni Blockaid ven indicios de filtración de claves privadas. Este artículo reconstruye la cadena de ataque con los datos públicos y explica el mecanismo usado en Ethereum. Después lo traslada a los controles que una entidad financiera española tiene a su alcance, como los consentimientos OAuth, las identidades de carga de trabajo (las cuentas que usan las aplicaciones, no las personas), la gestión de secretos y las obligaciones de DORA.

¿Cómo se desarrolló el hackeo de Binance?

La mayor parte de los fondos salió en unos veinte minutos, y una segunda oleada llegó unas dos horas y media después. Entre las 20:05 y las 20:09 UTC, cinco carteras de Binance en XRP Ledger enviaron 233,46 millones de XRP a una única dirección del atacante. Hacia las 20:10 siguieron Solana y Optimism.

A las 20:20 salieron 18.270 BTC de una cartera de Bitcoin que TRM describe como caliente, es decir, conectada para operar a diario, y CryptoQuant, citado por Forbes, como fría. El atacante empezó a repartir esos fondos en el mismo bloque en importes redondos de 1.000 y 100 BTC, una dispersión que TRM describe como cadena de pelado (peel chain) y que dificulta el rastreo. En los dos minutos siguientes salieron de Tron 612,7 millones de USDT y 46,4 millones de TRX. A las 23:05, una segunda oleada alcanzó carteras en Avalanche y Polygon.

Por cadenas, Ethereum concentra unos 3.790 millones de dólares, Bitcoin unos 1.470 y Tron unos 628, según TRM. Más que el reparto, importa que carteras en diez redes, con distintos tipos de claves y esquemas de firma, produjeron firmas válidas para el mismo atacante en una misma tarde.

Binance confirmó un incidente de seguridad y suspendió las retiradas mientras reconstruye su servicio de retiradas y cambia las direcciones asociadas, y prevé reanudarlas en unas 48 horas. Según su investigación inicial, el portátil comprometido de un ingeniero de DevOps pudo ser el punto de entrada para alcanzar un contenedor de servicio y enviar retiradas no autorizadas. En una actualización posterior, recogida por The Next Web, la empresa añadió que ha encontrado otros puntos de intrusión y que el incidente responde a varios factores. Su consejero delegado, Richard Teng, aclaró que el atacante no se limitó a usar los permisos de un ingeniero. El análisis de causa raíz sigue pendiente.

¿Cuánto tiempo preparó el atacante la operación?

El atacante preparó la operación durante al menos 36 horas, según TRM. A partir de la mañana del 28 de octubre, su cartera operadora recibió tres retiradas pequeñas desde Tornado Cash, un servicio de mezcla que oculta la procedencia de los fondos. TRM señala el mismo patrón de financiación en Bybit y en el ataque a KelpDAO de abril de 2026.

A primera hora del 29, el operador desplegó una primera versión del código del ataque y la probó en dos carteras. Más tarde ensayó la versión definitiva en una tercera y devolvió los fondos de prueba a su cartera operadora. Unas cuatro horas después de ese ensayo, una cartera caliente de Binance quedó delegada en ese mismo código.

De esa secuencia se desprenden dos lecturas. Hubo día y medio de actividad preparatoria visible en la cadena de bloques, aunque vincularla de antemano con Binance habría exigido saber qué buscar. Y el ensayo final describe una operación planificada, con margen para corregir errores antes de ejecutarla.

TRM atribuye el ataque, con alta confianza, a TraderTraitor, la unidad norcoreana que el FBI relacionó con el robo de 1.500 millones de dólares a Bybit. Chainalysis también lo vincula a ese grupo y ha detectado fondos del ataque a Bitget de septiembre mezclados con los de Binance, según Forbes. Binance no ha nombrado a los atacantes. La atribución es una valoración de terceros, no un hecho confirmado. Los grupos APT norcoreanos ya han aparecido en este blog con la campaña Dream Job de Lazarus.

¿Cómo tomó el control de una cartera de Ethereum sin robar claves?

En Ethereum, el atacante usó una delegación EIP-7702 que convirtió una cartera caliente de Binance en un contrato bajo su control. EIP-7702 llegó con la actualización Pectra de Ethereum en mayo de 2025 y permite que una cuenta ordinaria delegue su comportamiento en un contrato inteligente mediante una autorización firmada. Desde ese momento, las llamadas a la cuenta ejecutan el código de ese contrato, y la delegación sigue vigente hasta que la cuenta firma otra autorización que la sustituya. Se parece a un consentimiento OAuth, aunque solo puede anularla la clave de la cuenta, no un administrador desde fuera.

A las 20:20 UTC, el operador envió una única transacción con cincuenta autorizaciones firmadas con la clave de la cartera caliente, todas apuntando a un contrato programado para vaciar la cartera (sweeper) que solo acepta órdenes del atacante. Cada autorización solo es válida para un valor determinado del contador de transacciones de la cuenta, el nonce, y el de una cartera caliente avanza sin parar con las retiradas de los clientes. Con firmas para cincuenta valores consecutivos, alguna iba a coincidir con el contador en el momento de ejecutarse.

Tres minutos y 24 segundos después, el contrato vació la cartera en una sola transacción de 167.464 ETH y 63 tokens, entre ellos 1.615 millones de USDT. La delegación siguió activa al menos hasta las 23:56 UTC. El atacante volvió a vaciar la cartera a medida que entraban fondos a las 20:41, 20:59, 21:04, 21:44, 22:39 y 23:56. Esa cartera estaba autorizada además a ordenar operaciones de otra cartera de Binance gestionada por contrato, lo que le permitió mover 823 millones de USDC que Circle congeló a las 21:04.

Blockaid, proveedor de seguridad para transacciones en la cadena de bloques, sostiene que su motor clasifica como maliciosa una delegación así en cuanto aparece, porque convierte una cuenta en un contrato no confiable. Según la firma, el ataque podía haberse frenado en la transacción de delegación y, una vez publicada, quedaban 3 minutos y 24 segundos para reaccionar. Es la opinión de un fabricante. No consta que Binance usara su producto, pero señala la primera señal visible desde fuera, en el cambio de configuración y antes de que se movieran los fondos.

¿Por qué las demás cadenas apuntan al sistema de firma?

Las demás cadenas apuntan al sistema de firma porque en ellas no hubo delegación y, aun así, el atacante obtuvo firmas válidas. Carteras de Binance en XRP Ledger, Arbitrum, Avalanche, Optimism, Base, Bitcoin, Tron, Solana y, más tarde, Polygon le enviaron fondos mediante transferencias firmadas ordinarias. Otra cartera caliente de Ethereum movió 28.006 ETH, 55,7 millones de USDT y 25,9 millones de RLUSD sin delegación de por medio.

Son redes con tipos de claves y esquemas de firma distintos, y por eso TRM considera más probable que el atacante consiguiera que el sistema de firma de carteras calientes de Binance firmara las transacciones que quería. El lote de cincuenta autorizaciones preparadas de antemano sugiere, además, que ese acceso pudo estar limitado en el tiempo o que las firmas debían solicitarse a través de un sistema.

Las firmas multiparte (MPC, que reparten la firma entre varias partes) y los módulos de seguridad hardware (HSM) protegen las claves. No protegen la decisión de firmar. Eso explica que no haya indicios de claves filtradas y que, aun así, diez redes aceptaran firmas del atacante. Las cincuenta autorizaciones se firmaron antes de las 20:20, así que el primer rastro estaba en los registros del propio servicio de firma, no en la cadena de bloques.

Por eso TRM y Blockaid sitúan el control antes de la firma. Recomiendan rechazar autorizaciones EIP-7702 no previstas, tratar como indicio de compromiso las peticiones de muchas autorizaciones para un rango de nonces y aplicar listas de destinos permitidos y límites de importe. El consejero delegado de Blockaid, Ido Ben-Natan, tampoco cree que hubiera filtración de claves y habla de uso indebido del sistema de firma.

¿Dónde está el sistema de firma en una entidad sin criptoactivos?

En una entidad que no custodia criptoactivos, el equivalente es todo sistema que autoriza operaciones en nombre de la organización sin volver a pedir credenciales. Tratar la noticia como ajena a la banca sería un error, porque lo comprometido en Binance fue un sistema de ese tipo. En un entorno Microsoft aparece de tres formas habituales.

La primera son los consentimientos OAuth y los registros de aplicación de Entra ID. Una aplicación con permisos delegados o de aplicación sobre Microsoft Graph opera sin pedir credenciales a nadie, igual que una delegación EIP-7702 actúa mientras no se anule. Microsoft documenta el abuso de este mecanismo como illicit consent grant, un patrón parecido al que vimos en el robo de datos de Salesforce a través de aplicaciones conectadas. MITRE ATT&CK lo recoge en T1528 (Steal Application Access Token) y T1550.001 (Application Access Token), y su uso como persistencia, en T1671 (Cloud Application Integration).

La segunda es la adición de credenciales a un service principal, la identidad con la que actúa una aplicación. Un atacante con permisos suficientes no necesita robar el secreto existente, porque puede añadir un certificado o un secreto nuevo a la aplicación y firmar con él. La aplicación legítima sigue funcionando, sus responsables no notan cambios y el acceso sobrevive a la rotación de contraseñas de los usuarios. MITRE la clasifica como T1098.001 (Additional Cloud Credentials), y es una vía habitual de persistencia en la nube que tratamos en la guía sobre identidades no humanas.

La tercera es la firma de tokens y de código. Quien obtiene el certificado de firma de tokens de una federación como AD FS puede emitir tokens SAML válidos (T1606.002). Quien controla la firma de artefactos de software obtiene el mismo efecto que en Binance, con operaciones indistinguibles de las legítimas porque criptográficamente lo son.

En los tres casos, la detección basada en accesos anómalos, geolocalización o fuerza bruta puede no saltar, porque el atacante presenta una firma válida. La señal útil está en el cambio de configuración de la autorización.

¿Con qué controles se puede empezar esta semana?

Los primeros pasos son inventariar los consentimientos OAuth, limitar el consentimiento de los usuarios, alertar de credenciales nuevas en aplicaciones, restringir quién puede añadirlas y probar la revocación.

1. El inventario de delegaciones vivas debe listar los consentimientos OAuth concedidos y las aplicaciones con permisos de aplicación sobre Graph, con la fecha de concesión y quién la autorizó, datos que solo constan en el registro de auditoría. Una autorización sin propietario identificable es un hallazgo.
2. El consentimiento libre de los usuarios finales puede limitarse a editores verificados y permisos de bajo impacto, o sustituirse por el flujo de aprobación de administradores de Entra ID, sabiendo que los consentimientos ya concedidos siguen vigentes.
3. Los registros de auditoría de Entra ID, exportados a un SIEM con retención suficiente, deben alertar de operaciones como «Add service principal credentials», «Consent to application» o los cambios de certificados y secretos registrados en «Update application». Son cambios que deberían ser infrecuentes y tener un responsable con nombre.
4. Los roles que pueden añadir credenciales a aplicaciones, como Administrador de aplicaciones o Administrador de aplicaciones en la nube, deben tratarse como nivel 0 y activarse solo bajo demanda con Privileged Identity Management (PIM). Lo mismo vale para los propietarios de aplicaciones con permisos altos sobre Graph.
5. El procedimiento de revocación tiene que estar probado. Cada organización debería saber cuánto tarda en retirar un consentimiento, eliminar las credenciales que no reconoce y deshabilitar el service principal afectado, teniendo en cuenta que los tokens ya emitidos siguen siendo válidos hasta que caducan.
6. La infraestructura de firma debe separarse por niveles. TRM recomienda segregar sistemas y rutas de aprobación por cadena y por categoría de cartera. El equivalente corporativo es que un mismo sistema no pueda autorizar a la vez operaciones de tesorería y cambios en el directorio, como propone el modelo de niveles de acceso privilegiado.
7. La administración privilegiada debe hacerse desde estaciones dedicadas. Si se confirma que un portátil de DevOps fue uno de los puntos de entrada en Binance, la lección es directa. Cuando las identidades se administran desde el equipo con el que se lee el correo, el perímetro de la firma es ese equipo.
8. Los contactos de contención deben estar identificados antes del incidente. Tether congeló USDT a las 21:01 UTC y Circle, USDC a las 21:04. Fue menos de una hora después del inicio del robo. Entre los emisores de monedas estables y el Security Council de Arbitrum, el órgano que puede intervenir de urgencia en esa red, se inmovilizaron unos 2.700 millones de dólares, según TRM. La entidad debería tener localizados a sus interlocutores en custodios, proveedores críticos, INCIBE-CERT y el supervisor.

Mientras tanto, el atacante se apresuró a cambiar monedas estables, que sus emisores pueden congelar, por ETH a través de creadores de mercado y protocolos de préstamo. TRM recomienda a exchanges, creadores de mercado y otros intermediarios cotejar depósitos y contrapartes con las direcciones del atacante que ha etiquetado.

¿Qué exige DORA ante un incidente así?

DORA obliga a prevenir y detectar este tipo de abusos, a notificar el incidente en plazos tasados, a gestionar el riesgo de los proveedores TIC y a probar la resiliencia. El Reglamento (UE) 2022/2554 se aplica a las entidades financieras de la UE, incluidos los proveedores de servicios de criptoactivos autorizados con arreglo a MiCA (artículo 2.1.f).

La prevención corresponde al artículo 9, que exige limitar el acceso lógico y proteger los mecanismos de autenticación y las claves criptográficas. Lo desarrollan los artículos 20 y 21 del Reglamento Delegado (UE) 2024/1774, sobre gestión de identidades y control de acceso.

¿Obligan los artículos 10 y 11 a cambiar la detección?

Los artículos 10 y 11 obligan indirectamente a cambiar la detección, porque exigen detectar con prontitud actividades anómalas y tener planes de respuesta y recuperación. Cuando todas las operaciones son criptográficamente válidas, eso pasa por vigilar los cambios de configuración de la autorización, como las credenciales nuevas en aplicaciones, los consentimientos recientes o los cambios en las políticas de firma.

¿En qué plazos se notifica un incidente grave?

Un incidente grave relacionado con las TIC se notifica en tres pasos, según el artículo 19 y el Reglamento Delegado (UE) 2025/301. La notificación inicial debe enviarse lo antes posible, como máximo 4 horas después de clasificar el incidente como grave y, como regla general, no más de 24 horas después de tener conocimiento de él. El informe intermedio se presenta en las 72 horas siguientes a la notificación inicial, y el final, como máximo un mes después del último informe intermedio, con las causas, los costes y las medidas correctoras.

La clasificación sigue los criterios del Reglamento Delegado (UE) 2024/1772, y las notificaciones usan las plantillas del Reglamento de Ejecución (UE) 2025/302. En España, el destinatario es el Banco de España, la CNMV o la DGSFP según el tipo de entidad, y en el caso de los proveedores de criptoactivos autorizados con MiCA, la CNMV. Cada supervisor puede añadir requisitos de procedimiento.

¿Cambia algo en el riesgo de terceros TIC?

En el riesgo de terceros TIC de los artículos 28 a 30, el foco pasa a los proveedores que firman o custodian en nombre de la entidad. Un exchange en el que una entidad tiene fondos no suele considerarse por sí mismo un proveedor de servicios TIC, pero sí pueden serlo los servicios de custodia y firma, como las carteras MPC gestionadas, los HSM en la nube o las plataformas de identidad.

El artículo 30 fija el contenido mínimo de esos contratos, incluida la asistencia del proveedor ante incidentes y, para funciones críticas o importantes, sus obligaciones de información a la entidad. La pregunta de revisión es cuánto tardaría la entidad en saber por vía contractual, y no por la prensa, que su proveedor crítico ha sufrido un incidente así. Forma parte de la gestión del riesgo de terceros que exige DORA.

¿Deben las pruebas de resiliencia cubrir este vector?

Las pruebas de los artículos 24 a 27 deberían incluir el abuso de identidades de carga de trabajo y la adición de credenciales a aplicaciones. Las entidades obligadas a pruebas de penetración basadas en amenazas (TLPT) por el artículo 26 y el Reglamento Delegado (UE) 2025/1190 deberían incluirlo en sus escenarios. Dejarlo fuera omite lo que funcionó en Binance, como explicamos en nuestro análisis de TLPT y TIBER-ES en España.

¿Qué preguntas debe llevar la dirección al consejo de administración?

Las tres preguntas para el consejo son qué autorizaciones delegadas están vivas hoy en el directorio y quién las concedió, cuánto tarda la organización en revocarlas y a quién se llama en la primera hora.

El hackeo de Binance combinó una preparación de día y medio, un ensayo previo y, según la hipótesis de TRM y Blockaid, el uso de la capacidad de firmar en lugar de robar claves. La primera señal visible en la cadena de bloques fue un cambio de configuración, pero las autorizaciones ya se habían firmado antes dentro de Binance. La contención dependió en buena parte de terceros, los emisores de monedas estables y el Security Council de Arbitrum.

Hard2bit ayuda a revisar el inventario de consentimientos e identidades no humanas, a preparar el cumplimiento de DORA y a diseñar escenarios de red team que incluyan este vector.

Fuentes y atribución: este análisis se basa en información pública disponible a 30 de octubre de 2026, principalmente el análisis de TRM Labs, los comunicados de Binance recogidos por CyberInsider y The Next Web, Blockaid, Forbes, Fortune y Cointelegraph, y el texto de DORA y de sus reglamentos de desarrollo. Que el atacante controlara el sistema de firma es una hipótesis de TRM pendiente del análisis de causa raíz de Binance, y la atribución a TraderTraitor es una valoración de terceros. Las referencias a DORA no constituyen asesoramiento jurídico y deben contrastarse con el supervisor competente.