Hackeo de Binance 2026: cómo un portátil perdió 6.300 millones de dólares

Hagamos cuentas. El 29 de octubre a las 20:05 UTC, el dinero empezó a salir de las wallets de Binance. Unos 6.360 millones de dólares, y la mayor parte se fue en unos 20 minutos.

Eso sale a una media de 300 millones de dólares por minuto. Cinco millones de dólares por segundo. En lo que tardaste en leer este párrafo, alguien podría haberse comprado una isla pequeña. Con palmeras.

Lo reconozco: cuando leo el análisis de un hackeo, suelo esperar algo sacado de una película. Un zero-day, un exploit genial, un hacker con capucha. Este es mucho más mundano, y justo por eso da más miedo. Según el relato preliminar de la propia Binance, todo empezó con el portátil de un ingeniero.

No la blockchain. No la criptografía. Un portátil. Quizá uno igualito al tuyo.

La versión corta: el hackeo de Binance fue un ataque en el que los intrusos usaron el portátil comprometido de un ingeniero DevOps para llegar a la infraestructura interna del exchange y conseguir que el propio exchange firmara transferencias a sus direcciones. Según Binance, no se filtró ni una sola clave privada. Los atacantes no la necesitaban: el sistema firmaba obedientemente todo lo que se le pedía.

Vamos a ver cómo funciona esto, quién está detrás y, sobre todo, por qué esta historia importa a cualquiera que escriba código o esté aprendiendo a hacerlo.

Cronología del hackeo de Binance: 36 horas de preparación, 20 minutos de trabajo

Lo más llamativo de este ataque no es la cifra. Es lo tranquilo y metódico que fue. Los analistas de TRM Labs lo reconstruyeron a partir de los datos de la blockchain casi minuto a minuto.

• Mañana del 28 de octubre. La wallet del operador recibe tres pequeñas recargas a través de Tornado Cash, un mixer que hace imposible rastrear el origen de las monedas. Piensa en ello como dinero de bolsillo para las comisiones de gas.
• 29 de octubre. El operador despliega el código del ataque y lo prueba en dos wallets de test. Luego ensaya la versión final en una tercera y se devuelve a sí mismo el dinero de prueba. Muy pulcro.
• Unas cuatro horas después, el código ensayado aparece en una hot wallet de Binance.
• 20:05–20:23. El dinero sale de diez blockchains a la vez: XRP, Bitcoin, Solana, Tron, Ethereum y otras. Solo la wallet de Bitcoin entrega 18.270 BTC en una única transacción.
• Desde entonces hasta medianoche, la wallet de Ethereum del exchange "entrega" varias veces más los fondos que van llegando a la dirección del atacante.

La preparación llevó al menos 36 horas. Con tests, un ensayo general y un rollback de los fondos de prueba. Si cada release se probara con tanto cuidado, la mitad de los incidentes de producción del mundo simplemente desaparecerían.

Para hacerse una idea: el récord anterior era el hackeo de Bybit de febrero de 2025, con 1.500 millones de dólares. Binance perdió aproximadamente cuatro veces más.

Cómo un portátil se convierte en miles de millones

Para entender lo que pasó, necesitas saber una cosa sobre los exchanges.

Todo exchange de criptomonedas tiene cold wallets: almacenamiento offline donde está la mayor parte del dinero. Y tiene hot wallets: conectadas a la red y funcionando de forma automática. Esas se encargan de los pagos diarios a los clientes. Pulsas "Retirar", el servicio del exchange comprueba la solicitud, firma la transacción y el dinero sale.

Una hot wallet es como un cajero de banco con un sello de goma. No toma ninguna decisión. Sella todo lo que le pasan por la ventanilla correcta.

Según el primer relato de Binance, el camino del atacante fue este:

1. Se compromete el portátil de un ingeniero DevOps. Cómo exactamente, el exchange todavía no lo ha revelado.
2. A través de él, el atacante entra en un contenedor de servicio, un entorno aislado donde corre uno de los servicios internos del exchange.
3. Desde dentro, envía solicitudes de retiro que el sistema toma como propias y firma.

O sea, el atacante no tuvo que robar el sello. Simplemente se acercó a la ventanilla correcta.

Más tarde, Binance dijo que había encontrado puntos de entrada adicionales, y el co-CEO del exchange, Richard Teng, subrayó que no fue una "acción de un clic" y que el atacante no se limitó a aprovechar los permisos de un solo ingeniero. El exchange ha prometido un informe técnico cuando termine la investigación. TRM Labs, al ver firmas válidas apareciendo en diez blockchains en menos de media hora, considera que la explicación más probable es que se comprometiera la propia infraestructura de firma de las hot wallets.

