El 29 de octubre de 2026 salieron de las hot wallets de Binance unos 6.300 millones de dólares en criptoactivos. Es el hackeo a Binance más grande de la historia del ecosistema, más de cuatro veces lo que Lazarus le sacó a Bybit en 2025. El FBI se lo atribuyó a Corea del Norte tres días después.
Lo primero que circuló fue la versión fácil: «un empleado abrió un archivo infectado». Es una historia cómoda porque deja todo en una sola persona y un solo clic. Pero el hackeo a Binance no empezó con un clic, y quedarnos con eso nos impide aprender lo que importa.
La cronología del hackeo a Binance: meses de trabajo, no un clic
Según el informe preliminar de Binance, la campaña tuvo varias etapas:
- Junio. Un ingeniero buscaba una herramienta de IA para programar e instaló un paquete de Homebrew adulterado. Seguridad lo detectó, cambió el equipo y rotó credenciales. Aun así, los atacantes ya sabían quién era, qué hacía y quiénes eran sus compañeros en el equipo de wallets.
- Septiembre. Un ingeniero recibió una oferta por una plataforma de empleo legítima. Hubo una entrevista con «Recursos Humanos» y otra con un supuesto CEO, quien le pidió descargar una prueba técnica. La corrió en su computadora de trabajo. Traía malware a medida que ningún antivirus detectó.
- 20 de octubre. Desde esa máquina, y usando una herramienta interna de IA, los atacantes tomaron control de los equipos de dos ingenieros más. En uno encontraron lo que buscaban: un permiso para desplegar contenedores.
- 29 de octubre. Desplegaron un contenedor con un script malicioso, alcanzaron el servicio de firma de wallets y, usando EIP-7702 de Ethereum, se dieron permisos de ejecución sobre una hot wallet. Los fondos salieron por fuera del flujo normal de retiros. La contención tardó unas cuatro horas.
Pero en esas empresas capacitan en compliance y PCI-DSS…
Sí, y es justo la pregunta correcta. Binance dice que en 2026 bloqueó 57 intentos vinculados a Corea del Norte, muchos con este mismo truco de la entrevista falsa. La capacitación existía y los controles también: el acceso por rol hizo que el primer ingeniero no tuviera los permisos necesarios.
El problema es que los controles no fallaron de golpe, se fueron erosionando:
- Se instaló software no aprobado en un equipo corporativo.
- Se usó la máquina de trabajo para un proceso de selección de otra empresa.
- Una herramienta interna permitía saltar a los equipos de otros colegas.
- Un token de despliegue vivía en una laptop en lugar de estar atado a un hardware o a una aprobación de varias personas.
Ninguna de estas faltas habría vaciado una wallet por sí sola. Juntas, sí.
¿Fue un trabajo interno?
Es sano preguntárselo, y hay gente haciéndolo. La velocidad impresiona: en tres minutos el atacante depositó 60 millones de USDT en Aave y pidió prestados casi 19.800 ETH, porque el ETH no tiene un emisor que lo pueda congelar. Tether tardó 37 minutos en congelar la wallet principal.
Pero esa velocidad no prueba complicidad interna. Prueba preparación. TRM Labs detectó movimientos en Tornado Cash más de 36 horas antes del robo. Y las solicitudes de congelamiento de Tether son visibles on-chain mientras esperan las firmas del multisig: un bot bien hecho puede reaccionar en segundos. Lazarus no es una persona, es una organización con equipos especializados en ingeniería social, malware y lavado. Que haya «un grupo» detrás no significa que haya gente adentro.
¿Hay preguntas abiertas? Claro. La cronología viene de la propia Binance y todavía no la verificó un tercero independiente, aunque la empresa anunció una auditoría externa. Vale la pena seguirla con espíritu crítico, sin convertir a un empleado en culpable de algo que fue una falla sistémica.
Lo que esto nos enseña a todos los que trabajamos en tecnología
Las políticas de seguridad parecen burocracia hasta que ves lo que cuesta saltártelas. Algunas lecciones concretas:
- La computadora de la empresa es solo para la empresa. Nada de pruebas técnicas de otros empleadores, side projects ni repos para ver qué onda.
- Solo software aprobado. Si una herramienta de IA te encanta, pídela por el canal oficial. Los atacantes saben que los devs andan buscando herramientas nuevas.
- Sospecha de las ofertas demasiado buenas. Si te contactan por tu experiencia en una empresa específica, te están eligiendo por tu acceso.
- Mínimo privilegio, en serio. Los tokens de deploy en infraestructura crítica deben estar atados a hardware, ser de corta duración y requerir aprobación de varias personas.
- Segmenta las herramientas internas. Si una herramienta puede saltar entre los equipos de tus colegas, también se la puede pasar a un atacante.
- Reporta sin miedo. Una cultura que castiga los errores hace que la gente los esconda. Una que los premia los detecta en junio y no en octubre.
Conclusión
Binance va a cubrir las pérdidas y ya congeló o interceptó cerca de 2.850 millones. La mayoría de las empresas no tiene ese colchón. Para ellas, la diferencia entre un susto y una quiebra está en algo mucho menos glamoroso que la criptografía: que cada persona del equipo siga las reglas, incluso cuando parecen exageradas.
La próxima vez que una política de compliance te parezca un trámite, acuérdate de que alguien la escribió pensando en un caso como este.
Fuentes
CoinDesk, The Block, BleepingComputer, TechCrunch, Tom’s Hardware, Decrypt, BeInCrypto y Bitcoin.com News.
La información es orientativa y no constituye asesoría legal.
