Actualización (3 de noviembre de 2026): Binance publicó su informe inicial y aclara varios puntos de este artículo. El ataque no empezó con un solo portátil. Fue una campaña de meses que combinó un instalador manipulado (junio), una falsa entrevista de trabajo con malware (septiembre), el uso de una herramienta interna de IA como trampolín (20 de octubre) y un token de despliegue de contenedores robado, hasta llegar al servicio de firma de billeteras. El impacto es de unos 6.340 millones de dólares, de los que se congelaron o interceptaron unos 2.850 millones, y Binance dice haber repuesto el 98 % de los activos afectados. Además, afirma que la información más reciente del FBI señala a Corea del Norte. La investigación sigue abierta y el informe es el relato de la propia empresa. El texto de abajo es la versión original del 2 de noviembre.
Nota: la investigación sigue abierta y Binance todavía no ha publicado un análisis de causa raíz. Este texto se basa en lo que ha comunicado la propia empresa y en los análisis de TRM Labs y Elliptic hasta la fecha. Algunas cifras y detalles técnicos pueden cambiar.
La mayor parte de la cobertura mediática del robo de 6.300 millones de dólares a Binance se ha centrado en las cifras y en el impacto financiero. Para quienes miramos la infraestructura, lo realmente interesante está en la ingeniería. Según lo que se ha divulgado hasta ahora, no hubo una falla en los algoritmos criptográficos ni en la blockchain. Fue una falla clásica de arquitectura de seguridad: gestión de privilegios, segmentación de entornos y diseño del flujo que termina en una firma de retiro.
El monto es unas cuatro veces mayor que el del hackeo a Bybit (1.500 millones, febrero de 2025), que hasta ahora era el más grande registrado. TRM Labs atribuye el ataque, con alta confianza, a TraderTraitor, el grupo norcoreano que el FBI vinculó con el caso Bybit.
El vector de ataque: del portátil de un ingeniero a la firma de retiros
Binance indica que la investigación inicial apunta al portátil comprometido de un ingeniero DevOps. Ese equipo habría dado acceso a un contenedor de servicio interno desde el cual se enviaron retiros no autorizados. Más adelante la empresa habló de un «ataque complejo» y de puntos de brecha adicionales que todavía están en análisis. Aún no se sabe cómo se comprometió el portátil ni cuál fue el camino exacto hasta el sistema que firma.
Lo que sí documentan TRM Labs y Elliptic es el mecanismo en cadena. En Ethereum, el atacante envió una transacción con 50 autorizaciones EIP-7702 pre-firmadas, una por cada nonce consecutivo, para asegurarse de que alguna fuera válida. Cada autorización delegaba una hot wallet de Binance en un contrato “sweeper” controlado por el atacante, que se encargaba de vaciar los fondos. Según TRM, el dinero salió de las billeteras de Binance en diez blockchains.
Hay dos matices importantes:
- No se robó una clave privada. Binance afirma no tener evidencia de filtración de claves. El atacante consiguió que la propia infraestructura de firma de Binance aprobara las transacciones. Es el mismo patrón que en Bybit: no hace falta robar la llave si se puede lograr que el sistema firme por ti.
- EIP-7702 no es un bug del protocolo. Es una función legítima de Ethereum que el atacante aprovechó. La lección es que el riesgo se concentra en la capa que decide qué se firma.
Sobre la causa raíz solo podemos especular con cautela. Si el portátil tenía una ruta confiable hasta un servicio capaz de pedir firmas, el perímetro real de producción era ese portátil. Y si la plataforma no validó el contexto de esas solicitudes (origen, volumen inusual, patrón de nonces), la ausencia de controles conductuales fue el eslabón siguiente. Insisto en que esto es una hipótesis, no un hallazgo confirmado.
[Portátil de un ingeniero DevOps comprometido]
│
▼
[Contenedor de servicio con acceso a retiros]
│
▼
[Infraestructura de firma emite 50 autorizaciones EIP-7702]
│
▼
[Hot wallets delegadas a un contrato "sweeper"] ──► [Fondos en 10 blockchains]
│
▼
[Emisores de stablecoins congelan fondos]En resumen: no rompieron la caja fuerte. Consiguieron que el sistema de apertura programada abriera la puerta por ellos.
La paradoja de la remediación: centralización como mecanismo de seguridad
Tras el drenaje, el problema pasó de ser una vulnerabilidad de infraestructura a una carrera contra el tiempo. En una red descentralizada pura, el rastreo habría sido puramente forense y el dinero, irrecuperable.
Pero buena parte del botín estaba en stablecoins centralizadas. Tether congeló cerca de 1.570 millones de dólares en USDT y Circle más de 800 millones en USDC. Binance habló de unos 3.000 millones congelados en cadena con ayuda de socios (otros medios sitúan la cifra entre 2.500 y 2.700 millones). Desde la ingeniería de software, la función de congelamiento y las listas negras de esos contratos funcionaron como un mecanismo de revocación a escala global. Para los puristas cripto es una contradicción filosófica; para la mitigación de riesgos fue un cortafuegos indispensable.
También conviene decir lo incómodo: cerca de la mitad del monto no se congeló, y esa parte depende de que Binance la reponga.
Por qué no hubo un apocalipsis cripto
- El libro mayor público funcionó. A diferencia de FTX, donde los balances internos estaban adulterados, aquí cada movimiento fue visible en cadena. Firmas como TRM Labs y Elliptic pudieron seguir los flujos casi en tiempo real. No hubo asimetría de información sobre qué había pasado.
- Binance absorbió la pérdida con recursos propios. La empresa anunció que cubriría todas las pérdidas con fondos propios y con su fondo SAFU, y empezó a reponer saldos. Que el incidente no obligara a congelar la red ni a un hard fork muestra que la capa operativa de la plataforma y la capa del protocolo están bien desacopladas.
- El mercado reaccionó, pero sin colapsar. Las principales criptomonedas cayeron en las primeras horas, con bitcoin tocando los 77.500 dólares, sin una cascada sistémica.
Lecciones de arquitectura
Estas lecciones valen para cualquier sistema que automatice acciones financieras, y no son un diagnóstico de lo que Binance hizo mal (eso solo lo dirá su post-mortem):
- Separar quién solicita de quién autoriza. El servicio que envía un retiro no debería poder obtener por sí solo una firma válida. Las políticas de firma (límites por transacción, por hora y por destino, listas de destinos permitidos) deben vivir en un sistema independiente, idealmente respaldado por HSM o enclaves seguros, con aprobación humana o multi-parte para montos altos.
- Credenciales y autorizaciones de vida corta. Cualquier pre-autorización utilizable en bloque (tokens, firmas, delegaciones) debería caducar en minutos y estar atada a contexto, no ser reutilizable ni transferible.
- Aislar los pipelines y las máquinas de desarrollo de la producción financiera. Un portátil de uso diario no debería tener una ruta hasta servicios que puedan mover fondos. Si la tiene, ese portátil es producción.
- Detección conductual. Una firma criptográficamente válida ya no basta. Un sistema financiero moderno debería frenar de forma autónoma ráfagas anómalas de solicitudes, como 50 autorizaciones consecutivas para vaciar una billetera.
¿Qué nos dejó el hackeo?
La blockchain resistió porque nada de lo que falló estaba en ella. Lo que cedió fue una pieza centralizada y humana: el entorno de un ingeniero y el camino de confianza hacia la firma de retiros. Y eso matiza el mensaje: este incidente no habla tanto de la «resiliencia de la Web3» como de lo que ocurre cuando un intermediario centralizado concentra el riesgo operativo. Los intermediarios tendrán que evolucionar hacia modelos de seguridad mucho más estrictos, porque un error en una laptop de desarrollo ya costó miles de millones.
Excelente analisis, facil de entender