El mayor robo de la historia del sector no empezó con un ataque informático sino con una oferta de trabajo. Binance detalló cómo se produjo la sustracción de alrededor de u$s6.300 millones y la reconstrucción desarma la imagen habitual del hackeo.
Hubo entrevistas por video, una falsa reclutadora que compartió fotos personales para generar confianza y una prueba técnica que el candidato descargó en su computadora laboral. Richard Teng, co-CEO del exchange, lo resumió sin eufemismos al señalar que "fue una campaña, construida durante muchos meses".
La secuencia que describió la compañía es meticulosa y cada paso tenía una función.
En septiembre, un ingeniero de software fue contactado a través de una plataforma legítima de empleo por alguien que se presentaba como director de proyecto. El primer filtro fue una entrevista por video con una supuesta representante de recursos humanos, que compartió una cuenta de redes sociales con fotos personales para construir credibilidad. No era un correo sospechoso ni un enlace dudoso. Era un proceso de selección que se veía normal.
La segunda instancia fue una entrevista con un presunto director ejecutivo. Y ahí llegó el pedido que cerró la operación. Se le solicitó al ingeniero descargar una tarea de programación en su computadora de trabajo, exactamente lo que cualquier proceso de contratación técnica pide de forma rutinaria.
"Esa tarea contenía un malware de día cero, es decir que explotaba una vulnerabilidad desconocida, y evadió la seguridad del dispositivo", relata a iProUP el experto en ciberseguridad Segundo Carranza. La descripción del vector la aportó Jimmy Su, director de seguridad de Binance.
El detalle que más preguntas abre sobre la respuesta de la compañía es que no hubo una sola puerta de entrada, y que una de ellas se conocía desde antes.
En junio, otro ingeniero instaló un paquete de Homebrew manipulado mientras buscaba una herramienta de inteligencia artificial. "Homebrew es un gestor de paquetes muy usado por desarrolladores en computadoras Mac, y la pieza alterada se descargó dentro de ese ecosistema", describe Carranza a iProUP.
Binance detectó ese incidente y reemplazó el dispositivo. Pero según su propia reconstrucción, el ingeniero y sus colegas del equipo de billeteras permanecieron expuestos. Es decir que el reemplazo del equipo no cerró la exposición del grupo.
El resto de la cronología muestra cuánto tiempo tuvo el atacante para moverse. El 20 de octubre, usando la máquina comprometida y una herramienta interna de inteligencia artificial de la propia compañía, los atacantes accedieron a las computadoras de dos ingenieros del equipo de billeteras. El 29 de octubre emplearon credenciales robadas para desplegar un contenedor y ejecutar un script malicioso. Y ese día los fondos empezaron a salir.
Guido Zatloukal, presidente de la Fundación Blockchain Argentina, había advertido a iProUP días atrás sobre exactamente ese fenómeno: "No porque la IA ataque, sino porque es una herramienta que tienen los atacantes para poder hacer ataques mucho más rápidos, buscar vulnerabilidades en software que antes no pensaba que existían". En este caso, la herramienta usada para el movimiento lateral era un sistema interno de la propia empresa atacada.
Para tomar control de una billetera operativa, el atacante usó EIP-7702, una propuesta de mejora de Ethereum que permite a una cuenta delegar capacidades de ejecución, según explicó Jimmy Su. Hasta ahí, una explotación sofisticada de una funcionalidad legítima del protocolo.
Lo revelador es lo que pasó después. Las billeteras operativas de Binance funcionan con computación multiparte, conocida por su sigla MPC, un esquema en el que la clave privada no existe completa en ningún lugar sino que está dividida entre varias partes que deben coordinarse para firmar. Es, en el estado del arte de la custodia institucional, la arquitectura más segura disponible, precisamente porque elimina el punto único de falla.
Y fue eso lo que complicó la respuesta. Al no haber una clave única, ninguna parte individual podía revocar el acceso del atacante por sí sola, lo que según la compañía extendió el tiempo de contención.
La contención se completó el 30 de octubre, cuatro horas y cinco minutos después de que empezaran a salir los fondos. En ese lapso se fueron alrededor de u$s6.300 millones.
Dicho de otro modo, la medida diseñada para que un atacante no pudiera robar con una sola clave también impidió que un defensor pudiera detenerlo con una sola clave. No es un argumento contra el MPC, que sigue siendo la mejor práctica del sector. Es una lección sobre el diseño de los protocolos de emergencia. Una arquitectura que distribuye el poder de firmar necesita un procedimiento de revocación tan rápido como el de autorización, y acá no lo hubo.
Los números de la respuesta se actualizaron respecto de los primeros días.
Según Richard Teng, co-CEO del exchange, se congelaron alrededor de u$s2.850 millones y la compañía restauró cerca del 98% de los tokens afectados utilizando fondos propios. El ejecutivo sostuvo que los usuarios no se verán afectados.
Esa cifra del 98% marca un avance respecto del 95% que la empresa informaba el 1 de noviembre, cuando reanudó los retiros. En esa reapertura, los usuarios sacaron u$s4.649 millones contra depósitos por u$s1.010 millones, con una salida neta cercana a los u$s3.640 millones, equivalente a alrededor del 2,1% de los u$s171.000 millones en activos bajo gestión que la compañía reportó en su última prueba de reservas.
Sobre la autoría, Binance vinculó el ataque a Corea del Norte y Teng señaló que el FBI hizo esa atribución. Las firmas de análisis TRM Labs y Chainalysis ya habían apuntado con alta confianza a TraderTraitor, una unidad de hackers patrocinada por ese Estado, el mismo grupo al que el FBI atribuyó el robo de u$s1.500 millones a Bybit en febrero de 2025.
Hay un dato que la compañía aportó y que sirve para dimensionar la presión que soporta. Binance afirma haber bloqueado 57 intentos sospechosos vinculados a Corea del Norte durante este año. Puesto en perspectiva, el atacante necesitó que funcionara uno de 58 intentos para concretar el mayor robo de la historia del sector. La asimetría entre atacar y defender no se mide en capacidad técnica sino en cuántas veces alcanza con acertar.
La compañía anunció además que incorpora expertos independientes de ciberseguridad para revisar el incidente.
Tres conclusiones prácticas se desprenden del informe y aplican mucho más allá de Binance.
La primera es sobre el eslabón humano. El ataque no explotó la blockchain ni comprometió claves privadas de billeteras, algo que la compañía remarcó expresamente. Explotó un proceso de contratación. Como había señalado Lemon al ser consultada por iProUP días atrás: "El problema estuvo en los sistemas y procesos internos de la plataforma" y "no fue una falla de la tecnología blockchain ni una filtración de claves privadas".
La segunda es sobre los dispositivos. Hubo un incidente detectado en junio, un dispositivo reemplazado y un equipo que siguió expuesto. La pregunta que queda abierta es qué protocolo se aplica cuando se detecta un compromiso en un equipo con acceso a sistemas críticos, y si reemplazar la máquina alcanza cuando el acceso pudo propagarse.
Y la tercera es sobre los tiempos de respuesta. Cuatro horas y cinco minutos fue lo que tardó la contención en una arquitectura de clave distribuida. En un sistema que mueve miles de millones por hora, el procedimiento de emergencia es tan importante como el de seguridad. El pedido que hizo Star Xu, fundador de OKX, en los días posteriores al ataque apuntaba justamente ahí, al reclamar estándares compartidos entre exchanges y demoras obligatorias para retiros grandes hacia direcciones desconocidas.
Para el usuario, la conclusión del episodio es la misma que dejó la cobertura de estos días. Binance cubrió las pérdidas porque tenía el balance y la decisión de hacerlo, no porque una norma la obligara ni un seguro la respaldara. Y el ataque que lo hizo posible empezó con alguien contestando un mensaje en una plataforma de empleo.