Se vieron afectados activos por valor de 6,34 mil millones de dólares.
Pero después de leer el informe de Binance sobre el ataque del 29 de octubre, no creo que la cifra en sí sea lo más aterrador.
Lo más aterrador es esto:
Puede que los atacantes ni siquiera necesitaran la clave privada.
Solo necesitaban controlar el sistema que tenía permiso para usarla.
Este ataque no ocurrió de la noche a la mañana.
Según se informa, los atacantes recurrieron a ingeniería social, falsas entrevistas de contratación, malware, dispositivos de empleados comprometidos, credenciales robadas, herramientas internas de IA y permisos de despliegue…
hasta que finalmente llegaron al servicio de firma de la billetera.
Desde allí, pudieron iniciar transacciones fuera del proceso normal de retiro.
Se transfirieron XRP, SOL, OP, BTC y ETH desde las billeteras calientes de Binance.
Total de activos afectados: ~6,34 mil millones de dólares
Binance afirma que se congelaron o interceptaron alrededor de 2,85 mil millones de dólares, mientras que se habían repuesto el 98 % de los activos en tokens afectados.
Pero hay una distinción importante:
98 % repuesto ≠ 98 % recuperado de los atacantes.
Reponer significa que Binance usó sus propios recursos para restaurar los activos faltantes.
Sin embargo, lo que más me llamó la atención fue EIP-7702.
Los atacantes crearon una autorización en la cadena para un contrato inteligente que controlaban.
Eso significaba que, incluso después de que Binance pausara los retiros, algunos movimientos de activos no autorizados no podían detenerse de inmediato.
La billetera caliente también usaba MPC, así que no había una única clave privada que se pudiera usar para revocar al instante la autorización maliciosa.
Este incidente cambió mi forma de pensar sobre la seguridad de las billeteras.
La pregunta de antes era:
«¿Está segura la clave privada?»
Quizá la pregunta más adecuada sea:
¿Quién puede hacer que el sistema firme?
¿Quién puede desplegar código?
¿Qué credenciales pueden llegar al firmante?
¿Hasta dónde puede escalar el acceso a partir del dispositivo comprometido de un empleado?
Puede que la clave privada siga exactamente donde debería estar.
Pero si un atacante puede hacer que la infraestructura firme en su nombre…
¿realmente es distinto de tener la clave?
Pero después de leer el informe de Binance sobre el ataque del 29 de octubre, no creo que la cifra en sí sea lo más aterrador.
Lo más aterrador es esto:
Puede que los atacantes ni siquiera necesitaran la clave privada.
Solo necesitaban controlar el sistema que tenía permiso para usarla.
Este ataque no ocurrió de la noche a la mañana.
Según se informa, los atacantes recurrieron a ingeniería social, falsas entrevistas de contratación, malware, dispositivos de empleados comprometidos, credenciales robadas, herramientas internas de IA y permisos de despliegue…
hasta que finalmente llegaron al servicio de firma de la billetera.
Desde allí, pudieron iniciar transacciones fuera del proceso normal de retiro.
Se transfirieron XRP, SOL, OP, BTC y ETH desde las billeteras calientes de Binance.
Total de activos afectados: ~6,34 mil millones de dólares
Binance afirma que se congelaron o interceptaron alrededor de 2,85 mil millones de dólares, mientras que se habían repuesto el 98 % de los activos en tokens afectados.
Pero hay una distinción importante:
98 % repuesto ≠ 98 % recuperado de los atacantes.
Reponer significa que Binance usó sus propios recursos para restaurar los activos faltantes.
Sin embargo, lo que más me llamó la atención fue EIP-7702.
Los atacantes crearon una autorización en la cadena para un contrato inteligente que controlaban.
Eso significaba que, incluso después de que Binance pausara los retiros, algunos movimientos de activos no autorizados no podían detenerse de inmediato.
La billetera caliente también usaba MPC, así que no había una única clave privada que se pudiera usar para revocar al instante la autorización maliciosa.
Este incidente cambió mi forma de pensar sobre la seguridad de las billeteras.
La pregunta de antes era:
«¿Está segura la clave privada?»
Quizá la pregunta más adecuada sea:
¿Quién puede hacer que el sistema firme?
¿Quién puede desplegar código?
¿Qué credenciales pueden llegar al firmante?
¿Hasta dónde puede escalar el acceso a partir del dispositivo comprometido de un empleado?
Puede que la clave privada siga exactamente donde debería estar.
Pero si un atacante puede hacer que la infraestructura firme en su nombre…
¿realmente es distinto de tener la clave?
