Una falsa entrevista de trabajo ayudó a abrir la puerta a la infraestructura de wallets de Binance: el empleado descargó un supuesto ejercicio de programación que instaló malware, y los atacantes terminaron usando credenciales internas y una herramienta de inteligencia artificial de la empresa. Binance atribuye a esa cadena el robo del 29 de octubre; las estimaciones publicadas oscilan entre 6.300 y 6.430 millones de dólares, según la fuente y el método de valoración.
El caso no se reduce a un archivo malicioso ni a un fallo de una herramienta de IA. La reconstrucción de Binance, publicada el 3 de noviembre, describe una intrusión preparada durante meses, que combinó el compromiso de dos ingenieros, el acceso a otros empleados y la capacidad de operar sobre el servicio de firma de wallets. El FBI identificó a los responsables como TraderTraitor, una unidad norcoreana; TRM Labs también atribuyó el ataque a ese grupo.
Dos caminos de entrada y una escalada interna
La secuencia tuvo un antecedente en junio. Según Binance, un ingeniero descargó un instalador manipulado que, al parecer, se difundía mediante un anuncio malicioso de Google. The Hacker News detalla que se trataba de un instalador de Homebrew usado para instalar una herramienta de IA. Binance detectó esa primera infección y sustituyó el dispositivo, pero la información sobre el puesto del ingeniero y sus compañeros del equipo de wallets ya había quedado expuesta.
En septiembre, otra persona contactó con un segundo ingeniero a través de una plataforma legítima de búsqueda de empleo, haciéndose pasar por responsable de proyectos. La trama avanzó con entrevistas: primero intervino alguien que decía trabajar en recursos humanos y compartió un perfil con fotos y vídeos personales para ganar confianza; después, otra persona se presentó como director ejecutivo de una empresa ficticia. El supuesto candidato recibió entonces un ejercicio de programación alojado en un repositorio de código.
El repositorio ejecutaba código malicioso durante la configuración. De acuerdo con BleepingComputer, el malware sustituyó el ejecutable legítimo pyenv en la instalación de Homebrew por una versión alterada, cambió su enlace simbólico y la utilizó para iniciar un proceso de Z shell. Así podía ejecutar órdenes recibidas desde un servidor controlado por los atacantes. Binance dijo que el programa recurrió a técnicas de ofuscación y evasión, y que eliminó rastros de la infección para dificultar su investigación.
La cadena que describe Binance conecta los dos equipos comprometidos con el acceso posterior a la infraestructura de wallets:
flowchart TD A["Instalador manipulado en junio"] --> B["Datos del equipo expuestos"] C["Entrevista falsa en septiembre"] --> D["Ejercicio con malware"] D --> E["Equipo del ingeniero comprometido"] B --> F["Herramienta interna de IA abusada"] E --> F F --> G["Acceso a dos empleados más"] G --> H["Credenciales y token de despliegue"] H --> I["Servicio de firma de wallets"] I --> J["Transferencias no autorizadas"]
La herramienta de IA fue un tramo de la cadena
El 20 de octubre, según Binance, los atacantes aprovecharon el equipo comprometido y una herramienta interna de IA para llegar a otros dos empleados vinculados a la infraestructura de wallets. Obtuvieron credenciales y un token de despliegue de contenedores. The Hacker News recoge que el token estaba en el equipo del primer ingeniero comprometido, mientras BleepingComputer explica que las credenciales robadas se usaron después para desplegar un script malicioso.
El 29 de octubre, entre las 17:15 y las 19:56, los atacantes iniciaron sesión en el ordenador de un tercer empleado, desplegaron un contenedor y activaron el script, según el horario que publica Binance. El acceso al servicio de firma de wallets permitió generar transacciones fuera del proceso habitual de retirada. TRM Labs observó movimientos desde wallets de Binance en diez blockchains y consideró que la amplitud de las firmas válidas apuntaba a un compromiso de la infraestructura de firma en caliente.
Binance no ha publicado una causa raíz técnica que explique cómo se obtuvo ese acceso. Tampoco se ha detallado qué función cumplía la herramienta interna de IA ni por qué pudo ayudar a los atacantes. El dato disponible es más acotado: la empresa afirma que se abusó de ella para controlar cuentas de otros empleados. Presentar la IA como origen del robo iría más allá de lo que Binance ha explicado.
“It was not a single isolated breach or a simple phishing incident,”
— Binance
La respuesta anunciada por Binance incluye reconstruir el sistema de wallets afectado en un entorno nuevo, rehacer la herramienta interna de IA y sus controles de acceso, reemplazar dispositivos comprometidos y revocar credenciales y tokens. La empresa también dijo que reforzó los controles de riesgo del servicio de wallets y amplió la detección de anomalías de comportamiento, incluida la basada en IA.
Por qué detener las transferencias no bastó
El robo no se limitó a Ethereum. TRM calcula que salieron aproximadamente 6.360 millones de dólares de wallets de Binance en diez redes; BleepingComputer habla de unos 6.340 millones y The Hacker News de 6.430 millones. Son cifras distintas, no una cantidad única confirmada en todas las publicaciones. TRM valoró cada transferencia al precio del activo en el momento del robo y señaló que esos mismos activos valían unos 6.230 millones de dólares a precios posteriores.
En Ethereum, TRM identificó una autorización EIP-7702 que permitió convertir una hot wallet de Binance en un mecanismo de barrido controlado por el atacante. El grupo había preparado 50 autorizaciones firmadas para distintos valores consecutivos del contador de transacciones de la wallet; una seguía siendo válida al ejecutarse. El contrato envió después los fondos a una dirección del atacante y volvió a barrer depósitos posteriores.
Binance explicó que el uso de MPC en la hot wallet implicaba que no existía una clave privada única cuya revocación pudiera cancelar de inmediato las autorizaciones EIP-7702 maliciosas. Esa limitación ayuda a entender por qué la suspensión de retiradas no detuvo todas las salidas: según BleepingComputer, los atacantes continuaron aprovechando la autorización mientras Binance interrumpía retiradas en varias redes. Las demás cadenas también registraron transferencias firmadas, un patrón que llevó a TRM a situar el problema en la infraestructura de firma y no solo en una autorización de Ethereum.
La intervención de terceros contuvo parte del daño. Binance dijo que alrededor de 2.850 millones de dólares en activos robados habían sido congelados o interceptados, y que el 98 % de los tokens afectados se había repuesto al 31 de octubre; la empresa seguía completando el 2 % restante. TRM contabilizó cerca de 2.700 millones congelados en cadena en su análisis inicial del 30 de octubre. Sus cifras describen momentos y categorías de activos distintos, por lo que no deben tratarse como una misma medición.
Lo que cambia para los equipos de desarrollo y custodia
Para los equipos de desarrollo, el episodio pone en primer plano una ruta de acceso menos llamativa que un ataque directo a producción: una tarea de selección de personal que conduce a ejecutar código en un ordenador de trabajo. En este caso, el dispositivo tenía conexión con información y personas relacionadas con la infraestructura de wallets. Binance dijo que la infección inicial de junio expuso información sobre el puesto de un ingeniero y sus compañeros; en septiembre, otro ingeniero fue objetivo de una entrevista laboral falsa.
El riesgo empresarial aparece en el encadenamiento de permisos. Una cuenta comprometida no tuvo que vaciar por sí sola los fondos: el acceso a otros empleados, las credenciales y un token de despliegue condujeron al servicio que firmaba transacciones. Por eso Binance enumera controles en varios puntos —dispositivos, accesos internos, herramientas de IA y servicio de wallets— en vez de atribuir la solución a un único producto de seguridad.
TRM recomienda a exchanges y equipos de cumplimiento vigilar las direcciones vinculadas al atacante, y a los equipos de tesorería controlar las delegaciones EIP-7702 en wallets compatibles con Ethereum. También propone rechazar autorizaciones EIP-7702 que no estén previstas y separar las políticas de firma por cadena y por nivel de wallet. Son medidas propuestas por TRM; Binance, por su parte, ha comunicado que reconstruyó sistemas afectados y reforzó sus controles.
Binance afirmó que las entradas identificadas en la ruta del ataque ya se habían cerrado y que los sistemas afectados se reconstruyeron o reemplazaron. La empresa dijo también que las retiradas se habían reanudado ampliamente; los activos aún bajo control de los atacantes seguían siendo objeto de seguimiento por parte de TRM.
Fuentes: The Verge, BleepingComputer, The Hacker News, TRM Labs
