El hackeo a Binance empezó en una laptop: qué probar en tus propios sistemas

¿Qué pasó en el hackeo a Binance?

El hackeo a Binance es el robo de unos USD 6.300 millones en criptomonedas de las hot wallets de Binance el 29 de octubre de 2026. Según TRM Labs, es el mayor robo de criptomonedas registrado, unas cuatro veces los USD 1.500 millones que los atacantes le quitaron a Bybit en febrero de 2025. Los reportes públicos dan esta secuencia:

• A las 20:05 UTC, los fondos empezaron a salir de las wallets de Binance en diez blockchains. La mayor parte del dinero se movió en los 20 minutos siguientes.

• En Ethereum, el atacante usó una delegación EIP-7702, con 50 autorizaciones firmadas por adelantado, para convertir una hot wallet de Binance en un sweeper bajo su control.

• Los emisores de stablecoins congelaron fondos durante la noche. TRM contó unos USD 2.700 millones congelados a las 00:30 UTC del 30 de octubre, y solo Tether congeló unos 1.770 millones de USDT.

• Binance suspendió depósitos y retiros, y dijo que cubriría todas las pérdidas con su Secure Asset Fund for Users (SAFU) y con fondos propios.

• En una actualización posterior, Binance dijo que su investigación había "descubierto puntos de intrusión adicionales" más allá de la laptop.

EIP-7702 es una funcionalidad de Ethereum, añadida en 2025, que permite que una cuenta normal delegue sus acciones a código de un contrato inteligente mediante una autorización firmada (EIP-7702). The Hacker News cita las declaraciones de Binance, y Chainalysis da su propia estimación de unos USD 2.800 millones congelados.

¿Qué es una hot wallet y por qué es un blanco para los atacantes?

Una hot wallet es una billetera de criptomonedas cuyo sistema de firma está en línea, para que un exchange pueda procesar retiros sin que intervenga una persona. Una cold wallet guarda sus claves fuera de línea y necesita pasos manuales para cada transferencia. Los exchanges mantienen la mayor parte de los fondos en almacenamiento en frío y un saldo operativo en hot wallets.

El detalle importante está en la declaración de Binance: no encontró evidencia de que se filtrara una clave privada de una wallet. Las 50 autorizaciones que describe TRM se firmaron por adelantado, así que algo tuvo que firmarlas. Si ambos hechos se sostienen, el atacante no robó las claves. Hizo que los propios sistemas de Binance firmaran. Cuando un servicio de firma firma cualquier solicitud bien formada que venga de un servicio interno de confianza, controlar ese servicio interno basta para mover fondos.

Esto no es exclusivo de las criptomonedas. Un servicio de pagos, una API de core bancario o una cola de transferencias en un banco tiene el mismo punto débil cuando confía en toda solicitud que viene de dentro de la red.

¿Cómo llegó el atacante al sistema de retiros de Binance?

El relato preliminar de Binance describe esta ruta:

1. El atacante comprometió una laptop que usaba un ingeniero DevOps. Binance no ha dicho cómo.

2. Desde esa laptop, el atacante obtuvo acceso a un contenedor de servicio en la infraestructura de Binance.

3. El atacante usó ese contenedor para enviar transacciones de retiro no autorizadas.

4. La infraestructura de hot wallets de Binance firmó esas transacciones, y los fondos salieron por diez blockchains.

Toma la laptop como una hipótesis de trabajo, no como una causa raíz confirmada. El co-CEO Richard Teng le dijo a CoinDesk que el robo no fue una sola acción "de un clic", que la delegación EIP-7702 eludió los controles de aprobación habituales de Binance y que un mecanismo de autodestrucción borró las herramientas y los rastros del atacante. Binance está revisando sus sistemas en la nube, los dispositivos de sus empleados, la gestión de claves y la firma. Cada paso de la ruta es un punto de control: el atacante tuvo que superarlos todos, y al defensor le bastaba con detenerlo en uno.

¿La misma cadena de acceso ha causado pérdidas en otras organizaciones?

