3,047 millones de USDC drenados en ataque con contrato falso de Request Finance contra Safe

Un reciente ataque de phishing provocó la pérdida de 3,047 millones de USDC. El exploit tuvo como objetivo una billetera multifirma de Safe mediante el uso de un contrato falso de Request Finance. Los investigadores señalan que los atacantes planearon el esquema con detalle y lo ejecutaron de manera que parecía casi autorizada. La víctima utilizaba una billetera multifirma 2-de-4 de Safe. Según Scam Sniffer, la transacción parecía procesarse a través de la interfaz de la aplicación Request Finance, pero dentro de la solicitud en lote se ocultaba la aprobación de un contrato malicioso.

La dirección del contrato falso era casi idéntica a la legítima, con apenas diferencias sutiles en los caracteres intermedios. Ambas comenzaban y terminaban con el mismo carácter, lo que dificultaba detectarlo a simple vista. Para aumentar la credibilidad, los atacantes incluso verificaron el contrato malicioso en Etherscan, un paso adicional que lo hacía parecer auténtico ante una revisión superficial. Una vez concedida la aprobación, los atacantes drenaron de inmediato 3,047 millones de USDC. Los fondos robados se intercambiaron luego por ETH y se trasladaron rápidamente a Tornado Cash, lo que dificulta rastrearlos.

Una cronología cuidadosamente planificada

La cronología del ataque muestra una preparación clara. Trece días antes del robo, los atacantes desplegaron el contrato falso de Request Finance y realizaron múltiples transacciones de tipo “batchPayments” para que pareciera activo y confiable. Para cuando la víctima interactuó con él, el contrato ya mostraba un historial de uso aparentemente normal. Cuando la víctima utilizó la aplicación Request Finance, los atacantes introdujeron la aprobación oculta en la transacción por lotes. Una vez firmada, el exploit quedó completado.

Respuesta de Request Finance

Request Finance reconoció el incidente y emitió un comunicado de advertencia a los usuarios. La compañía confirmó que un actor malicioso había desplegado una imitación de su contrato de Batch Payment. Según el comunicado, solo un cliente resultó afectado. La vulnerabilidad ya fue corregida, aunque aún no está claro el método exacto que permitió inyectar la aprobación maliciosa. Los analistas consideran posibles vectores de ataque una vulnerabilidad en la propia aplicación, la presencia de malware o extensiones de navegador que modifican transacciones, así como un frontend comprometido o un secuestro de DNS. No se descartan otras formas de inyección de código.

Preocupaciones de seguridad

El caso refleja la creciente sofisticación de las estafas en la industria cripto. Los atacantes ya no dependen únicamente de enlaces de phishing básicos o trucos evidentes. Ahora despliegan contratos verificados, imitan servicios reales y esconden acciones maliciosas en transacciones complejas. Las transacciones por lotes, diseñadas para simplificar pagos, también generan oportunidades para los atacantes, ya que agrupan múltiples acciones y dificultan que los usuarios revisen cada aprobación o transferencia. Esta falta de visibilidad permite introducir operaciones fraudulentas sin ser detectadas hasta que es demasiado tarde.

Lecciones para la comunidad

Los expertos insisten en la necesidad de extremar precauciones al usar funciones de multi-send o pagos por lotes. Cada aprobación de contrato debe revisarse carácter por carácter para evitar confusiones con direcciones similares. Incluso un detalle pasado por alto puede derivar en grandes pérdidas, como en este caso. Las firmas de seguridad también recomiendan minimizar el uso de extensiones de navegador y verificar las aplicaciones no oficiales conectadas a las billeteras.

Mantener el software actualizado, utilizar hardware wallets para aprobaciones y cotejar las direcciones de los contratos con fuentes confiables son medidas que reducen el riesgo de exploits de este tipo. El incidente es un recordatorio de la importancia de reforzar la protección de los usuarios en las plataformas. Advertencias más claras, sistemas automáticos de detección de contratos similares y una mejor visibilidad de las transacciones podrían ayudar a prevenir ataques de este tipo.