¿Te imaginás que una sola computadora comprometida pueda convertirse en una puerta de entrada para sustraer miles de millones de dólares de una de las plataformas de criptomonedas más grandes del planeta?
Eso es precisamente lo que Binance comenzó a investigar después del ataque del 29 de octubre de 2026.
Pero la historia es mucho más compleja. Y lo verdaderamente inquietante no es solamente el dinero robado, sino cómo los atacantes consiguieron que sistemas legítimos autorizaran operaciones fraudulentas.
Voy a reconstruir lo ocurrido, paso a paso, siguiendo las investigaciones técnicas y los movimientos registrados en blockchain.
// Los horarios corresponden a ARGENTINA //
28 DE OCTUBRE. COMIENZAN LOS PREPARATIVOS.
Al menos 36 horas antes del robo, los atacantes ya estaban preparando su infraestructura.
Financiaron una billetera operativa mediante pequeños retiros de Tornado Cash, un protocolo que dificulta rastrear el origen de las criptomonedas.
El 29 de octubre desplegaron código malicioso y realizaron pruebas utilizando billeteras bajo su propio control.
No estaban improvisando. Habían ensayado el mecanismo que posteriormente utilizarían contra Binance.
PERO ¿CÓMO CONSIGUIERON ENTRAR A SU INFRAESTRUCTURA?
Acá aparece uno de los datos más importantes.
Binance reconoció oficialmente que su investigación inicial apuntaba a una posible computadora portátil comprometida de un ingeniero DevOps.
¿Y qué significa eso?
Un ingeniero DevOps trabaja con sistemas que permiten administrar, ejecutar y automatizar servicios informáticos.
Según la hipótesis inicial de Binance, el compromiso de esa computadora habría permitido al atacante acceder a un contenedor de servicio y enviar instrucciones de retiro no autorizadas.
Un contenedor es un entorno donde se ejecuta un programa o servicio. En este caso, el problema habría sido que los delincuentes consiguieron utilizar infraestructura interna para solicitar operaciones que nunca debieron autorizarse.
Sin embargo, Binance todavía no confirmó cómo se comprometió la computadora ni cuándo ocurrió. Tampoco identificó públicamente el malware, las credenciales o la vulnerabilidad que pudieron haberse utilizado.
Y posteriormente reconoció que había encontrado otros puntos de intrusión...
29 DE OCTUBRE. 17:05. COMIENZA EL ROBO.
Cinco billeteras vinculadas a Binance transfieren aproximadamente 233 millones de XRP hacia una dirección controlada por los atacantes.
A las 17:10 aparecen movimientos en Solana y otras redes.
Pero lo más grave estaba por suceder.
17:20. EL ATAQUE SE MULTIPLICA.
Una billetera de Bitcoin de Binance transfiere 18.270 BTC hacia una dirección del atacante.
Al mismo tiempo, en Ethereum, los delincuentes utilizan una funcionalidad legítima denominada EIP-7702.
Esta permite que una billetera autorice la ejecución de código de un contrato inteligente.
¿Y qué hicieron?
Presentaron 50 autorizaciones criptográficas previamente firmadas por una billetera de Binance.
Cada autorización correspondía a un número diferente del contador de transacciones de esa billetera, conocido como nonce.
Prepararon 50 valores consecutivos porque ese contador cambiaba constantemente.
Cuando enviaron las autorizaciones, una coincidió con el valor vigente....
UNA SOLA FUE SUFICIENTE.
La billetera quedó delegada a un contrato inteligente controlado por los atacantes, diseñado para transferir los fondos siguiendo sus instrucciones.
17:22. OTRA RED COMPROMETIDA.
En Tron salen aproximadamente 612 millones de USDT y 46 millones de TRX.
Y entonces llega el momento decisivo.
17:24:23. EL VACIAMIENTO PRINCIPAL.
Apenas 3 minutos y 24 segundos después de la delegación en Ethereum, los atacantes ejecutan una operación que transfiere 167.464 ETH y 63 tokens diferentes, incluidos más de 1.600 millones de USDT.
Todo mediante una única transacción.
Segundos después, otra billetera de Binance realiza nuevas transferencias no autorizadas.
Pero hay algo todavía más preocupante... La delegación maliciosa seguía activa.
Eso significaba que, si ingresaban nuevos fondos a esa billetera, los delincuentes podían volver a retirarlos.
Y así ocurrió.
A las 17:41 se registra otra ejecución del contrato, seguida de nuevas operaciones durante las horas posteriores.
¿QUÉ NOS DICE TODO ESTO?
Que el incidente no puede explicarse simplemente como el robo de una contraseña.
Las transferencias realizadas en distintas blockchains tenían firmas criptográficas válidas.
La investigación de TRM Labs considera que los atacantes probablemente consiguieron hacer que la infraestructura de firma de las billeteras calientes de Binance autorizara transacciones elegidas por ellos.
Esto es fundamental.
Una cosa es robar una clave privada. Otra, conseguir que el sistema legítimo encargado de utilizarla firme operaciones fraudulentas.
Binance sostiene que todavía no encontró evidencia de filtración de claves privadas.
17:57. COMIENZA LA RESPUESTA.
World Liberty Financial ejecuta un primer congelamiento de tokens WLFI.
A las 18:01, Tether congela fondos USDT vinculados al ataque.
A las 18:04, Circle bloquea aproximadamente 823 millones de USDC.
Los delincuentes intentan adelantarse a estas medidas convirtiendo stablecoins en otros activos, principalmente ETH.
¿Por qué?
Porque los emisores de determinadas stablecoins pueden congelar sus tokens. Bitcoin y Ether, en cambio, no tienen un emisor central con esa misma facultad.
19:33. BINANCE SUSPENDE LOS RETIROS.
Según los reportes recopilados por Bitquery, la plataforma interrumpe los retiros mientras investiga el incidente.
Sin embargo, la actividad maliciosa todavía no había terminado.
A las 20:05 aparecen movimientos de una segunda oleada en Avalanche y Polygon.
Y a las 20:56 se registra la última ejecución documentada del contrato malicioso sobre la billetera principal de Ethereum.
21:10. BINANCE REVOCA LA DELEGACIÓN.
Finalmente, Binance consigue cancelar la autorización maliciosa utilizada en Ethereum.
Habían transcurrido casi cuatro horas desde que los atacantes obtuvieron esa capacidad de ejecución.
Durante la respuesta también se congelaron y recuperaron activos en distintas redes. Binance informó posteriormente que aproximadamente 3.000 millones de dólares habían sido inmovilizados en blockchain.
30 DE OCTUBRE. APARECEN LAS PRIMERAS EXPLICACIONES OFICIALES.
Binance confirma la hipótesis de la laptop comprometida del ingeniero DevOps, pero en una segunda actualización reconoce otros puntos de intrusión.
También anuncia que cubrirá las pérdidas mediante fondos corporativos y su fondo de protección SAFU.
La investigación de TRM Labs atribuye el ataque, con alta confianza, al grupo norcoreano TraderTraitor. Binance, por su parte, todavía no confirmó oficialmente la identidad de los responsables.
Y llegamos a la conclusión más importante.
LOS ATACANTES NO NECESITARON ROMPER LA CRIPTOGRAFÍA DE LAS BLOCKCHAINS.
Consiguieron autorizaciones y firmas válidas para ejecutar transferencias que nunca debieron permitirse.
Todavía falta conocer exactamente cómo pasaron desde los sistemas comprometidos hasta esa capacidad de autorización.
🧠 Pero el caso deja una enseñanza demoledora:
PODÉS PROTEGER LAS CLAVES PRIVADAS, UTILIZAR CRIPTOGRAFÍA AVANZADA Y TENER MILLONES INVERTIDOS EN SEGURIDAD.
PERO SI UN DELINCUENTE CONSIGUE QUE TU PROPIO SISTEMA DE AUTORIZACIÓN TRABAJE PARA ÉL, NO NECESITA ROMPER TU SEGURIDAD DESDE AFUERA.
PUEDE HACER QUE SEA TU PROPIA INFRAESTRUCTURA LA QUE EJECUTE EL ROBO....
Fuentes:
https://www.binance.com/es-LA/support/announcement/detail/c5a8729a97ac486d963784d96c5642d7
https://www.binance.com/en/support/announcement/detail/d3306d9dca5243548c813b605e1d1751
https://www.trmlabs.com/resources/blog/north-korea-steals-usd-6-36-billion-from-binance-in-the-largest-hack-in-history
https://bitquery.io/investigations/binance-hack