Binance explica su hackeo: una entrevista falsa y 6.340 millones

“Básicamente fue un ataque de phishing”, resumía Jokker en X. El informe inicial de Binance, publicado el 3 de noviembre, dice lo contrario con esas mismas palabras: no fue “un simple incidente de phishing”, sino una campaña por fases que empezó en junio. Y confirma lo que en nuestra primera crónica aún no estaba confirmado: hubo hackeo, y la cifra oficial es de unos 6.340 millones de dólares.

La cadena de ataque, fase a fase

Del tuit hay que matizar algo más. Dice que la IA sirvió para comprometer a “dos ingenieros más”, pero uno de los dos era el A de junio. Tampoco el informe menciona Google: habla de “un buscador” y enlaza, como ejemplo de la técnica, un análisis de SANS sobre un anuncio malicioso de Homebrew.

Setenta bytes de diferencia

El detalle más concreto del informe es lo que hizo la prueba técnica. Sustituyó un componente de pyenv, un gestor de versiones de Python muy común, por una copia maliciosa:

CREATE  /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv_
MODIFY  pyenv_ → 3,414 B
DELETE  .../libexec/pyenv  (3,344 B)   ← elimina el pyenv válido
RENAME  pyenv_ → pyenv  (3,414 B)      ← lo reemplaza por el malicioso
DELETE  /opt/homebrew/bin/pyenv  (3,414 B)
ln  (crea un enlace simbólico)  +  lanza zsh

La copia solo pesa 70 bytes más que el original. Según Binance, el malware ejecutaba comandos, hablaba con un servidor externo y borraba rastros. Lo califica de 0-day porque sus herramientas de protección de equipos no lo detectaron en ese momento.

Por qué no bastó con parar las retiradas

Entre las 20:05 y las 20:09 UTC, cinco hot wallets enviaron 233,46 millones de XRP al atacante. Después salieron unos 970.500 SOL, 44,2 millones de OP y 18.270 BTC.

Luego vino lo más difícil de frenar. El atacante usó el servicio de firma para abusar de EIP-7702, la función de Ethereum que permite delegar ciertos permisos de una cuenta en un contrato. Envió 50 transacciones de firma para manipular el nonce y dejar establecida esa delegación. A partir de ahí, ya no dependía de la infraestructura de Binance, así que suspender las retiradas no la anulaba.

Revocarla tampoco fue inmediato. La wallet usa computación multipartita (MPC), de modo que no hay una única clave privada con la que firmar la revocación, y el equipo tuvo que desarrollar un procedimiento específico. La última transferencia, de 2.961,9 ETH, se cerró a las 23:56 UTC. La delegación de Binance14 se limpió a las 00:10 UTC del 30 de octubre.

Así que “en minutos”, como dice el tuit, describe el grueso del robo, no su final. TRM calculó que la mayor parte salió en unos 20 minutos, pero la salida no se cortó del todo hasta casi cuatro horas después.

Lo que Binance no cuenta

Es el relato de la propia afectada, y deja huecos importantes:

• Qué herramienta de IA era y cómo se abusó de ella. Solo dice “herramienta interna de IA”. Sin saber qué permisos tenía o si hubo inyección de instrucciones, la frase más llamativa del informe no se puede evaluar.
• Por qué un portátil guardaba un token de despliegue con ese alcance. Tampoco explica qué controles debían haberlo impedido. Dice que revisa la “cobertura de la política de firma”.
• Indicadores de compromiso. No publica hashes, dominios ni el repositorio de la prueba, así que otras empresas no pueden buscarlos con este informe. Binance reconoce que reserva detalles técnicos.
• Una comprobación externa. La revisión de firmas independientes está aún por hacer. Las cifras y la reposición del 98 % son datos de Binance, que remite a su Proof of Reserves.

La atribución sí tiene respaldo externo. Binance enlaza una alerta del FBI, que no hemos podido abrir porque bloquea el acceso automático, y la AP ya recogió que el FBI señalaba a Corea del Norte y a TraderTraitor. El propio informe añade que Binance detectó y frenó 57 casos de amenazas vinculadas a ese país durante 2026, con cebos como entrevistas falsas, herramientas de desarrollo clonadas o videollamadas trucadas.

Lo que deberían mirar otras empresas

“Nunca uses el PC de la empresa para otras cosas”, cierra el tuit. Es buen consejo, pero el problema es mayor que el de un empleado despistado. El ingeniero A solo quería instalar una herramienta de trabajo, y bastó con el resultado de un buscador.

Las lecciones que se pueden sacar del informe son para quien gestiona la empresa:

1. Instalar software desde un buscador es un riesgo real. Conviene dar a los desarrolladores fuentes internas y aprobadas.
2. Un equipo limpio no elimina la exposición. Tras el incidente de junio, Binance cambió el equipo y las credenciales, pero el atacante ya sabía a quién dirigirse.
3. Las herramientas internas de IA también son infraestructura privilegiada. Merecen el mismo control de permisos que cualquier otro acceso a producción.
4. Los tokens de despliegue no deberían vivir en un portátil ni abrir camino hasta los sistemas que firman transacciones.
5. El plan de respuesta debe cubrir lo que ocurre en la cadena. Binance apagó sus sistemas, y la autorización maliciosa siguió activa.