Pero el punto de entrada que Binance nombró primero sigue siendo el mismo. Un portátil.

EIP-7702 explicado: cómo la wallet se puso a trabajar para otro

La parte más técnica y, sinceramente, más elegante del ataque ocurrió en Ethereum. Aquí es donde entró en juego EIP-7702.

La versión corta: EIP-7702 es un mecanismo de Ethereum que permite a una wallet normal "ponerse" temporalmente el código de un smart contract y ejecutar su lógica. Llegó con la actualización Pectra en mayo de 2025. La idea es buena: agrupar varias acciones en una sola transacción, dejar que otra persona pague la comisión por el usuario, hacer las wallets más fáciles de usar.

Pero para que una wallet se "ponga" el código de otro, necesita una autorización firmada. Y esa autorización incluye un nonce, el número de secuencia de transacciones de la wallet. La wallet envía una transacción nueva, el número avanza y la autorización vieja deja de servir.

La hot wallet de un exchange envía transacciones sin parar. Adivinar en qué número estará justo en el segundo exacto es prácticamente imposible. Entonces, ¿cómo lo resolvió el atacante?

Preparó 50 autorizaciones para 50 nonces consecutivos. Todas firmadas por la wallet de Binance. Como un ladrón que se presenta en la puerta no con una llave, sino con un llavero de cincuenta: alguna tiene que entrar.

Una entró. Poco más de tres minutos después, la wallet había entregado todo su saldo: 167.464 ETH más otros 63 tokens, incluidos más de 1.600 millones de USDT.

Y entonces llegó lo más retorcido. La autorización siguió vigente. La wallet ahora ejecutaba un código "aspiradora" que solo obedecía al atacante. Cada vez que llegaba dinero nuevo a la dirección de Binance, el atacante también se lo llevaba. Es como configurar el reenvío del buzón de otra persona: la gente sigue escribiéndole a su dueño, pero eres tú quien lee las cartas.

La lección para developers: cada funcionalidad potente es también una forma potente de hacer daño. EIP-7702 no es un "agujero". Funciona exactamente como se diseñó. El problema es quién tuvo la oportunidad de usarlo.

La carrera por el dinero: congelaciones vs. swaps

En cuanto el ataque salió a la luz, empezó la carrera.

Las stablecoins tienen algo que Bitcoin no tiene: las empresas que las emiten pueden congelar tokens en una dirección concreta. Tether, Circle, Ripple y otras empezaron a bloquear las direcciones del atacante. El Arbitrum Security Council movió a la fuerza los fondos de la wallet del atacante. Según la estimación de Binance, se congelaron unos 3.000 millones de dólares.

Mientras tanto, el atacante cambiaba a toda prisa stablecoins por ETH, que no se puede congelar. Y, según las cuentas de TRM, para hacerlo pagó más de un 10% por encima del precio de mercado. Cuando tienes a Tether pisándote los talones, no hay tiempo para regatear.

Binance detuvo los depósitos y retiros y prometió cubrir el agujero con su fondo de seguro SAFU y su propio capital: "Estas pérdidas no se trasladarán a los usuarios". Para el 1 de noviembre, el exchange dijo que había cubierto cerca del 95% del importe afectado y anunció una reapertura gradual de los retiros.

Parece que los clientes saldrán bien parados. Y la pregunta de "¿quién fue?" ya tiene respuesta.

TraderTraitor y Lazarus Group: hackers que hackean personas, no código

El 31 de octubre, el FBI declaró oficialmente que detrás del hackeo estaba Corea del Norte, en concreto el grupo TraderTraitor. También se le conoce como Lazarus Group, Jade Sleet y APT38. TRM Labs y Chainalysis habían llegado a la misma conclusión incluso antes. La propia Binance todavía no ha nombrado públicamente a los autores.

Mira los ataques sonados anteriores de este grupo y verás un patrón.

Bybit, febrero de 2025, 1.500 millones de dólares. Los atacantes no fueron a por el exchange, sino a por su proveedor de wallets, Safe{Wallet}. El Mac de un developer de Safe se infectó a través de un proyecto Docker con un nombre inocente sobre un simulador de inversión en bolsa, al parecer con ayuda de ingeniería social. A partir de ahí: acceso a AWS, tokens de sesión robados y JavaScript manipulado en la interfaz, que mostraba a los firmantes de Bybit una transacción "normal".

