Hackeo de Binance 2026: retiradas, reservas y causas

¿Se puede volver a retirar de Binance?

El 5 de noviembre Binance anunció nuevas reaperturas graduales desde las 04:00 UTC. Cada par token–red debe comprobarse en el acceso oficial.

El 4 de noviembre Binance comunicó una reposición aproximada del 98 % del importe afectado con recursos propios. No es una tasa de devolución de activos robados.

Según Binance, la instantánea de reservas del 4 de noviembre a las 00:00 UTC cubre 44 tokens. La prueba criptográfica completa seguía en elaboración al anunciarse. Una instantánea no es una auditoría financiera completa ni demuestra la causa. [28] [29] [17]

Congelado no significa devuelto

Los 2.540 millones de dólares anunciados antes eran una cifra provisional. Ahora Binance comunica cerca de 3.000 millones congelados. Una congelación puede limitar el movimiento de determinados tokens; no demuestra que ya se hayan devuelto a Binance o a sus usuarios.

El impacto total estimado en unos 6.300 millones tampoco es una pérdida neta definitiva. Las cifras de esta investigación en curso describen magnitudes distintas. Restar 3.000 a 6.300 millones no establece una falta de cobertura confirmada ni una pérdida final. [11] [14] [15]

Varios puntos de compromiso, no solo un portátil

La primera explicación de Binance describía un portátil DevOps comprometido y acceso a un contenedor de servicio. La versión posterior señala otros puntos de compromiso. Richard Teng afirma que el incidente iba más allá de una máquina o los permisos de un ingeniero. La pista inicial aún no constituye una causa completamente reconstruida.

Según Teng, la delegación EIP-7702 no pasó por los controles de aprobación normales. Esto plantea una pregunta concreta: ¿qué vía permitió esa autorización cuando los controles habituales debían examinarla? La declaración no publica todos los registros, identidades o mecanismos de evasión. No demuestra una técnica específica de phishing ni una fuga del contenedor.

La delegación observada en Ethereum y el acceso a la infraestructura operativa son niveles distintos. La cadena muestra autorizaciones y transacciones procesadas; la investigación operativa debe explicar el acceso previo. EIP-7702 permite delegar código. No es una regla de firmas múltiples, aunque una entrevista utilice una explicación simplificada. [5] [14] [22] [23]

Qué pueden hacer usuarios y empresas

Compruebe el estado en la aplicación habitual de Binance o introduciendo usted mismo la dirección oficial. Ignore enlaces inesperados de compensación o desbloqueo; nunca comparta contraseñas, códigos de un solo uso ni frases de recuperación. Las empresas pueden revisar responsables, aprobaciones y comunicación de incidentes, y documentar saldos y transacciones por canales oficiales. Evite operaciones precipitadas basadas en rumores. [6]

Por qué un portátil comprometido no implica automáticamente claves robadas

Un atacante no siempre necesita llevarse una clave privada como archivo para activar una transacción no autorizada. En una infraestructura con servicios de firma puede ser decisivo qué solicitudes llegan al firmante protegido. El abuso de esa vía puede producir firmas válidas para operaciones que nunca fueron aprobadas. Es un análisis técnico, no otro hecho confirmado sobre Binance.

Binance no comunica por ahora indicios de filtración de claves privadas de carteras. Por eso cobra importancia examinar identidades, acceso a contenedores y reglas de aprobación. La cuestión sigue abierta: un resultado inicial de la empresa no sustituye la reconstrucción completa ni una revisión independiente. Causa, conciliación de activos y posibles reembolsos exigen pruebas separadas. [5] [14] [16]

EIP-7702: qué permite realmente una autorización

EIP-7702 es una función de Ethereum que permite a una cuenta delegar la ejecución de código en un contrato inteligente. Requiere una autorización válida de esa cuenta. Un tercero puede incluirla en una transacción adecuada y pagar las comisiones; la transacción externa no tiene que proceder de la cuenta que delega.

Una vez aceptada, la cuenta apunta al código seleccionado. Una llamada posterior puede ejecutarlo en el contexto de la cuenta y afectar a sus activos. La delegación permanece hasta que otra autorización válida la cambie o elimine. EIP-7702 es una función; no se ha demostrado que una vulnerabilidad de este estándar causara el incidente.

El código puede ejecutarse en la fase de ejecución de la misma transacción; no es necesaria una llamada posterior. Una autorización criptográficamente válida no demuestra que la organización quisiera aprobarla. Un fallo (« revert ») en la fase de ejecución posterior no revierte una delegación ya procesada. [5]

Qué muestra el análisis inicial de la cadena

La firma de seguridad Blockaid informa de una transacción con 50 autorizaciones EIP-7702 para la dirección identificada como Binance 14. Según su análisis, se aceptó una autorización y la cuenta quedó delegada a un contrato. El nonce de la autorización debe coincidir con el contador actual de la cuenta. Es un análisis externo preliminar, no el informe final de Binance.

Un análisis independiente de 808bits sitúa la delegación el 29 de octubre a las 20:20:59 UTC y una llamada posterior con movimientos de tokens y ether a las 20:24:23 UTC. Esas horas corresponden a las transacciones Ethereum examinadas, no a todas las redes ni a una pérdida total definitiva. Una autorización válida no revela cómo se produjo: esos datos no prueban por sí solos el robo de una clave, el abuso del proceso de firma ni otra vía de acceso.

Fuentes: 808bits y drk.vc. Las horas describen transacciones examinadas, no una pérdida total confirmada. [4] [7] [8]

