Binance sufre el robo de miles de millones: por qué suspender los retiros no logró detener las pérdidas de inmediato
La noche del 29 de octubre, Binance, el mayor exchange de criptomonedas del mundo, sufrió un incidente de seguridad sin precedentes. No se trató de una simple intrusión informática, sino de un ataque complejo que se prolongó durante meses e involucró la cadena de suministro interna y la gestión de permisos. Mediante técnicas de ingeniería social cuidadosamente diseñadas, los atacantes se infiltraron gradualmente en los sistemas internos de Binance y, finalmente, accedieron al servicio de firma de las hot wallets. El incidente no solo provocó la pérdida de activos por valor de miles de millones de dólares, sino que también dejó al descubierto una lógica profunda que suele pasarse por alto en la infraestructura blockchain moderna: en el mundo descentralizado de las cadenas, una orden de «pausa» emitida desde la plataforma no equivale a revocar de inmediato los permisos en la cadena.
Según el informe preliminar de la investigación publicado por Binance el 3 de noviembre, la cronología del ataque fue mucho más larga de lo que se había supuesto inicialmente. Ya en junio, un ingeniero encargado del mantenimiento de las wallets descargó un instalador de Homebrew manipulado mientras instalaba una herramienta de programación con IA, lo que provocó la instalación de código malicioso en su dispositivo. Aunque el equipo de seguridad sustituyó después el dispositivo y rotó las credenciales, los atacantes ya habían obtenido información sobre el puesto de ese empleado y de sus compañeros. En septiembre, otro ingeniero de software sufrió el control remoto de su ordenador de trabajo tras ser víctima de un ataque de phishing disfrazado de oferta de empleo. En octubre, los atacantes utilizaron los ordenadores comprometidos y las herramientas internas de IA para ampliar aún más su control y robar las credenciales de despliegue de contenedores del personal de mantenimiento de las wallets. Finalmente, alrededor de las 20:05 UTC del 29 de octubre, los atacantes utilizaron esas credenciales para desplegar contenedores, acceder sin autorización al servicio interno de firma de wallets e iniciar una serie de transferencias de gran cuantía. El seguimiento en cadena de la firma independiente de seguridad TRM Labs mostró que las wallets de Binance en diez blockchains registraron salidas de activos en unos veinte minutos, con un valor estimado de aproximadamente 6.340 millones de dólares. Por el momento, Binance ha congelado o interceptado unos 2.850 millones de dólares y se ha comprometido a asumir las pérdidas financieras, reservando fondos para proteger los intereses de los usuarios.
El detalle con mayor relevancia técnica de este incidente es por qué los activos siguieron saliendo incluso después de que la plataforma suspendiera el servicio de retiros. Según la percepción tradicional, basta con que un exchange cierre los canales de retiro para cortar la salida de fondos. Sin embargo, este ataque aprovechó las características del mecanismo EIP-7702 de Ethereum, que permite a las cuentas ordinarias autorizar, mediante una firma, la ejecución de operaciones con código de contratos inteligentes. A través del servicio de firma comprometido, los atacantes establecieron en la cadena una delegación maliciosa, lo que permitió que los contratos inteligentes bajo su control obtuvieran permisos parciales para operar las hot wallets. Una vez registrada en la cadena, esta autorización existe de forma independiente a los servicios centralizados de la plataforma. Aunque Binance cerrara la opción de retiro en la web, las autorizaciones ya activas en la cadena seguían siendo válidas, y los atacantes podían invocar directamente esos permisos para iniciar transacciones sin necesidad de aprobación de la plataforma. Además, como las hot wallets implicadas utilizaban tecnología de computación multipartita (MPC), las firmas requerían la colaboración de varias partes y no existía una clave privada única que permitiera revocar los permisos de emergencia. Esto obligó al equipo a desarrollar un proceso de revocación específico, lo que consumió un tiempo crucial. No fue hasta las 00:10 UTC del 30 de octubre cuando Binance emitió una nueva autorización desde las hot wallets y eliminó el código de delegación malicioso. La última transferencia no autorizada quedó registrada en la cadena a las 23:56 UTC del 29 de octubre. Esta diferencia temporal pone de manifiesto que «detener nuevas solicitudes» y «revocar autorizaciones existentes» son dos acciones de ingeniería completamente distintas: la primera es un interruptor a nivel de servicio; la segunda, un cambio en el estado de la cadena.
Desde la perspectiva de la gestión de riesgos, este incidente rompe con la idea arraigada de que «si la clave privada no se ha filtrado, todo está seguro». Los atacantes no robaron directamente la clave privada completa, sino que se aprovecharon de la capacidad de firma del sistema y lograron que los servicios internos «firmaran» transacciones no aprobadas. Esto demuestra que el perímetro de seguridad de los activos digitales ya no se limita a la custodia de claves, sino que se extiende al control dinámico de los permisos. En su comunicado del 31 de octubre, el FBI atribuyó el robo a la actividad TraderTraitor, vinculada a Corea del Norte, lo que subraya aún más la capacidad de los métodos de ataque de nivel estatal para penetrar las defensas de seguridad tradicionales. Para el sector, el caso de Binance ofrece una lección dura, pero necesaria: al incorporar nuevas tecnologías como MPC y herramientas de IA para mejorar la eficiencia, es imprescindible volver a examinar la lógica fundamental de la respuesta ante emergencias. Los equipos de ingeniería no pueden depender únicamente de una medida como «cerrar el servicio»; deben establecer una vía de emergencia para revocar permisos, independiente de los procesos operativos normales y ensayada de antemano. Asimismo, los sistemas de firma deben distinguir estrictamente entre las solicitudes de transferencia ordinarias y las solicitudes de autorización que modifican los permisos de ejecución de una cuenta, ya que, una vez activadas, estas últimas tienen efectos persistentes y son difíciles de revertir de inmediato. Aunque el incidente ya se ha contenido inicialmente, el problema de ingeniería que deja planteado —cómo implementar un mecanismo centralizado de frenado de emergencia en una cadena descentralizada— sigue siendo una cuestión que todos los proveedores de infraestructura cripto deben afrontar y resolver.
Sígueme para no perderte la próxima lectura rápida del mercado.
La noche del 29 de octubre, Binance, el mayor exchange de criptomonedas del mundo, sufrió un incidente de seguridad sin precedentes. No se trató de una simple intrusión informática, sino de un ataque complejo que se prolongó durante meses e involucró la cadena de suministro interna y la gestión de permisos. Mediante técnicas de ingeniería social cuidadosamente diseñadas, los atacantes se infiltraron gradualmente en los sistemas internos de Binance y, finalmente, accedieron al servicio de firma de las hot wallets. El incidente no solo provocó la pérdida de activos por valor de miles de millones de dólares, sino que también dejó al descubierto una lógica profunda que suele pasarse por alto en la infraestructura blockchain moderna: en el mundo descentralizado de las cadenas, una orden de «pausa» emitida desde la plataforma no equivale a revocar de inmediato los permisos en la cadena.
Según el informe preliminar de la investigación publicado por Binance el 3 de noviembre, la cronología del ataque fue mucho más larga de lo que se había supuesto inicialmente. Ya en junio, un ingeniero encargado del mantenimiento de las wallets descargó un instalador de Homebrew manipulado mientras instalaba una herramienta de programación con IA, lo que provocó la instalación de código malicioso en su dispositivo. Aunque el equipo de seguridad sustituyó después el dispositivo y rotó las credenciales, los atacantes ya habían obtenido información sobre el puesto de ese empleado y de sus compañeros. En septiembre, otro ingeniero de software sufrió el control remoto de su ordenador de trabajo tras ser víctima de un ataque de phishing disfrazado de oferta de empleo. En octubre, los atacantes utilizaron los ordenadores comprometidos y las herramientas internas de IA para ampliar aún más su control y robar las credenciales de despliegue de contenedores del personal de mantenimiento de las wallets. Finalmente, alrededor de las 20:05 UTC del 29 de octubre, los atacantes utilizaron esas credenciales para desplegar contenedores, acceder sin autorización al servicio interno de firma de wallets e iniciar una serie de transferencias de gran cuantía. El seguimiento en cadena de la firma independiente de seguridad TRM Labs mostró que las wallets de Binance en diez blockchains registraron salidas de activos en unos veinte minutos, con un valor estimado de aproximadamente 6.340 millones de dólares. Por el momento, Binance ha congelado o interceptado unos 2.850 millones de dólares y se ha comprometido a asumir las pérdidas financieras, reservando fondos para proteger los intereses de los usuarios.
El detalle con mayor relevancia técnica de este incidente es por qué los activos siguieron saliendo incluso después de que la plataforma suspendiera el servicio de retiros. Según la percepción tradicional, basta con que un exchange cierre los canales de retiro para cortar la salida de fondos. Sin embargo, este ataque aprovechó las características del mecanismo EIP-7702 de Ethereum, que permite a las cuentas ordinarias autorizar, mediante una firma, la ejecución de operaciones con código de contratos inteligentes. A través del servicio de firma comprometido, los atacantes establecieron en la cadena una delegación maliciosa, lo que permitió que los contratos inteligentes bajo su control obtuvieran permisos parciales para operar las hot wallets. Una vez registrada en la cadena, esta autorización existe de forma independiente a los servicios centralizados de la plataforma. Aunque Binance cerrara la opción de retiro en la web, las autorizaciones ya activas en la cadena seguían siendo válidas, y los atacantes podían invocar directamente esos permisos para iniciar transacciones sin necesidad de aprobación de la plataforma. Además, como las hot wallets implicadas utilizaban tecnología de computación multipartita (MPC), las firmas requerían la colaboración de varias partes y no existía una clave privada única que permitiera revocar los permisos de emergencia. Esto obligó al equipo a desarrollar un proceso de revocación específico, lo que consumió un tiempo crucial. No fue hasta las 00:10 UTC del 30 de octubre cuando Binance emitió una nueva autorización desde las hot wallets y eliminó el código de delegación malicioso. La última transferencia no autorizada quedó registrada en la cadena a las 23:56 UTC del 29 de octubre. Esta diferencia temporal pone de manifiesto que «detener nuevas solicitudes» y «revocar autorizaciones existentes» son dos acciones de ingeniería completamente distintas: la primera es un interruptor a nivel de servicio; la segunda, un cambio en el estado de la cadena.
Desde la perspectiva de la gestión de riesgos, este incidente rompe con la idea arraigada de que «si la clave privada no se ha filtrado, todo está seguro». Los atacantes no robaron directamente la clave privada completa, sino que se aprovecharon de la capacidad de firma del sistema y lograron que los servicios internos «firmaran» transacciones no aprobadas. Esto demuestra que el perímetro de seguridad de los activos digitales ya no se limita a la custodia de claves, sino que se extiende al control dinámico de los permisos. En su comunicado del 31 de octubre, el FBI atribuyó el robo a la actividad TraderTraitor, vinculada a Corea del Norte, lo que subraya aún más la capacidad de los métodos de ataque de nivel estatal para penetrar las defensas de seguridad tradicionales. Para el sector, el caso de Binance ofrece una lección dura, pero necesaria: al incorporar nuevas tecnologías como MPC y herramientas de IA para mejorar la eficiencia, es imprescindible volver a examinar la lógica fundamental de la respuesta ante emergencias. Los equipos de ingeniería no pueden depender únicamente de una medida como «cerrar el servicio»; deben establecer una vía de emergencia para revocar permisos, independiente de los procesos operativos normales y ensayada de antemano. Asimismo, los sistemas de firma deben distinguir estrictamente entre las solicitudes de transferencia ordinarias y las solicitudes de autorización que modifican los permisos de ejecución de una cuenta, ya que, una vez activadas, estas últimas tienen efectos persistentes y son difíciles de revertir de inmediato. Aunque el incidente ya se ha contenido inicialmente, el problema de ingeniería que deja planteado —cómo implementar un mecanismo centralizado de frenado de emergencia en una cadena descentralizada— sigue siendo una cuestión que todos los proveedores de infraestructura cripto deben afrontar y resolver.
Sígueme para no perderte la próxima lectura rápida del mercado.