Sí. Bancos, exchanges y proveedores de wallets han perdido dinero por la misma secuencia: el atacante compromete a una persona o un sistema con acceso privilegiado y luego usa ese acceso para llegar al sistema que mueve el dinero. Estos casos públicos siguen ese patrón:

América Latina también ha visto la primera parte de esta cadena: engañaron a un empleado de Redbanc, la red interbancaria de Chile, para que descargara malware, como contamos en nuestro post sobre ciberseguridad en servicios financieros. En cada caso, el primer objetivo fue una persona con acceso privilegiado, no una aplicación pública. Hablamos de robos anteriores a exchanges en Top 10 de delitos con criptomonedas.

¿Cómo te ayuda Fluid Attacks a probar cada eslabón?

La protección de endpoints y la concientización en seguridad defienden el primer eslabón. La mayoría de los eslabones siguientes dependen de cómo se escribe y se configura el software, y Fluid Attacks los prueba antes que un atacante. Estos son los cinco eslabones que revisamos en aplicaciones de banca y fintech.

1. Secretos en repositorios y pipelines

Un atacante que controla la laptop de un desarrollador puede leer todos los repositorios que ese desarrollador puede leer. Las credenciales, claves de API y tokens en el código fuente, en archivos de configuración o en el historial de Git convierten ese acceso en acceso a otros sistemas. Busca información sensible en el código fuente, incluidas credenciales y secretos que se borraron pero siguen en el historial de Git. La corrección es eliminar el secreto, rotarlo y moverlo a un gestor de secretos. El escaneo de secretos de Fluid Attacks encuentra secretos expuestos en código, configuración e infraestructura como código (IaC), y puede romper el build en tu pipeline de CI/CD cuando encuentra uno.

2. Dependencias maliciosas y vulnerables

Los atacantes también distribuyen malware mediante paquetes de software y pruebas de programación falsas, como muestra el caso de DMM Bitcoin. En septiembre de 2025, un ataque de phishing a un mantenedor de npm introdujo código que redirigía transacciones de criptomonedas en paquetes de npm con más de 2.000 millones de descargas semanales, como explicamos en nuestro análisis de ese ataque a npm. Revisa cada dependencia en busca de vulnerabilidades conocidas y de malware, y fija las versiones para que una nueva versión no entre a un build sin revisión. Nuestro análisis de composición de software (SCA) genera una lista de materiales de software (SBOM) y ordena las dependencias vulnerables según su riesgo real.

3. Funciones privilegiadas dentro de tus aplicaciones

Muchas aplicaciones tienen funciones para los equipos de operaciones: paneles de administración, endpoints de soporte, rutas de depuración, cuentas de servicio y tokens que los servicios usan para llamarse entre sí. Estas funciones suelen recibir menos revisión que las funcionalidades para clientes, porque solo los usuarios internos llegan a ellas. Tras comprometer una laptop, el atacante es un usuario interno. Verifica que cada función privilegiada exija autenticación fuerte, que cada rol tenga solo los permisos que necesita (privilegios excesivos) y que ninguna ruta permita a una persona actuar sobre datos de producción sin los controles normales. En nuestra revisión de código seguro, los analistas rastrean quién puede llamar a cada una de estas funciones y con qué identidad.

4. Autorización y lógica de negocio en los flujos que mueven dinero

El sistema de retiros es donde el ataque se convierte en pérdida. La declaración de Teng de que una delegación eludió los controles de aprobación normales muestra por qué: un paso de aprobación que una segunda ruta puede saltarse no protege nada. Revisa cómo los servicios que crean, aprueban y firman transacciones autentican cada solicitud, y qué verifican antes de actuar:

• ¿El servicio de firma verifica qué servicio envió la solicitud y que esta pasó por aprobación?

• ¿Una transferencia grande o inusual necesita una segunda aprobación independiente?

• ¿Hay límites de monto, límites de frecuencia y tiempos de espera que un operador solo puede cambiar en un sistema separado?

Las fallas aquí son de control de autorización inadecuado y debilidades de lógica de negocio, y los escáneres automatizados rara vez las encuentran. Nuestros pentesters prueban estos flujos en PTaaS: intentan mover dinero con el acceso que tendría un empleado comprometido.