Deslice la tabla horizontalmente para leerla.

Qué pueden revisar las organizaciones en la firma

Para custodios y operadores de infraestructura de carteras, la cuestión esencial es qué autoriza realmente cada firma. Los sistemas de firma y aprobación deben mostrar con claridad el tipo de solicitud, la red, el contrato de destino y el nonce, y compararlos con una política documentada. Cuando sea viable, conviene impedir la aprobación ciega de hashes desconocidos y las delegaciones innecesarias.

También pueden restringirse los destinos permitidos, generar alertas por cambios y series anómalas de autorizaciones y revisar de forma independiente los cambios críticos. Definir responsables, ensayar la pausa y recuperación, y conservar los registros ayuda a investigar un incidente. Todavía no se ha demostrado que alguna de estas medidas hubiera evitado el caso concreto de Binance.

Estos controles son una interpretación técnica de Cyberkern. Las políticas deben verificar el contenido real antes de firmarlo; aprobar solo un hash puede ocultar su propósito. Una alerta en la cadena tras la ejecución llega tarde para impedir esa transacción. Una dirección permitida por sí sola no garantiza que el código sea seguro. [5] [9]

Qué revelan las 50 autorizaciones y el nonce

La cifra 50 describe, en primer lugar, las entradas de una lista de autorizaciones. No cuenta clientes afectados ni demuestra el robo de 50 claves. Ethereum comprueba para cada entrada datos como la firma, la red y el nonce de la cuenta. Si una entrada no supera una comprobación, se omite y el procesamiento continúa.

El nonce es un contador de la cuenta. En una cartera muy activa puede cambiar rápidamente con las transacciones. Las autorizaciones para diferentes valores pueden cubrir así una ventana cambiante. Los análisis externos señalan una autorización aceptada en la transacción de Binance examinada. Es un hallazgo del caso, no un límite del protocolo: una lista puede contener varias entradas válidas y cada autorización aceptada incrementa el contador. [5] [7] [12]

¿Cómo puede ocurrir pese a proteger las firmas?

La primera pista DevOps no explica toda la secuencia. Richard Teng identifica más puntos de compromiso y afirma que la delegación no pasó por los controles normales. La revisión anunciada abarca terminales, nube, gestión de claves y firmas. Los operadores necesitan comprobar cada vía crítica de autorización, además de proteger los dispositivos.

De ahí surgen tres preguntas para los operadores. Son un análisis técnico de Cyberkern; la declaración preliminar no permite afirmar qué control concreto habría evitado con certeza este incidente:

Una reconstrucción fiable conecta registros de acceso, actividad del contenedor, solicitudes de retirada, aprobaciones y firmas. En la cadena hay que distinguir la revocación anunciada del estado histórico. Una actuación sobre una cuenta o sesión no demuestra por sí sola que se haya eliminado una delegación anterior en la cadena. [5] [12] [14] [22] [23]

• Identidad y solicitud: ¿qué identidad podía emitir solicitudes críticas desde el equipo afectado? ¿Se comparaban de forma independiente la operación mostrada y el contenido firmado?
• Permisos del contenedor: ¿qué servicios y funciones de retirada eran accesibles? ¿Estaban limitados a lo necesario los permisos, accesos y excepciones?
• Contención y pruebas: ¿cuándo se bloquearon los accesos, se revocaron autorizaciones y se verificaron los cambios mediante registros o el estado de la cadena?

¿Lo habría evitado una cartera física o fría?

Las claves desconectadas y el hardware adecuado pueden reducir considerablemente la exposición al robo de claves. Es una protección importante. Pero no sustituye la comprobación de la operación: una clave bien protegida también puede firmar una solicitud peligrosa si se aprueba una delegación o un destino incorrecto.

Un exchange necesita además saldos operativos y retiradas frecuentes. Por eso importan también inventarios limitados en carteras conectadas, responsabilidades separadas y reglas claras y obligatorias para firmas críticas. Las fuentes revisadas no documentan por completo el hardware, el reparto de claves o la custodia desconectada utilizados por Binance en los sistemas afectados. El incidente no demuestra que las carteras físicas sean inútiles ni que un producto concreto lo hubiera evitado con certeza. [5] [13]

Tres preguntas para los usuarios y el informe del incidente

¿Está comprometida mi propia cartera? Un incidente en Binance no demuestra acceso a una cartera personal gestionada de forma independiente. Un saldo en un exchange y claves bajo custodia propia son situaciones distintas. Compruebe su cuenta en la aplicación habitual o escribiendo la dirección oficial; una noticia general no permite conocer su saldo individual.

¿Debo aprobar una compensación o una reparación de la cartera? No. Una noticia sobre el incidente no justifica aprobar contratos desconocidos, revelar una frase de recuperación ni pagar a quien ofrezca ayuda. Estas ofertas pueden ocasionar una nueva pérdida. Los cambios técnicos de una cartera realmente afectada deben formar parte de un plan de recuperación verificado.

¿Qué debe demostrar un informe completo? La relación técnica y temporal entre acceso, firma y movimientos de activos, seguida de una conciliación que separe transferencias, activos congelados, devoluciones y pérdida restante. Prometer cubrir las pérdidas responde a la responsabilidad financiera; no sustituye las pruebas de la causa ni de reembolsos ya completados. Una prueba de reservas por sí sola no sustituye una auditoría financiera completa ni la investigación de las causas y los controles internos de seguridad. [5] [6] [13] [14] [17]