DMM Bitcoin, mayo de 2024, 308 millones de dólares. Según el FBI, el atacante se hizo pasar por recruiter en LinkedIn y envió a un empleado de Ginco, la empresa japonesa que gestionaba las wallets, un script de Python disfrazado de prueba técnica previa a la contratación. El empleado ejecutó el script. Fin de la partida.

¿Ves el patrón? Corea del Norte no rompe la criptografía. Eso es lento y caro. Es mucho más fácil hackear a una persona con acceso: un developer, un ingeniero DevOps, un admin. Y la forma más fiable de conseguir que un developer ejecute código ajeno es ofrecerle el trabajo de sus sueños.

Cómo se infectó exactamente el portátil del ingeniero de Binance todavía no se sabe, y nadie puede afirmar que fuera una prueba técnica falsa. Pero el manual de este grupo está muy bien documentado. Y afecta directamente a cualquiera que busque trabajo en tecnología.

Malware en entrevistas de trabajo falsas: la prueba técnica más peligrosa que te van a mandar

Ya en 2023, investigadores de Palo Alto Networks describieron una campaña norcoreana con un nombre de lo más elocuente: Contagious Interview. Desde entonces el esquema no ha hecho más que refinarse, y sus víctimas ya no son solo empleados de exchanges, sino developers normales y corrientes que buscan trabajo.

Más o menos funciona así:

1. Un "recruiter" te escribe por LinkedIn, Telegram o email. La empresa suena legítima, el sueldo está agradablemente por encima del mercado y el proceso es rápido.
2. Tras una llamada breve, te llega una prueba técnica. Tienes que descargar un repo, "ejecutar el proyecto en local y arreglar un par de bugs". O instalar "nuestra app de videollamadas".
3. Ejecutas npm install o lanzas un script de Python. Y en ese momento, en tu máquina corre código ajeno del que no has visto ni una línea. Su autor, en cambio, pensó muy bien cada una.

A partir de ahí, el malware busca todo lo que haya a mano: contraseñas del navegador, cookies de sesión, claves SSH, tokens de la nube, wallets de criptomonedas. Si es un portátil del trabajo con acceso a producción, enhorabuena: tu portátil acaba de convertirse en la puerta principal de la empresa de otros.

Lo peor es que una prueba técnica es el cebo perfecto. Quieres ejecutarla. Te pueden los nervios, vas con prisa, y lo último en lo que piensas es en qué hay dentro de package.json.

Señales de alarma:

• El sueldo está claramente por encima del mercado y el proceso es sospechosamente rápido: "vamos directo a la prueba técnica".
• La prueba hay que ejecutarla, no solo escribirla desde cero.
• Te piden instalar una "app especial para la llamada" en lugar de Zoom o Google Meet.
• El repo tiene scripts de instalación raros, código ofuscado o dependencias con erratas en el nombre.
• Te meten prisa: "la necesitamos hoy, hay que cubrir este puesto ya".

Cómo ejecutar una prueba técnica de programación de forma segura sin perder el sueño:

• Nunca en el portátil del trabajo. Y menos aún en una máquina con acceso a producción, a la nube o al dinero de otras personas.
• En aislamiento. Una máquina virtual o un contenedor Docker sin acceso a tu carpeta personal. Si sabes levantar un contenedor para el proyecto de otra persona, ya tienes una capa de protección que el developer de Safe no tenía. En el curso de Docker, es una de las primeras cosas que haces con tus propias manos.
• Primero lee, después ejecuta. Abre package.json y revisa la sección scripts, sobre todo preinstall y postinstall. Para la primera instalación existe npm install --ignore-scripts.
• Nada de wallets ni claves cerca. Una wallet de criptomonedas, las claves SSH de producción y una prueba técnica de desconocidos nunca deberían vivir en la misma máquina.
• Investiga a la empresa. La web, empleados reales en LinkedIn, el historial de la oferta. Cinco minutos en Google pueden valer más que cinco años de sueldo.

Y una nota especial para 2026: si le pasas una prueba técnica a un agente de IA, recuerda que el agente también puede ejecutar npm install. Al malware le da igual quién pulsó Enter, tú o Claude Code. Dejar que un agente ejecute código de un repo desconocido exige el mismo aislamiento que usarías tú.

Si ya tienes acceso a producción

Para quien trabaja en DevOps, backend o soporte de infraestructura, la lección de Binance pega todavía más fuerte: tu portátil forma parte del perímetro de la empresa. No es "mi equipo personal con el que, de paso, trabajo", sino literalmente una puerta a producción.

Esto es lo que significa en la práctica:

