Satoshi BrotherTu hermano en el mercado cripto
ES

El hackeo de Binance: un drenaje de $296 millones en XRP tras 36 horas de preparación

Descubre cómo un drenaje de $296 millones en XRP inició el mayor robo de criptomonedas en la historia, con tácticas de preparación meticulosas por parte del atacante de Binance.

El hackeo de Binance: un drenaje de $296 millones en XRP tras 36 horas de preparación

Resumen del Ataque a Binance

El atacante de Binance pasó al menos 36 horas preparando el hackeo que resultó en la sustracción de $6.36 mil millones de la plataforma de intercambio de criptomonedas, comenzando con un drenaje de $296 millones en XRP.

Preparativos del Ataque

Según una investigación realizada el 29 de octubre por TRM Labs, el atacante inició la preparación de la operación el 28 de octubre, antes de ejecutar transferencias coordinadas a través de 10 blockchains la noche siguiente. La firma de inteligencia blockchain descubrió que la mayoría de los fondos fueron extraídos de las billeteras vinculadas a Binance en aproximadamente 20 minutos, convirtiendo este incidente en el mayor robo de criptomonedas registrado hasta la fecha.

Detalles del Ataque

TRM rastreó los primeros preparativos hasta la mañana del 28 de octubre, cuando una billetera controlada por el atacante recibió tres pequeñas transferencias de Tornado Cash, un servicio de mezcla de criptomonedas. A primera hora del día siguiente, el atacante desplegó un código de contrato inteligente malicioso y lo probó contra dos billeteras de Ethereum recién creadas. Posteriormente, el atacante implementó una versión revisada y ensayó la operación en una tercera billetera, transfiriendo con éxito fondos de prueba antes de devolverlos.

Aproximadamente cuatro horas después de ese ensayo final, comenzó el ataque principal. Entre las 20:05 y las 20:09 UTC, cinco billeteras de Binance en el XRP Ledger transfirieron aproximadamente 233.46 millones de XRP, valorados en $296 millones, a una única dirección controlada por el atacante.

Transferencias y Ejecución del Ataque

El investigador on-chain Wazz Crypto llegó a una conclusión similar, afirmando que para las 20:10 UTC también habían comenzado transferencias sospechosas desde billeteras de Binance en Solana y Optimism. A las 20:20 UTC, una billetera de Bitcoin de Binance transfirió 18,270 BTC, por un valor aproximado de $1.47 mil millones. El atacante inmediatamente comenzó a dividir los fondos en lotes más pequeños de 1,000 BTC y 100 BTC.

En dos minutos, una billetera de Binance en Tron transfirió otros 612.7 millones de USDT y 46.4 millones de TRX, por un valor combinado de aproximadamente $628 millones. La operación en Ethereum se desarrolló casi simultáneamente. A las 20:20 UTC, el atacante presentó 50 autorizaciones EIP-7702 previamente firmadas a una billetera caliente de Binance, permitiéndole delegar la ejecución a un contrato inteligente malicioso.

Las autorizaciones cubrían conteos de transacciones consecutivas, asegurando que una coincidiera con el conteo actual de la billetera al ser procesada. Tres minutos y 24 segundos después, el atacante activó la función de barrido del contrato, transfiriendo 167,464 ETH y 63 tokens, incluyendo 1.615 mil millones de USDT, en una sola transacción.

Conclusiones y Fuentes de Autorización

Posteriormente, el atacante ejecutó barridos adicionales a las 20:41, 20:59, 21:04, 21:44, 22:39 y 23:56 UTC a medida que más activos ingresaban a la billetera comprometida. La billetera delegada también ejerció sus permisos existentes sobre una cuenta inteligente separada de Binance, facilitando la transferencia de otros 823 millones de USDC.

Una segunda ola alrededor de las 23:05 UTC extendió la operación a billeteras adicionales de Binance en Avalanche y Polygon. Para las 00:30 UTC del 30 de octubre, TRM había rastreado aproximadamente $6.36 mil millones en transferencias a través de Ethereum, Bitcoin, Tron, el XRP Ledger, Solana, Arbitrum, Optimism, Base, Avalanche y Polygon.

Mientras los investigadores han reconstruido la secuencia de eventos, la fuente de las autorizaciones necesarias que permitieron el ataque sigue sin resolverse. El investigador de Ethlabs, Derek Chiang, indicó que el atacante podría haber obtenido la clave privada de la billetera o engañado a su propietario para que firmara una autorización maliciosa. También enfatizó que el atacante necesitaba una autorización válida para ejecutar la operación EIP-7702.

En otros idiomas: EnglishРусскийDeutschFrançaisItaliano

Política editorial e IA · Contacto