Volver

2026/11/02

El mayor robo de criptomonedas no comenzó en la blockchain, sino en una sola computadora portátil: lecciones de Binance

El robo a Binance empezó en un portátil DevOps comprometido, no por fallas criptográficas. Qué está confirmado, qué no, y cinco comprobaciones para sus sistemas.

El 29 de octubre de 2026, unos atacantes vaciaron hot wallets de Binance en al menos diez blockchains en pocas horas. Binance cifra el impacto en unos 6300 millones de dólares, lo que lo convierte casi con certeza en el mayor robo de la historia de las criptomonedas. Lo que falló no fue la criptografía. Según las conclusiones preliminares de Binance, el ataque comenzó en un único equipo portátil comprometido de un ingeniero de DevOps.

Eso hace que este incidente sea relevante mucho más allá de los exchanges de criptomonedas. Toda organización tiene personas, dispositivos y sistemas que pueden aprobar acciones sensibles: despliegues en producción, pagos, firmas, acceso privilegiado a la nube. Este artículo separa lo confirmado de lo que todavía es preliminar, explica por qué un endpoint privilegiado comprometido puede ser peor que una clave robada y enumera cinco comprobaciones que puede realizar en su propio entorno.

Puntos clave

  • La investigación preliminar de Binance señala como punto de entrada el equipo portátil comprometido de un ingeniero de DevOps, y Binance afirma no haber encontrado pruebas de una filtración de claves privadas de sus wallets. Ambas conclusiones son preliminares.
  • Un atacante que controla los sistemas que solicitan y aprueban firmas no necesita robar las claves.
  • El FBI y varias firmas de análisis de blockchain atribuyen el robo al grupo norcoreano TraderTraitor; la propia Binance no ha identificado a ningún atacante.
  • Las defensas más importantes protegen a las personas, los endpoints y los circuitos de aprobación que rodean a las claves, no solo las claves en sí.
  • El mismo patrón se aplica a consolas en la nube, SSH, pipelines de CI/CD y agentes de IA que pueden actuar en producción.

Qué ocurrió y qué sigue siendo preliminar

La firma de análisis de blockchain TRM Labs informa que los fondos empezaron a salir de las wallets de Binance hacia las 20:05 UTC del 29 de octubre, y que la mayor parte del valor se movió en unos 20 minutos. En su comunicado preliminar, recogido por BleepingComputer, Binance indicó que el incidente podría involucrar el equipo portátil comprometido de un ingeniero de DevOps, a través del cual el atacante llegó a un contenedor de servicio y envió transacciones de retiro no autorizadas. Binance suspendió los retiros, revocó la autorización afectada y comenzó a colaborar con las fuerzas del orden.

Desde entonces, Binance ha señalado que su investigación “ha descubierto puntos de intrusión adicionales”. El co-CEO Richard Teng afirmó que el ataque no fue obra de los permisos de un solo ingeniero y, según cita Elliptic, que “no pasó por nuestros controles de aprobación habituales”. Binance ha prometido un post-mortem detallado, que no se había publicado al momento de escribir este artículo (2 de noviembre).

AspectoSituación al momento de escribir
Cantidad afectadaUnos 6300 millones de dólares según la estimación de Binance; las firmas de análisis reportan entre 6360 y 6430 millones de dólares, según el método y los precios utilizados.
Punto de entradaPreliminar: el equipo portátil comprometido de un ingeniero de DevOps. Desde entonces, Binance ha informado de puntos de intrusión adicionales.
Filtración de claves privadasBinance afirma no haber encontrado pruebas de una filtración de claves privadas de sus wallets. La investigación continúa.
AutoríaEl FBI atribuyó el robo al grupo norcoreano TraderTraitor el 31 de octubre, en línea con TRM Labs, Chainalysis y Elliptic. Binance no ha identificado a ningún atacante.
Fondos congeladosCifra no definitiva. Binance habla de unos 3000 millones de dólares inmovilizados; Elliptic había verificado unos 2850 millones de dólares congelados o incautados on-chain al 1 de noviembre, en su mayoría stablecoins.
Impacto en los clientesBinance afirma que asumirá la pérdida y que los fondos de los usuarios están a salvo. Los retiros comenzaron a reabrirse por fases el 1 de noviembre.

Congelado no es lo mismo que recuperado. Los emisores de stablecoins como Tether y Circle pueden congelar los tokens que emiten, pero bitcoin, XRP y otros activos nativos no pueden congelarse de esa manera, y gran parte del valor robado sigue en proceso de blanqueo.

Por qué un endpoint privilegiado comprometido puede ser peor que una clave robada

Una clave privada robada es un problema grave, pero es un problema único y bien conocido: se rota la clave y la copia robada pierde la mayor parte de su valor. Un atacante que controla el dispositivo de un ingeniero con privilegios está en una posición distinta. Puede usar los sistemas que solicitan firmas de forma legítima, llamar a servicios internos con credenciales válidas y enviar transacciones que parecen operaciones normales.

La evidencia on-chain encaja con este panorama. TRM Labs concluyó que el patrón observado en muchas cadenas “apunta a un compromiso de la infraestructura de firma de las hot wallets de Binance”, es decir, que el atacante podía conseguir que los propios sistemas de Binance firmaran transacciones elegidas por él. En Ethereum, la firma de seguridad Blockaid descubrió que una hot wallet firmó un lote de autorizaciones EIP-7702 que cedieron el control de la wallet al contrato del atacante. Aún no se ha confirmado cómo se obtuvieron esas firmas; trataremos ese mecanismo en un artículo de seguimiento aparte.