5. Infraestructura como código

Si tus repositorios definen infraestructura en Terraform, manifiestos de Kubernetes o archivos de Docker Compose, una falla de configuración también es una falla de código. Un contenedor que corre con privilegios excesivos, un cluster role que cualquier pod puede usar o una regla de red que permite que las estaciones de trabajo lleguen a servicios de producción le facilitan al atacante el segundo paso. Un pull request que cambia un role binding o una regla de firewall merece la misma revisión que un cambio en el código de pagos. Las pruebas de seguridad de aplicaciones estáticas (SAST) revisan estos archivos junto con el resto del código, antes de que lleguen a producción.

¿Qué controles dependen de la operación y no del código?

El hackeo a Binance empezó con el acceso que una persona tenía a los sistemas de producción. El código de las aplicaciones no puede corregir eso, así que necesita su propia revisión periódica. Valida el acceso de tu equipo técnico a producción:

• Haz una lista de quién tiene acceso a producción y confirma que cada persona todavía lo necesita.

• Otorga acceso por un tiempo limitado y tras una aprobación, en lugar de acceso permanente.

• Exige autenticación multifactor en cada acceso a producción, preferiblemente con un método que el phishing no pueda capturar, como una llave de seguridad física. Mantén las sesiones cortas: en el robo a Bybit, el atacante reutilizó un token de sesión de AWS que ya había pasado la MFA.

• Asegúrate de que nadie pueda llegar a contenedores o servicios de producción directamente desde una laptop de trabajo. Usa una ruta de acceso controlada, como un bastion host o un broker de acceso, que registre cada sesión.

• Registra cada acceso y cada acción sensible, y envía alertas cuando la actividad sea inusual, como una ráfaga de retiros a una hora poco habitual.

La configuración de la nube es parte de esta revisión. La gestión de la postura de seguridad en la nube (CSPM) revisa de forma continua la configuración de identidades y accesos en tus cuentas de nube frente a requisitos de seguridad.

Preguntas frecuentes

¿Robaron una clave privada de Binance?

Binance dijo que no encontró evidencia de que se filtrara una clave privada de una wallet. Su declaración preliminar dice que el atacante envió transacciones de retiro no autorizadas a través de un contenedor de servicio. Esto sugiere que el atacante usó sistemas en los que confiaba la infraestructura de firma de Binance, no claves robadas. El postmortem confirmará o corregirá esto.

¿EIP-7702 es una vulnerabilidad?

No. EIP-7702 es una funcionalidad estándar de Ethereum que permite que una cuenta delegue sus acciones a código de un contrato inteligente. Los reportes públicos no describen una falla en EIP-7702 en sí. Describen autorizaciones que firmaron los propios sistemas de Binance y que se saltaron sus controles de aprobación habituales. El punto débil fue qué solicitudes aceptaba la infraestructura de firma.

¿Un escáner de código puede detectar un ataque como este?

El primer paso, no. Una laptop comprometida es un problema de seguridad de endpoints, y un escaneo de tu código no lo mostrará. Los escáneres y la revisión de código encuentran las fallas que facilitan los pasos siguientes, como secretos expuestos, dependencias vulnerables y verificaciones de autorización faltantes. La lógica de negocio de los flujos que mueven dinero requiere pentesting manual.

Prueba los flujos que mueven dinero antes que un atacante

La lección práctica del hackeo a Binance: haz una lista de cada flujo de tus sistemas que pueda mover dinero y de cada persona y servicio que pueda iniciar uno, y prueba qué puede hacer un atacante con cada una de esas identidades. Empieza por los flujos con los límites más altos y la menor cantidad de aprobaciones. Esta tabla relaciona cada eslabón con la técnica de Fluid Attacks que lo prueba:

Si tus equipos de fraude y de ingeniería gestionan estos riesgos por separado, nuestro post sobre riesgo de seguridad y fraude muestra cómo unirlos. Puedes probar nuestras herramientas con una prueba gratuita de 21 días o contactarnos para planear una prueba de tus flujos de transacciones.