Incidente de seguridad de Binance del 29 de octubre:

Hallazgos preliminares y actualización de la respuesta
El 29 de octubre de 2026, Binance sufrió un incidente de seguridad grave y altamente sofisticado. Esto no debería haber ocurrido, y pedimos disculpas por los inconvenientes, la interrupción y la incertidumbre que causó a nuestros usuarios, socios y al sector en general.
Nuestra primera responsabilidad es proteger a los usuarios. Binance está asumiendo el impacto financiero de los fondos robados, no nuestros usuarios. Ya hemos reservado más del 100 % de los fondos necesarios para cubrir la pérdida. Hasta hoy, 3 de noviembre de 2026, se había repuesto el 98 % de los activos en tokens afectados, que pueden verificarse en nuestra página de Prueba de Reservas. Estamos en proceso de comprar los activos restantes, que tienen menor liquidez.
El incidente afectó aproximadamente US$ 6,34 mil millones en activos virtuales. A la fecha de esta actualización, se han congelado o interceptado aproximadamente US$ 2,85 mil millones en activos virtuales, sujetos a conciliación y a la volatilidad de los precios de mercado.
Tomamos medidas inmediatas para contener el incidente y reforzar los sistemas implicados. Cerramos los puntos de entrada identificados como utilizados en el ataque. Reconstruimos o sustituimos los sistemas alcanzados a través de la ruta del ataque. También implementamos controles de dispositivos más estrictos, mejoramos los controles de riesgo para los servicios de cartera y ampliamos la detección de anomalías de comportamiento basada en IA.
Este es nuestro informe inicial. Abarca lo que sabemos hoy y lo que ya hemos mejorado. La investigación sigue en curso y nuestros hallazgos estarán sujetos a un análisis independiente adicional. Algunos detalles técnicos permanecerán confidenciales para impedir que actores maliciosos los utilicen para planificar ataques. Estamos contratando empresas de seguridad independientes para realizar un análisis adicional.
La información más reciente publicada por la Oficina Federal de Investigación (FBI) (https:// www. fbi.gov/investigate/cyber/alerts/2026/north-korea-responsible-for-6-billion-binance-attack) indica que la República Popular Democrática de Corea es responsable de este incidente.
Compartimos este informe preliminar porque la seguridad mejora cuando el sector aprende en conjunto.
Qué ocurrió el 29 de octubre
El ataque se desarrolló rápidamente en varias redes.
El atacante aprovechó el acceso no autorizado a un servicio interno de firma de carteras para iniciar transacciones al margen del proceso normal de retiros.
Entre las 17:05 y las 17:09 (hora de Brasilia), cinco carteras calientes de Binance enviaron 233,46 millones de XRP a una dirección controlada por el atacante.
Las carteras calientes de Binance en Solana y Optimism enviaron aproximadamente 970.500 SOL y 44,2 millones de OP a direcciones controladas por el atacante.
Binance recibió entonces una alerta interna sobre transferencias de gran volumen e inició de inmediato una investigación.
Una cartera caliente de Binance envió 18.270 BTC a una dirección controlada por el atacante.
El atacante utilizó entonces el servicio de firma para explotar el mecanismo de autorización EIP-7702 de Ethereum. EIP-7702 permite que una cuenta delegue determinados derechos de ejecución a un contrato inteligente sin exponer la clave privada. En este caso, el atacante utilizó este mecanismo para conceder a un contrato inteligente bajo su control derechos de ejecución parciales sobre una cartera caliente de Binance.
Binance inició de inmediato varias medidas de contención, entre ellas la suspensión de los retiros para restringir nuevas salidas de fondos, la coordinación con socios para congelar los tokens afectados y la adopción de medidas para revocar permisos no autorizados. Estos esfuerzos permitieron congelar un total de US$ 2,85 mil millones en activos.
Sin embargo, la suspensión de los retiros por sí sola no pudo detener todos los movimientos de activos no autorizados. Las autorizaciones maliciosas de EIP-7702 existían en la cadena y operaban independientemente de la infraestructura normal de retiros de Binance. Los atacantes enviaron 50 transacciones de firma para manipular el NONCE de la cuenta y establecer autorizaciones de delegación maliciosas. Una vez establecidas, estas autorizaciones permitieron a los atacantes seguir moviendo activos independientemente de la infraestructura normal de retiros de Binance. Binance necesitó transacciones adicionales para revocar estas autorizaciones en la cadena.
El proceso de contención implicó complejidades técnicas adicionales. Como la cartera caliente utilizaba Computación multipartita (MPC), no había una única clave privada que pudiera utilizarse para revocar de inmediato las autorizaciones maliciosas de EIP-7702. Por lo tanto, el equipo desarrolló y ejecutó un procedimiento especializado para revocar estas autorizaciones, lo que requirió tiempo adicional. Además, la suspensión de los retiros y el apagado de los servicios de carteras calientes no invalidaban automáticamente las autorizaciones existentes en la cadena.
Estos desafíos prolongaron el tiempo necesario para contener por completo los movimientos de activos no autorizados. Estamos revisando el proceso de respuesta a incidentes, la cobertura de las políticas de firma y los controles de las carteras calientes, e identificando oportunidades para reforzar aún más nuestra capacidad de responder rápidamente a amenazas similares en el futuro.
La última transferencia no autorizada, de 2.961,9 ETH, se confirmó en la cadena a las 20:56 (hora de Brasilia). La transacción se había transmitido anteriormente y había quedado pendiente antes de confirmarse más tarde. Después de eso no se observó ninguna otra transferencia no autorizada.
A las 21:10 (hora de Brasilia) del 29 de octubre de 2026, Binance ejecutó una nueva autorización de la cartera caliente Binance 14 a la dirección cero, eliminando el código de delegación de EIP-7702.
Preparación del ataque
Nuestra investigación actual indica que se trató de una campaña de ataque sofisticada y con múltiples etapas. No fue una única brecha aislada ni un simple incidente de phishing. Los atacantes combinaron diversas técnicas, entre ellas ingeniería social mediante falsas entrevistas de contratación, descargas de software malicioso, el compromiso de herramientas internas de IA y de endpoints, y un método avanzado de autorización de transacciones.
Junio de 2026 — Ataque a la cadena de suministro. El Ingeniero A, del equipo de DevOps de Carteras, descargó una instalación adulterada de Homebrew ( isc.sans.edu/diary/32942) para instalar una popular herramienta de programación con IA después de buscarla en un motor de búsqueda. Nuestro equipo de seguridad detectó la anomalía, sustituyó el dispositivo y rotó todas las credenciales relacionadas como medida proactiva de seguridad. Sin embargo, la función del Ingeniero A y la identidad de sus colegas relacionados de nuestro equipo de infraestructura de carteras quedaron expuestas al hacker.
A lo largo de 2026, el equipo de seguridad de Binance detectó e impidió 57 casos de amenazas cibernéticas con presuntos vínculos con Corea del Norte. Estos intentos reflejan la persistente amenaza que representan los actores patrocinados por Estados que tienen como objetivo el sector de las criptomonedas. Las técnicas incluyen entrevistas de trabajo fraudulentas, software malicioso disfrazado de herramientas populares para desarrolladores, como Claude y Codex, paquetes de software y extensiones de navegador comprometidos, aplicaciones falsas de videoconferencia y campañas de ingeniería social diseñadas para robar credenciales o instalar malware de acceso remoto.
Septiembre — Ingeniería social. El Ingeniero de Software B fue contactado a través de una plataforma legítima de búsqueda de empleo por una persona que se hacía pasar por director de proyectos. El Ingeniero de Software B tenía un perfil en la plataforma que mencionaba su experiencia en Binance. El supuesto director de proyectos organizó una primera ronda de entrevista con un representante de Recursos Humanos, seguida de una segunda ronda con una persona que afirmaba ser el CEO de una empresa ficticia.
En la primera ronda, el supuesto representante de Recursos Humanos realizó una entrevista por videollamada en directo con el Ingeniero de Software B. El entrevistador compartió con él una cuenta de redes sociales, incluidas fotos y videos personales publicados en la plataforma, para generar confianza. Esto fue más sofisticado y engañoso que los métodos de ingeniería social observados anteriormente.
La segunda entrevista se realizó en una popular aplicación de mensajería social. Cerca del final de la entrevista, se indicó al Ingeniero B que descargara una «tarea» que contenía un repositorio de código malicioso en su computadora de trabajo. El repositorio contenía código malicioso que se ejecutó durante el proceso de configuración e inició una serie de actividades no autorizadas.
El malware empleó sofisticadas técnicas de ofuscación y evasión, incluida la sustitución de un componente legítimo de una herramienta de desarrollo por una versión maliciosa para ejecutar comandos y establecer comunicación con un servidor externo controlado por el atacante. Las herramientas de protección de endpoints no detectaron el malware de día cero en ese momento. El atacante también tomó medidas para ocultar la actividad maliciosa y eliminar rastros del compromiso, lo que dificultó la detección y la investigación posterior.
El script ejecutó los pasos siguientes, aplicando técnicas de ofuscación para evitar la detección por parte de los sistemas de seguridad.
CREATE /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv_
MODIFY pyenv_ → 3,414 B
DELETE .../libexec/pyenv (3,344 B) ← elimina el pyenv legítimo
RENAME pyenv_ → pyenv (3,414 B) ← lo sustituye por una versión maliciosa
DELETE /opt/homebrew/bin/pyenv (3,414 B)
ln (crea un nuevo enlace simbólico) + spawn zsh
20 de octubre — Uso de una herramienta interna de IA como punto de apoyo. El atacante aprovechó la computadora comprometida del Ingeniero B y utilizó una herramienta interna de IA para obtener el control del Ingeniero A, de DevOps de Carteras, y de otro Ingeniero de Software de Carteras, C. El atacante pronto descubrió que el Ingeniero A, de DevOps de Carteras, tenía un token de permiso para implementar contenedores en su computadora.
29 de octubre — Acceso a las operaciones de firma de carteras. El 29 de octubre, entre las 17:15 y las 19:56, el atacante accedió a la computadora del Ingeniero de Software C, utilizó las credenciales robadas del Ingeniero A, de DevOps de Carteras, implementó un contenedor y activó un script malicioso para iniciar el ataque.

Qué hicimosReconstruimos el sistema de carteras afectado en un nuevo entorno.
Reconstruimos la herramienta interna de IA afectada y los controles de acceso.
Sustituimos los dispositivos afectados.
Desactivamos las credenciales y los tokens relacionados con los ingenieros afectados.
Completamos análisis de seguridad reforzados en todos los dispositivos de los empleados.
Mejoramos la detección de anomalías de comportamiento basada en IA.
Reforzamos los controles de riesgo de los servicios de cartera.
Trabajamos con las fuerzas del orden, empresas de inteligencia de cadena de bloques y socios del sector para rastrear y congelar los activos afectados.
Seguiremos reforzando nuestras medidas a medida que avance la investigación. Hemos implementado y estamos implementando diversas medidas de seguridad que mantendremos en privado para impedir que actores maliciosos comprometan nuestra seguridad.
Medidas adicionalesEstamos tomando las siguientes medidas de inmediato.
Análisis independiente de ciberseguridad
Estamos contratando especialistas independientes y empresas de ciberseguridad para realizar un análisis exhaustivo del incidente, validar nuestros hallazgos y recomendar medidas adicionales. El alcance y los hallazgos de este análisis orientarán nuestro trabajo continuo de corrección.
Ampliación de la inversión en seguridad y prevención de IA
Estamos aumentando la inversión en detección basada en IA, protección de endpoints, seguridad del entorno de desarrollo y supervisión de anomalías de comportamiento.
Fondo de investigación en seguridad e iniciativas del sector
Estamos trabajando para establecer un fondo de investigación en seguridad e iniciativas específicas con empresas líderes de IA, participantes del sector y empresas de seguridad, centrados en la seguridad de la IA en entornos de cadena de bloques.
Seguiremos compartiendo información de forma proactiva a medida que la tengamos.