Binance: robo récord de 6.300 millones desde un portátil DevOps

El 29 de octubre de 2026 salieron de los hot wallets de Binance, los monederos conectados a internet que el exchange usa para los retiros, unos 6.300 millones de dólares en criptomonedas. Binance ha confirmado el incidente y, en sus primeras conclusiones, lo relaciona con el portátil comprometido de un ingeniero DevOps. Las empresas de análisis de blockchain TRM Labs y Chainalysis lo atribuyen con alta confianza a TraderTraitor, el grupo norcoreano al que el FBI atribuyó el robo de 1.500 millones a Bybit en febrero de 2025. Si las cifras se confirman, es el mayor robo de criptomonedas registrado.

La noticia la publican BleepingComputer, Security Affairs, TechCrunch, The Hacker News, The Register, SecurityWeek, Help Net Security y The Record.

Qué ha pasado

• 29 de octubre, desde las 20:05 UTC: según TRM Labs, unos 6.360 millones de dólares salen de los monederos de Binance, la mayor parte en unos 20 minutos. TRM habla de diez blockchains; The Record, en cambio, escribe 20 blockchains, entre ellas Bitcoin, Ethereum, Tron, XRP Ledger y Solana.
• En las primeras horas, las estimaciones públicas, basadas solo en las transacciones observadas, oscilan entre 2.000 y 5.800 millones. Binance dice que está investigando y que los fondos de los usuarios están «completamente a salvo», y después suspende depósitos y retiros. Según The Register, también se detuvo la negociación.
• 30 de octubre: en su primera actualización técnica, Binance eleva la estimación a 6.300 millones, afirma haber congelado unos 3.000 millones con ayuda de sus socios y se compromete a cubrir todas las pérdidas con el fondo SAFU y con fondos propios. Según Help Net Security, los depósitos se han reanudado, mientras que los retiros siguen suspendidos hasta completar la revisión de seguridad del servicio de retiros y de las direcciones asociadas, con una reanudación prevista en 48 horas.

Detalles técnicos

La versión de Binance. La investigación inicial indica que el portátil comprometido del ingeniero DevOps permitió al atacante acceder a un contenedor de servicio y enviar transacciones de retiro no autorizadas. Binance afirma no haber encontrado pruebas de una fuga de claves privadas de los monederos. El co-CEO Richard Teng precisa que el atacante «no usó simplemente los permisos de un ingeniero» y que no fue una acción «de un clic», sino un proceso más complejo; la empresa señala «otros puntos de intrusión» que aún analiza. La autorización de la dirección afectada se ha revocado y se ha anunciado un post-mortem técnico. Binance no ha explicado cómo se comprometió el portátil: The Register apunta a phishing o a un paquete de software comprometido, pero es solo una hipótesis.

El análisis de TRM Labs (recogido por SecurityWeek, Help Net Security y BleepingComputer):

• preparación: al menos un día y medio. El monedero usado en la operación se financió con pequeños retiros de Tornado Cash y el código malicioso se probó en otros monederos antes del ataque;
• Ethereum: los atacantes usaron EIP-7702, el mecanismo que permite a un monedero normal delegar su comportamiento en un smart contract firmando una autorización. Enviaron 50 autorizaciones firmadas de antemano por un hot wallet de Binance, para que una coincidiera con el contador de transacciones (nonce) en el momento de la ejecución. El monedero quedó delegado en un contrato que solo controlaban los atacantes, que lo vaciaron;
• las demás blockchains: los monederos de Binance enviaron los fondos con transacciones normales firmadas de forma válida, aunque usan tipos de clave y esquemas de firma distintos, todo en una media hora. Para TRM, la explicación más probable es que el atacante consiguió que el sistema de firma de los hot wallets de Binance firmara las transacciones que él quería. El phishing, que al principio parecía explicar lo ocurrido en Ethereum, no explica las demás cadenas.

Las dos versiones son compatibles: se puede abusar de un servicio de firma sin que las claves salgan nunca del sistema.

