Actualizado: 30 de octubre de 2026.
Binance informó que sufrió un ataque el 29 de octubre de 2026, con retiros no autorizados y un impacto estimado de 6,300 millones de dólares. La investigación continúa.
El incidente también plantea un tema relevante para las empresas: revisar hasta dónde puede llegar un atacante cuando consigue acceso a un equipo, una cuenta o un servicio interno.
¿Qué ocurrió en Binance?
Según la actualización oficial del 30 de octubre, se comprometió la seguridad de las billeteras digitales conectadas a internet de Binance, conocidas como hot wallets, desde las cuales se realizaron retiros no autorizados.
La compañía informó que contuvo la infraestructura afectada, revocó autorizaciones e implementó controles adicionales. También anunció que cubriría las pérdidas con su fondo de protección para usuarios, SAFU, y recursos propios.
Binance reportó aproximadamente 3,000 millones de dólares en activos congelados. Esto impide su movimiento, pero no significa que todos esos recursos ya hayan sido recuperados.
Al cierre de esa actualización, los retiros permanecían suspendidos mientras se realizaban verificaciones de seguridad. Los depósitos y otros servicios no afectados seguían operando.
Los atacantes operan en tiempo de ejecución. Tu AppSec también debería hacerlo
La única plataforma de seguridad de aplicaciones diseñada para la velocidad y la complejidad de la era de la IA. Un legado de inteligencia en tiempo de ejecución, aplicada a través de seis motores de escaneo, unificados en una sola vista para mostrarle el riesgo real.
Conocer..
¿Cómo pudieron acceder los atacantes?
La investigación inicial señaló que una computadora portátil de un ingeniero DevOps posiblemente permitió acceder a un contenedor de servicio y enviar solicitudes de retiro no autorizadas.
Posteriormente, Binance comunicó que había encontrado otros puntos de acceso utilizados durante el ataque. Por ello, todavía no es posible presentar una causa definitiva ni atribuir todo lo ocurrido a una sola computadora.
La empresa también indicó que, hasta ese momento, no había encontrado evidencia de filtración de las claves privadas de las billeteras. El informe técnico completo continúa pendiente.
Qué revelan los análisis técnicos
Las investigaciones de TRM Labs y Bitquery examinan operaciones registradas en las blockchains. Permiten observar movimientos y autorizaciones, aunque no reconstruyen por completo lo ocurrido dentro de la infraestructura de Binance.
Transferencias con firmas válidas
TRM identificó transferencias firmadas desde billeteras de Binance en distintas redes. Su interpretación es que el atacante pudo haber conseguido que la infraestructura de firma autorizara operaciones elegidas por él.
Esta es una conclusión de TRM, no una causa definitiva confirmada por Binance. Una firma válida demuestra que una operación cumple la verificación criptográfica; no demuestra que haya sido solicitada legítimamente por la organización.
Cincuenta autorizaciones para delegar la ejecución de una billetera
En Ethereum, TRM identificó el uso de EIP-7702, una función que permite a una cuenta delegar su ejecución al código de un contrato inteligente.
Según su análisis, el atacante presentó una transacción con 50 autorizaciones previamente firmadas, dirigidas a un contrato que podía vaciar los fondos siguiendo sus instrucciones.
Las autorizaciones cubrían valores consecutivos del contador de operaciones de la cuenta, denominado nonce. Una coincidió con el valor requerido y permitió activar la delegación.
El uso de esta función describe parte del mecanismo observado en Ethereum. Por sí solo, no establece cómo se obtuvieron las firmas ni explica los movimientos realizados en otras redes.
La autorización continuó activa después del primer retiro
Bitquery documentó que el código delegado permitió realizar nuevos retiros cuando llegaban fondos a la billetera afectada.
Su investigación sitúa estos eventos en los siguientes momentos:
| Evento | Fecha y hora UTC |
|---|---|
| Activación de la delegación | 29 de octubre, 20:20:59 |
| Retiro principal | 29 de octubre, 20:24:23 |
| Revocación de la delegación | 30 de octubre, 00:10:35 |
La autorización permaneció activa aproximadamente tres horas y cincuenta minutos. Según Bitquery, más de hora y media de ese periodo transcurrió después de que se suspendieran los retiros de la plataforma.
Este hallazgo muestra la importancia de verificar que una medida de contención retire también las autorizaciones que siguen permitiendo ejecutar acciones.
Cuatro áreas que conviene revisar en una empresa
Mientras se esclarece el incidente, desde NORTH NETWORKS proponemos revisar cuatro áreas de seguridad. Estas recomendaciones son generales y no presuponen qué controles tenía implementados Binance.
1. Permisos sobre sistemas y operaciones críticas
Identificar qué acciones pueden realizar las cuentas de usuarios, administradores y servicios automatizados.
La revisión debe considerar los permisos realmente necesarios, los accesos temporales y la rapidez con la que pueden revocarse cuando se detecta una actividad sospechosa.
2. Validaciones para acciones sensibles
Comprobar qué operaciones requieren una aprobación adicional y quién puede autorizarlas.
Transferencias, cambios de permisos y modificaciones de configuración necesitan controles acordes con su impacto. Conviene revisar el proceso completo, desde la solicitud hasta su ejecución.
3. Registros útiles para investigar
Conservar y centralizar los registros de acceso, cambios administrativos y operaciones relevantes facilita reconstruir lo ocurrido.
También es necesario definir quién revisa esos eventos, qué situaciones generan alertas y cómo se relaciona la información de distintos sistemas durante una investigación.
4. Procedimientos de contención y recuperación
El equipo debe saber cómo aislar un dispositivo o servicio, retirar sus accesos y verificar que sea seguro restablecer la operación.
Documentar responsables y practicar estos procedimientos ayuda a reducir la improvisación durante un incidente.
Monitoreo de red de nivel empresarial que revela patrones que otros pasan por alto. Más allá del monitoreo de NetFlow, agregue captura de paquetes, alertas basadas en reglas y mapeo de red a su base probada de Nagios
Conocer..
Zero Trust como marco de referencia
El enfoque Zero Trust descrito por NIST establece que la ubicación de un equipo dentro de una red o su pertenencia a la empresa no deben otorgarle confianza automática.
La autenticación y la autorización deben aplicarse al acceso a los recursos. Este principio ofrece un marco para revisar las relaciones entre usuarios, dispositivos, servicios y operaciones críticas.
Visibilidad para tomar decisiones de seguridad
El monitoreo de infraestructura, el análisis de registros y las evaluaciones de seguridad de aplicaciones permiten revisar diferentes aspectos del entorno tecnológico.
Su utilidad depende de definir qué se necesita supervisar o evaluar y quién atenderá los hallazgos.
En NORTH NETWORKS acompañamos a las organizaciones en la selección de soluciones de monitoreo con Nagios y evaluación de seguridad web con Burp Suite.
Contacta a nuestro equipo para revisar las necesidades de tu empresa.
Fuente:
Binance, NIST, TRM, Bitquery
