El hackeo de Binance del 29 de octubre de 2026 se llevó unos 6.300 millones de dólares de las carteras calientes (hot wallets) del exchange en aproximadamente 20 minutos. No se vulneró ninguna blockchain. Hackers norcoreanos accedieron a los sistemas que rodean las carteras de Binance y, al parecer, consiguieron que el propio software del exchange aprobara las transferencias.
La mayoría de las noticias sobre el hackeo de Binance se han centrado en quién robó el dinero y cuánto se ha recuperado. Sin embargo, las empresas que desarrollan u operan productos cripto necesitan saber por dónde entraron los atacantes. Ese punto de entrada importa porque una blockchain acepta cualquier transferencia con una firma válida y nunca comprueba quién pidió la aprobación.
El equipo de desarrollo blockchain de Redwerk crea carteras, flujos de pago y contratos inteligentes. A continuación encontrará nuestro análisis técnico de cómo funcionó el ataque, por qué afectó a las hot wallets y cómo proteger cada capa de una plataforma cripto.
¿Qué ocurrió en el hackeo de Binance?
En la tarde del 29 de octubre, los atacantes vaciaron hot wallets de Binance en 10 blockchains, entre ellas Bitcoin, Ethereum, Tron y Solana. Una hot wallet permanece en línea para que un exchange pueda pagar las retiradas de los clientes en cuestión de minutos. Con unos 6.300 millones de dólares, el robo es el mayor hackeo cripto registrado, más de cuatro veces los 1.500 millones de dólares sustraídos al exchange Bybit en 2025.
Dos días después, el FBI señaló a Corea del Norte como responsable del robo de más de 6.000 millones de dólares e identificó a los atacantes como un grupo al que denomina TraderTraitor. Para frenar el blanqueo, la agencia publicó 628 direcciones de cartera vinculadas a los fondos robados, la mayoría en Ethereum. La alerta pedía a los exchanges, a los servicios de finanzas descentralizadas (DeFi) y a otras empresas cripto que bloquearan cualquier transacción relacionada con esa lista.
Parte del dinero robado aún podía detenerse, porque emisores de stablecoins como Tether y Circle pueden bloquear sus propios tokens respaldados por dólares. El bloqueo empezó menos de una hora después del inicio del ataque y, según Chainalysis, para el 30 de octubre ya se habían congelado unos 2.800 millones de dólares. A diferencia de esos tokens, Ether no tiene un emisor central, así que los atacantes se apresuraron a cambiar stablecoins por Ether mientras aún podían.
Binance prometió que los clientes no asumirían la pérdida y la cubrió con dos fondos de reserva y su propia tesorería. Aun así, los clientes retiraron un neto de 3.600 millones de dólares, alrededor del 2,1 % de los activos del exchange, el 1 de noviembre, el primer día en que se reabrieron las retiradas.
¿Cómo burlaron los atacantes la seguridad de firma de transacciones de Binance?
Las pruebas disponibles hasta ahora sugieren que los atacantes tomaron el control del sistema que firma las transferencias de Binance. Ese control bastaba, porque cada transferencia cripto solo necesita una firma digital generada con la clave privada de la cartera, un código secreto que demuestra que el titular aprobó el pago. Los grandes exchanges guardan esas claves dentro de un servicio de firma que gestiona miles de retiradas al día sin intervención humana.
Según Binance, la brecha pudo empezar en el portátil comprometido de un ingeniero DevOps. Los ingenieros DevOps gestionan los servidores y las herramientas que mantienen en funcionamiento el software de un exchange. Desde ese portátil, los atacantes habrían llegado a un contenedor de servicio, un pequeño programa aislado dentro de la infraestructura de Binance, y lo habrían usado para enviar retiradas. Al mismo tiempo, el exchange afirmó no haber encontrado pruebas de que se filtrara ninguna clave privada de cartera. A medida que avanzaba la investigación, el co-CEO Richard Teng informó de que su equipo había descubierto puntos de intrusión adicionales. Añadió que los atacantes también habían utilizado herramientas que borraban sus propias huellas por el camino.
Desde el punto de vista de la blockchain, una clave robada y un firmante secuestrado parecen lo mismo. Una clave robada permite a un tercero generar firmas, mientras que un servicio de firma secuestrado hace que la clave auténtica apruebe todo lo que envía ese tercero. En ambos casos, cada transferencia parece debidamente autorizada.
Por eso, cada una de las 10 blockchains registró las transferencias exactamente como estaba previsto. El punto débil estaba en los dispositivos, el software y los permisos de acceso que rodean a los registros. Los investigadores creen que un único sistema de firma daba servicio a las carteras de Binance en todas las cadenas, lo que explicaría cómo una sola brecha abrió todas esas carteras en cuestión de minutos. Un cifrado robusto protege las claves, pero la seguridad de la firma de transacciones también depende de cada dispositivo y cada cuenta que pueden enviar una solicitud al firmante.
¿Qué papel desempeñó EIP-7702 en Ethereum?
En Ethereum, los atacantes dieron un paso más con EIP-7702, una función incorporada a la red en 2025. Esta función permite que una cartera normal ejecute el código de un contrato inteligente, un programa que reside en la blockchain y funciona exactamente como está escrito. Para activarla, el titular firma una autorización y, a partir de ese momento, las instrucciones del contrato se aplican cada vez que alguien llama a la cartera.
Los atacantes consiguieron que una de las hot wallets de Binance firmara una autorización de este tipo para un contrato que solo aceptaba órdenes suyas. Con eso en marcha, una sola transacción vació la cartera de unos 2.500 millones de dólares, según análisis on-chain. El contrato mantuvo el control hasta que Binance firmó una nueva autorización casi cuatro horas después.
EIP-7702 es en sí una herramienta legítima, que las empresas utilizan para pagar las comisiones de red de sus clientes o para agrupar varias acciones en una sola. Sin embargo, para un exchange, cada nueva función de cartera es también una nueva vía para mover fondos.
Hot wallet frente a cold wallet: ¿por qué solo se vaciaron las hot wallets?
En el hackeo de Binance, los atacantes solo pudieron llegar a las hot wallets, porque estas permanecen conectadas a los sistemas automáticos de pago del exchange. En cambio, una cartera fría (cold wallet) guarda sus claves en un dispositivo que nunca se conecta a internet. Cualquier transferencia desde el almacenamiento en frío requiere la aprobación manual de personas, a menudo en varias ubicaciones.
Por eso, la mayoría de los exchanges mantienen en frío el grueso de los fondos de los clientes y dejan en línea una parte menor, para que las retiradas sigan llegando en minutos. Ese reparto es un equilibrio entre velocidad y exposición, ya que cada vía de pago automatizada también ofrece a un atacante un objetivo. Cualquier empresa que custodie criptomonedas de sus clientes se enfrenta a la misma decisión, desde las plataformas de trading hasta los proyectos de desarrollo de apps de banca cripto.
La seguridad de las hot wallets empieza por asignar a cada tipo de cartera una función clara. La siguiente tabla compara el almacenamiento en caliente y en frío en seis aspectos prácticos.
Acceso a la red
En línea y conectada a los sistemas de pago
Sin conexión, en hardware aislado de la red
Aprobación de transferencias
Software, de forma automática
Personas, mediante pasos manuales
Uso habitual
Retiradas diarias de los clientes
Almacenamiento a largo plazo de la mayor parte de los fondos de los clientes
Velocidad de pago
Minutos
Horas o días
Riesgo principal
Toma de control remota del firmante o de las cuentas que lo controlan
Robo físico, abuso interno o errores de manipulación
Control de pérdidas
Poco dinero en línea y límites a las salidas por hora
Aprobación de varias personas en lugares distintos
Mantener poco dinero en las hot wallets limita los daños, pero solo si el sistema de firma no puede transferirles más fondos desde el almacenamiento en frío cuando un atacante lo pide. Por eso, las recargas deben seguir importes fijos, un calendario regular y direcciones de destino aprobadas de antemano. Estas reglas son más fáciles de añadir mientras el sistema de carteras aún se está diseñando. Además, es uno de los principales factores del coste de desarrollo de una app de exchange de criptomonedas.
¿Qué debe cambiar en la seguridad de los exchanges de criptomonedas?
La seguridad de un exchange de criptomonedas debe abarcar todos los sistemas que pueden solicitar una firma, desde los portátiles de los ingenieros hasta las propias carteras.
¿Quién puede acceder al sistema de firma?
Según las informaciones, el hackeo de Binance empezó en el portátil de un ingeniero, lo que convierte los dispositivos del personal en parte de las defensas de un exchange. Los equipos que gestionan sistemas en producción necesitan un acceso limitado, temporal y registrado:
- Dispositivos separados para trabajar en sistemas en producción, sin correo electrónico ni navegación cotidiana
- Inicio de sesión con llaves de seguridad físicas, pequeños dispositivos que las páginas de inicio de sesión falsas no pueden engañar
- Acceso concedido para una sola tarea cada vez y retirado automáticamente al terminar el trabajo
- Ninguna cuenta capaz de acceder por sí sola al servicio de firma
- Un registro de cada cambio en los sistemas en producción, almacenado donde los ingenieros que lo hicieron no puedan editarlo
Las reglas de acceso solo se cumplen cuando los sistemas las aplican automáticamente, por eso configurarlas es una parte esencial del trabajo de consultoría DevOps.
¿Puede el servicio de firma rechazar una solicitud indebida?
Un servicio de firma debe comprobar cada solicitud según reglas que aplica él mismo, para que un servidor hackeado en otra parte del sistema no pueda simplemente ordenar un pago. Las reglas que mejor funcionan son sencillas:
- Límites a la cantidad que cada cartera puede enviar por hora y por día
- Una lista aprobada de destinos para las transferencias entre las propias carteras del exchange
- Aprobación adicional para importes elevados por parte de personas que trabajan en sistemas separados
Las carteras multifirma y la computación multipartita son dos formas habituales de repartir el control, de modo que varios aprobadores independientes deben estar de acuerdo antes de que se muevan los fondos. Sin embargo, si un solo servidor comprometido puede reunir todas las aprobaciones, el reparto no aporta nada.
¿Con qué rapidez puede detectar un vaciado de fondos?
En el caso de Binance, la mayor parte del dinero salió en 20 minutos, mucho antes de las primeras congelaciones. La monitorización tiene que reaccionar más rápido:
- Alertas ante salidas inusuales, como un aumento repentino de las retiradas, nuevas direcciones de destino o fondos que salen de varias cadenas a la vez
- Una pausa automática de las retiradas cuando varias de esas alertas se activan simultáneamente
- Contactos en emisores de stablecoins y empresas de análisis blockchain, acordados antes de cualquier incidente
- Un recuento claro de cuánto dinero de las hot wallets está en tokens que un emisor puede congelar
Una pausa automática a veces también detendrá retiradas legítimas. Aun así, un breve retraso para los clientes cuesta mucho menos que una cartera vacía, así que merece la pena fijar un umbral de alerta bajo.
¿Qué funciones de cartera permite su exchange?
Antes de que las hot wallets utilicen una función como EIP-7702, el equipo de seguridad debe decidir si el exchange realmente la necesita. Si la respuesta es sí, las reglas deben establecer a qué contratos puede una cartera conceder autorizaciones y quién aprueba cada cambio. Una hot wallet normal no contiene código de programa, así que cualquier cartera que de repente lo adquiera debería activar una alerta.
¿Con qué frecuencia se pone a prueba toda la configuración?
Muchas revisiones de seguridad cripto se centran en el código que reside en la blockchain. Una lista de control para auditar contratos inteligentes cubre bien esa capa, pero el hackeo de Binance empezó en otro lugar. Una revisión completa también analiza el servicio de firma, las herramientas de nube y de despliegue, y cada cuenta con acceso a los sistemas en producción.
Cuando Redwerk realiza una auditoría de desarrollo de software en una plataforma cripto, nuestros ingenieros siguen cada ruta que puede terminar en una firma. Nuestro equipo ha realizado un trabajo similar para Freenet, una red peer-to-peer de código abierto diseñada para el anonimato. Allí investigamos las vulnerabilidades de la plataforma y añadimos protección contra solicitudes falsificadas en uno de sus plugins. Tras una auditoría, el cliente recibe una lista priorizada de hallazgos y decide qué correcciones van primero.
¿Sigue siendo segura la blockchain tras el hackeo de Binance?
Sí, las propias blockchains siguieron siendo seguras. Sus registros públicos incluso jugaron a favor de los investigadores, porque cada moneda robada dejó un rastro que las empresas de análisis y el FBI pudieron seguir. El riesgo está en los sistemas de cada empresa, y la mayoría de los exchanges, proveedores de carteras y apps cripto dependen del mismo tipo de configuración de firma.
La respuesta práctica es trazar cada ruta que puede llevar a una firma y hacer que cada vía sea difícil de explotar. Si desea una visión externa de su propia configuración de firma, pida una revisión a nuestros ingenieros.
Preguntas frecuentes
¿Qué causó el hackeo de Binance?
El hackeo de Binance de octubre de 2026 comenzó dentro de la propia infraestructura del exchange. Según Binance, los atacantes pudieron entrar a través del portátil comprometido de un empleado y llegar a un sistema capaz de solicitar retiradas. Desde ahí, el software de firma de Binance aprobó sus transferencias, de modo que unos 6.300 millones de dólares salieron por canales que controlaba el propio exchange. Más tarde, la empresa informó de puntos de intrusión adicionales, y su informe completo seguía pendiente a principios de noviembre de 2026.
¿Quién estuvo detrás del hackeo de Binance?
El FBI atribuye el hackeo de Binance de octubre de 2026 a Corea del Norte y señala a un grupo respaldado por el Estado al que denomina TraderTraitor. El grupo se vincula ampliamente con Lazarus Group y ha atacado en repetidas ocasiones a empresas cripto, incluido el robo de unos 1.500 millones de dólares a Bybit en 2025. Las empresas de análisis habían llegado a la misma conclusión un día antes que el FBI, después de que fondos robados a Binance se mezclaran on-chain con dinero de un robo norcoreano anterior.
Hot wallet frente a cold wallet: ¿cuál es más segura?
Para guardar grandes cantidades, una cold wallet es más segura, porque sus claves privadas se almacenan sin conexión y cada transferencia requiere aprobación manual. Una hot wallet renuncia a parte de esa protección a cambio de velocidad. El software puede aprobar sus pagos al instante, así que un atacante remoto que controle ese software puede hacer lo mismo. Los exchanges suelen combinar ambas: mantienen las reservas en frío y una pequeña cantidad operativa en caliente.
¿Se hackeó la propia blockchain en el ataque a Binance?
No. Bitcoin, Ethereum y las demás redes afectadas por el ataque a Binance funcionaron según lo previsto. Una blockchain comprueba que cada transferencia esté debidamente firmada, y cada transferencia robada se basaba en firmas de las propias claves de Binance. Los sistemas comprometidos del exchange habían generado esas aprobaciones, así que las redes no tenían ningún motivo para rechazarlas. Después, esos mismos registros públicos ayudaron a los investigadores a seguir el rastro de los fondos robados.
¿Cómo puede un exchange de criptomonedas proteger sus hot wallets?
Una buena seguridad de las hot wallets limita tres cosas: quién puede activar un pago, cuánto dinero puede salir y cuánto tiempo puede pasar desapercibido un robo. En la práctica, un exchange necesita dispositivos del personal blindados, con permisos de acceso estrictos, y reglas de firma que limiten las retiradas. Ningún servidor por sí solo debería poder saltarse esas reglas. Las alertas en tiempo real deberían pausar las retiradas automáticamente cuando las salidas parezcan anómalas.
Vea cómo Redwerk auditó y protegió un API de backend para aumentar la mantenibilidad en un 80% y fortalecer cada punto de contacto de integración antes de escalar.