Atribución. TRM atribuye el ataque a TraderTraitor (rastreado también como Lazarus Group y APT38) por las similitudes con Bybit y con el ataque a KelpDAO de abril de 2026: monedero operativo financiado con un mezclador, larga preparación y firmas recogidas de antemano y usadas todas a la vez. Chainalysis llega a la misma conclusión tras encontrar fondos del robo a Bitget del mes pasado mezclados con los sustraídos a Binance. Binance no ha nombrado a los responsables.

Congelaciones y blanqueo. Tether bloqueó más de 1.560 millones en USDT y Circle más de 800 millones en USDC; Ripple, World Liberty Financial y el Security Council de Arbitrum bloquearon importes menores. TRM cuenta unos 2.700 millones congelados; Binance, unos 3.000. Para adelantarse a los bloqueos, los atacantes vendieron USDT a market makers a más del 10 % por debajo del precio de mercado y pidieron prestado ETH en Aave con USDT como garantía. Según TRM, aún controlan más de 420.000 ETH y 18.270 BTC, unos 2.400 millones que ningún emisor puede congelar.

MITRE ATT&CK (nuestra correspondencia a partir de los hechos publicados): T1657 (Financial Theft). No se ha revelado el vector de acceso inicial.

Impacto para las empresas europeas e italianas

Si tienes fondos en Binance, el efecto inmediato es el bloqueo de los retiros y el riesgo de phishing: la propia Binance advierte que no te fíes de enlaces, mensajes o peticiones de datos que lleguen por canales no oficiales. Los proveedores de servicios de criptoactivos autorizados con arreglo a MiCA entran en el ámbito de DORA, con sus obligaciones sobre riesgo TIC y notificación de incidentes.

La lección, sin embargo, va mucho más allá de las criptomonedas. Bastó el portátil de alguien que gestiona la infraestructura para llegar a un contenedor de producción y, desde ahí, a un servicio que firma operaciones de valor. El mismo esquema se aplica a pagos, publicación de software firmado, CA internas y claves en KMS o HSM: si el servicio firma lo que se le pide, proteger la clave no basta. Para las entidades NIS2, el artículo 21 exige medidas de control de acceso, seguridad en el desarrollo y gestión de incidentes, y los puestos del personal DevOps forman parte de ellas.

Qué hacer ya

1. Fondos en Binance: usa solo los canales oficiales y avisa a quien gestiona la tesorería de que circularán falsos anuncios y falsos agentes de soporte.
2. Puestos DevOps y de administración: trátalos como sistemas críticos. Puestos dedicados a la administración, nada de acceso directo a producción desde el portátil de cada día, credenciales de corta duración y autenticación fuerte.
3. Acceso a los contenedores de producción: revisa quién puede abrir una sesión o ejecutar comandos en los contenedores, registra cada sesión y genera alertas ante accesos fuera de horario o desde dispositivos nuevos.
4. Servicios de firma: añade reglas que no dependan de quién hace la petición, como límites por importe y frecuencia, destinos autorizados y aprobación de varias personas por encima de un umbral. Prevé un bloqueo de emergencia: aquí la mayor parte de los fondos salió en 20 minutos.
5. Autorizaciones firmadas de antemano: si gestionas monederos, impide que el sistema firme delegaciones EIP-7702 no previstas y comprueba si existen firmas ya preparadas y sin usar.
6. Exchanges y servicios que aceptan depósitos en cripto: TRM recomienda comprobar los depósitos entrantes frente a las direcciones que ha vinculado al robo.

Cómo ayuda ARXDOME

ARX Sentry recoge con su agente logs, eventos de seguridad, procesos y cambios en los archivos de ordenadores y servidores Windows, Linux y macOS, incluidos los puestos de desarrolladores y DevOps. Las páginas de identidad del SOC muestran accesos privilegiados, accesos nocturnos y ráfagas de intentos. Con ARX Trace, los analistas lanzan recogidas y búsquedas en varias máquinas para saber si un puesto está comprometido y hacia dónde se movió el atacante.

Última actualización: 30 de octubre de 2026