• Separa los entornos. La máquina del trabajo es para trabajar. Proyectos personales, pruebas técnicas, juegos y extensiones de navegador dudosas van a cualquier otro sitio.
• Mínimo privilegio. Necesitas acceso exactamente a aquello en lo que estás trabajando ahora mismo, y solo mientras trabajas en ello. Un acceso de admin permanente "por si acaso" es un regalo para los atacantes.
• Llaves de hardware y sesiones cortas. En el caso de Bybit, los atacantes esquivaron la autenticación de dos factores robando tokens de sesión ya activos. Cuanto menos dura una sesión, menos tiempo tiene quien la robó para usarla.
• Las operaciones críticas necesitan al menos dos pares de ojos. Ninguna cuenta debería poder retirar dinero o subir cambios al pipeline de pagos por sí sola.

Nada de esto suena a ciencia espacial. Y justo por eso tantas veces no se hace.

Qué significa esto si todavía estás aprendiendo a programar

Podrías leer esta historia como un thriller sobre miles de millones y Corea del Norte. Pero para quien programa, la lección es otra.

La seguridad no es una profesión aparte que queda lejos. Es entender qué hace realmente el código que ejecutas. Qué pasa cuando lanzas npm install. Qué es un contenedor y por qué no siempre aísla las cosas como crees. Dónde se guardan los tokens y por qué una cookie de sesión vale más que una contraseña.

Esa es la base. Ninguna IA la sustituye: te escribe un Dockerfile en un segundo, pero decidir si te fías de un repo de un "recruiter" sigue siendo cosa tuya.

Dónde aprender todo esto

Para leer historias como esta como una cadena clara de pasos y no como magia, necesitas los fundamentos.

En el curso de Docker montas contenedores con tus propias manos y descubres qué aíslan y qué no. Python y Java te dan una comprensión real de cómo funciona el código que ejecutas, incluido el que llega en un zip de tu "recruiter de ensueño". Y Web explica cómo funcionan esos mismos paquetes npm y el JavaScript del front-end.

Y si ahora mismo estás preparando entrevistas (de las de verdad, no de las norcoreanas), en nuestra guía de entrevistas para desarrolladores Java repasamos qué preguntan realmente en las entrevistas de Java en 2026.

A los hackers les basta con una persona descuidada con acceso. Asegúrate de no ser tú.

Preguntas frecuentes sobre el hackeo de Binance

¿Qué pasó en el hackeo de Binance de octubre de 2026? El 29 de octubre de 2026 se robaron unos 6.300 millones de dólares de las hot wallets de Binance en diez blockchains, el mayor robo de la historia de las criptomonedas. Según el relato preliminar del exchange, el ataque empezó con el portátil comprometido de un ingeniero DevOps, que el atacante usó para llegar a un servicio interno y enviar solicitudes de retiro no autorizadas.

¿Quién hackeó Binance? Según el FBI, el ataque lo llevó a cabo el grupo norcoreano TraderTraitor, también conocido como Lazarus Group, Jade Sleet y APT38. Los analistas de TRM Labs y Chainalysis llegaron a la misma conclusión. El mismo grupo estuvo detrás del hackeo de Bybit de 2025, con 1.500 millones de dólares.

¿Afectó el hackeo a los usuarios de Binance? Binance ha prometido cubrirlo todo por su cuenta, con su fondo de seguro SAFU y su propio capital, y no trasladar las pérdidas a los clientes. Se congelaron unos 3.000 millones de dólares con ayuda de los emisores de stablecoins. A fecha del 1 de noviembre, el exchange anunció una reapertura gradual de los retiros.

¿Qué es EIP-7702? Es un mecanismo de Ethereum introducido en mayo de 2025 que permite a una wallet normal ceder el control de sus operaciones al código de un smart contract. En el hackeo de Binance se usó para que la hot wallet del exchange ejecutara el código del atacante y le reenviara incluso los fondos nuevos que iban llegando.

¿Cómo detectar la prueba técnica de un falso recruiter? Desconfía si el sueldo está claramente por encima del mercado, el proceso es sospechosamente rápido, la prueba hay que ejecutarla en lugar de escribirla o te piden instalar una app especial para la llamada. Ejecuta código ajeno solo en una máquina virtual o un contenedor, nunca en el portátil del trabajo, y revisa antes los scripts de instalación.

¿Puede un agente de IA para programar ejecutar malware desde una prueba técnica? Sí. Si un agente lanza comandos como npm install en un repo desconocido, los scripts de instalación maliciosos se ejecutarán exactamente igual que si lo hubiera hecho una persona. Por eso solo deberías dejar que un agente trabaje con código ajeno en un entorno aislado.