Esto no es nuevo. En el robo a Bybit de febrero de 2025, que el FBI también atribuyó a TraderTraitor, los atacantes comprometieron el equipo de un desarrollador de un proveedor de wallets y manipularon la transacción que aprobaron los firmantes de Bybit. En ambos casos, las claves hicieron exactamente lo que se les pidió. La cuestión era quién lo estaba pidiendo.

Cinco comprobaciones defensivas

1. Separe los dispositivos privilegiados del trabajo diario

El dispositivo que se usa para aprobar cambios en producción, firmar transacciones o administrar la infraestructura no debería ser el mismo que se usa para el correo electrónico, el chat, la navegación y la instalación de herramientas de desarrollo. Utilice estaciones de trabajo de administración dedicadas y reforzadas o escritorios virtuales aislados, sin cuentas personales y con una lista corta de software aprobado. TraderTraitor ha recurrido repetidamente a ofertas de empleo falsas y pruebas de programación maliciosas para acceder a los equipos de los desarrolladores; un dispositivo separado mantiene ese tipo de compromiso lejos del circuito de aprobación.

2. Exija más de una persona y añada tiempo

Ninguna persona, dispositivo o cuenta de servicio debería poder mover por sí sola grandes cantidades de valor ni modificar producción. Exija la aprobación de personas en dispositivos distintos, establezca límites de valor por transacción y por ventana de tiempo, y añada un retardo (un timelock) para operaciones grandes o inusuales. Incluso un retardo de unos pocos minutos da a la supervisión y a las personas la oportunidad de reaccionar.

Consejo: Compruebe que los aprobadores vean lo que realmente están aprobando. En el caso de Bybit, los firmantes aprobaron una transacción cuyo contenido real había sido manipulado. La pantalla de aprobación debe mostrar la acción, el destino y la cantidad exactos, generados de forma independiente del sistema solicitante.

3. Refuerce los endpoints y vigílelos

Ejecute EDR en cada dispositivo privilegiado y asegúrese de que alguien revise sus alertas las 24 horas. Mantenga los sistemas al día con los parches, bloquee el software no firmado o no aprobado, use MFA resistente al phishing, como llaves de seguridad físicas, y limite el tiempo de validez de las sesiones de administración y los tokens. Considere las herramientas de desarrollo, incluidos paquetes, extensiones de IDE y asistentes de programación con IA, como parte de la superficie de ataque.

4. Detecte anomalías y tenga capacidad para congelar rápidamente

Los fondos de Binance se movieron en cuestión de minutos. Defina qué es lo normal en sus operaciones más sensibles, como volúmenes, destinos, horas del día y ritmos de firma, y genere alertas ante desviaciones en tiempo real. Prepare un mecanismo de parada de emergencia que pueda pausar retiros, despliegues o firmas en segundos, decida de antemano quién puede activarlo y practique su uso.

5. Audite quién y qué puede invocar firmas y acceso a producción

Elabore una lista de todas las personas, cuentas de servicio, contenedores, pipelines y claves de API que pueden solicitar una firma, aprobar un pago o modificar producción. Para cada elemento, compruebe si todavía necesita ese acceso, si el acceso tiene el alcance más limitado posible y si su uso queda registrado en un lugar que el atacante no pueda borrar. Elimine los privilegios permanentes siempre que pueda y utilice en su lugar acceso just-in-time.

Lecciones para la nube empresarial, SSH, CI/CD y las operaciones con IA

La mayoría de las organizaciones no gestionan hot wallets de criptomonedas, pero todas tienen algo equivalente: credenciales y sistemas que pueden actuar con autoridad.

  • Nube: el equipo portátil de un administrador con una sesión de consola activa o credenciales de CLI en caché es tan valioso como la cuenta root. Use credenciales de corta duración, sesiones vinculadas al dispositivo y flujos de aprobación para acciones destructivas o de alto impacto.
  • SSH: las claves de larga duración almacenadas en los equipos de los ingenieros dan al atacante acceso directo a los servidores. Prefiera certificados SSH de corta duración emitidos por sesión y registre de forma centralizada cada sesión privilegiada.
  • CI/CD: los pipelines suelen contener credenciales de despliegue y de firma. Proteja las definiciones de los pipelines con requisitos de revisión, separe las credenciales de compilación y de publicación, y exija aprobación para las publicaciones en producción.
  • Operaciones impulsadas por IA: los agentes de IA que pueden ejecutar comandos, abrir pull requests o llamar a API de producción son nuevas identidades privilegiadas. Asígneles credenciales propias con un alcance limitado, mantenga un paso de aprobación humana para las acciones sensibles y registre lo que hacen.

Consejo: Realice un ejercicio de simulación (tabletop) con una sola pregunta: “Si el equipo portátil de este ingeniero quedara completamente comprometido esta noche, ¿qué podría hacer el atacante antes de que alguien lo notara?” La respuesta muestra en qué puntos sus circuitos de aprobación dependen de un único dispositivo.

Qué vigilar a continuación

El post-mortem de Binance debería confirmar o revisar la hipótesis del equipo portátil, explicar cómo se obtuvieron las firmas y mostrar qué controles se eludieron. Hasta entonces, considere la causa raíz como preliminar. Las lecciones defensivas anteriores no dependen de los detalles finales: sea cual sea la ruta exacta, el atacante llegó a los sistemas que podían autorizar acciones sensibles.

Cómo puede ayudar LOGIQ

LOGIQ ayuda a las organizaciones a revisar el acceso privilegiado en servidores Linux, entornos en la nube y pipelines de CI/CD, y a diseñar controles de aprobación y supervisión que se ajusten a la forma en que sus equipos trabajan realmente. Si desea una segunda opinión sobre quién y qué puede actuar con autoridad en su entorno, contáctenos.

Fuentes