El hackeo a Binance empezó con entrevistas de trabajo falsas y un instalador alterado de Homebrew, cinco meses antes de que saliera el primer dólar. Este martes 3 de noviembre la empresa publicó sus hallazgos iniciales y contó la cadena completa: ingeniería social, código malicioso en herramientas de desarrollo, una herramienta interna de inteligencia artificial vuelta contra su equipo y un servicio de firma usado fuera del proceso normal de retiros. Los activos afectados rondan los US$6.340 millones.
La pieza que faltaba era el cómo. Cuando el robo a Binance de US$6.300 millones se conoció a finales de octubre, la empresa confirmó el vaciado y prometió cubrir a los usuarios, pero la ruta de entrada quedó sin explicar. Esa explicación llegó hoy, con una admisión incómoda: el primer equipo comprometido se detectó en junio y el ataque siguió vivo por otra puerta.
Cinco meses de preparación antes del primer retiro
Todo arrancó en junio de 2026. Un ingeniero del equipo de infraestructura de billeteras, identificado solo como Ingeniero A, buscó en internet una herramienta popular de inteligencia artificial para programar y descargó un instalador de Homebrew manipulado. Homebrew es el gestor de paquetes que millones de desarrolladores usan en Mac. La descarga traía código malicioso y el equipo de seguridad detectó la anomalía: cambió el equipo y rotó las credenciales relacionadas.
Ese cierre llegó tarde en un detalle concreto. Para ese momento, el atacante ya conocía el rol del Ingeniero A y los nombres de sus compañeros del equipo de billeteras. Con ese mapa, la segunda fase apuntó en septiembre al Ingeniero B, contactado en una plataforma real de empleo por alguien que se presentó como director de proyecto de una empresa que no existe.
La puesta en escena tuvo dos rondas: una entrevista por video con una supuesta representante de recursos humanos que compartió fotos y videos personales para ganar confianza, y otra en una aplicación de chat con un supuesto director ejecutivo. Casi al final, el Ingeniero B recibió la instrucción de descargar una «tarea» en su computadora de trabajo: un repositorio que ejecutó código malicioso durante la instalación.
El programa intruso cambió un componente legítimo de pyenv, herramienta que administra versiones del lenguaje Python, por una copia envenenada, borró rastros y abrió comunicación con un servidor del atacante. Binance reconoció que su protección de equipos no detectó ese código en su momento. El 20 de octubre, desde esa computadora y abusando de una herramienta interna de inteligencia artificial, el atacante tomó el control de los equipos del Ingeniero A y de un tercer ingeniero, el Ingeniero C.
En el equipo del Ingeniero A apareció la pieza que faltaba: un token con permiso para desplegar contenedores. El 29 de octubre, entre las 17:15 y las 19:56 UTC, el atacante entró al equipo del Ingeniero C, usó las credenciales robadas, desplegó un contenedor y disparó el código que abrió el vaciado.
Suspender los retiros no bastó: el permiso vivía en la cadena
Con acceso al servicio interno de firma, las transferencias salieron por fuera del proceso normal de retiros. Entre las 20:05 y las 20:09 UTC del 29 de octubre, cinco billeteras calientes enviaron 233,46 millones de XRP a una dirección del atacante. Después salieron fondos de billeteras de Solana y de Optimism, y una billetera envió 18.270 bitcoin en una sola operación.
El truco más fino usó EIP-7702, mecanismo de Ethereum que permite a una cuenta delegar parte de su ejecución en un contrato inteligente sin entregar su clave privada. El atacante envió 50 transacciones de firma para acomodar el contador de operaciones y dejó instalada una delegación maliciosa: su código con derechos parciales sobre una billetera caliente. Por eso frenar los retiros no detuvo el daño: el permiso ya vivía dentro de la cadena de bloques, no en los sistemas de la empresa.
La billetera firmaba con computación multipartita, esquema que reparte la firma entre varias partes y no guarda una sola clave para revocar en el acto. Hizo falta un procedimiento especial: a las 00:10 UTC del 30 de octubre, Binance autorizó la dirección cero desde su billetera Binance 14 y limpió la delegación. La última transferencia no autorizada, de 2.961,9 ether, se confirmó a las 23:56 UTC.
El balance que la empresa defiende hoy tiene tres cifras. Unos US$2.850 millones quedaron congelados o interceptados. La empresa apartó más del 100 % del monto para cubrir a los usuarios y repuso el 98 % de los activos al 31 de octubre. Y el Buró Federal de Investigaciones (FBI) señaló ese día a los actores norcoreanos TraderTraitor como responsables, con conversión de fondos hacia ether.
La respuesta interna ya corre: el sistema de billeteras se reconstruyó en un entorno nuevo, la herramienta de inteligencia artificial comprometida se rehízo con controles nuevos, los equipos tocados se reemplazaron y las credenciales quedaron fuera de servicio. Binance añadió escaneos reforzados y dijo haber frenado este año 57 casos sospechosos vinculados a Corea del Norte con señuelos parecidos.
Queda una lección práctica para cualquier equipo de desarrollo: una entrevista que pide correr código en la computadora de trabajo ya es una señal de ataque, y un token de despliegue en una portátil vale tanto como la llave de la bóveda. Los hallazgos siguen siendo iniciales, la revisión independiente sigue pendiente y la empresa retiene parte de los detalles técnicos para no regalarle el manual al próximo atacante.
Fuente: The Hacker News
