El exploit de DotSwap V1 drena aproximadamente 8,5 BTC, con pérdidas estimadas en 685.000 dólares
El exploit de DotSwap V1 drena aproximadamente 8,5 BTC, con pérdidas estimadas en 685.000 dólares
El 25 de octubre, la versión heredada de la plataforma de trading DotSwap, DotSwap V1, sufrió un exploit que provocó el robo de aproximadamente 8,5 BTC, valorados en unos 685.000 dólares en el momento del incidente.
El ataque pone de relieve un desafío de seguridad cada vez mayor en las aplicaciones basadas en Bitcoin: aunque los usuarios interactúen con activos descentralizados, los sistemas de autorización del backend, la infraestructura de liquidez bajo custodia y los servicios de firma automatizada pueden crear puntos únicos de fallo centralizados.
Según una actualización del incidente publicada por On Nexus, la plataforma afectada fue desconectada mientras el equipo investiga el ataque, rastrea los fondos robados y colabora con exchanges y empresas de análisis de blockchain.
¿Qué ocurrió con DotSwap V1?
DotSwap V1 utilizaba un modelo de firma desde el servidor para gestionar los pools de liquidez. Su infraestructura de liquidez operaba mediante un sistema multifirma bajo custodia, lo que significa que los BTC depositados estaban controlados por el proceso de firma de la plataforma y no directamente por cada proveedor de liquidez.
Según los informes, el atacante aprovechó un mecanismo de firma heredado que seguía activo en el backend de V1. Durante aproximadamente cuatro horas, unos scripts automatizados interactuaron con las interfaces disponibles de la plataforma y fueron transfiriendo gradualmente fondos de los pools de liquidez y las cuentas de usuario de V1.
El ataque no se limitó a un solo token o endpoint. Al parecer, los scripts probaron las interfaces de la plataforma y apuntaron a activos asociados con 99 tokens Runes, lo que permitió al atacante identificar y explotar vulnerabilidades en un entorno de aplicación más amplio.
Las pérdidas totales se estimaron aproximadamente en:
- 8,5 BTC robados
- Alrededor de 685.000 dólares en fondos afectados
- Depósitos de proveedores de liquidez de DotSwap V1 afectados
- Las wallets bajo control de los usuarios fuera de la plataforma no se vieron afectadas
DotSwap V1 fue clausurado posteriormente. On Nexus ha declarado que trabaja en la restauración de los servicios relacionados y que publicará un análisis más completo del incidente, junto con un plan para los usuarios afectados.
Por qué los proveedores de liquidez fueron las principales víctimas
La distinción más importante en este incidente es la que existe entre los fondos gestionados por la plataforma y los activos almacenados en la wallet propia del usuario.
Los proveedores de liquidez que depositaron BTC en DotSwap V1 quedaron expuestos a la arquitectura de custodia y firma de la plataforma. Aunque el sistema utilizaba controles multifirma, el proceso de firma seguía conectado a servicios backend que podían consultarse y activarse a través de las interfaces de la aplicación.
Esto significa que la protección multifirma, por sí sola, no eliminó el riesgo operativo. Si la lógica de autorización, los permisos de la API, las políticas de firma o los controles del servidor están mal diseñados, un atacante aún puede encontrar la forma de generar transacciones válidas.
En cambio, los usuarios que mantuvieron sus activos en wallets autocustodiadas y no los depositaron en los pools de V1 no se vieron afectados por el incidente. Sus claves privadas permanecieron fuera del entorno comprometido de la plataforma.
Esta diferencia es fundamental para comprender el riesgo de los pools de liquidez:
Un protocolo puede utilizar liquidación en la blockchain y, al mismo tiempo, depender de una infraestructura centralizada para la custodia, la firma, la fijación de precios, el enrutamiento o el control de acceso.
Por ello, los usuarios no solo deberían evaluar si una aplicación está “on-chain”, sino también dónde se encuentra la autoridad de firma, quién controla los permisos de retiro y si un sistema backend puede congelar o redirigir los fondos depositados.
Un posible ejemplo de automatización de ataques asistida por IA
On Nexus describió el incidente como un caso coherente con una tendencia reciente de ataques impulsados por IA o altamente automatizados.
El uso de la automatización puede aumentar significativamente la velocidad y el alcance de un exploit. En lugar de probar manualmente una función cada vez, un atacante puede:
- Descubrir endpoints de API expuestos
- Enviar grandes cantidades de solicitudes
- Comparar las respuestas entre distintos activos
- Detectar comportamientos de autorización incoherentes
- Identificar rutas anómalas de firma o retiro
- Ejecutar transacciones sucesivas a gran velocidad
En un entorno que admite decenas de contratos de tokens y rutas de trading, la automatización facilita la identificación de pequeñas diferencias de implementación que podrían pasar desapercibidas durante las pruebas manuales rutinarias.
La lección general es que los equipos de seguridad ahora deben defenderse de ataques que combinan el scripting tradicional con agentes de IA cada vez más capaces. El descubrimiento de APIs, la clasificación de vulnerabilidades, la construcción de transacciones y la monitorización pueden acelerarse mediante herramientas automatizadas.
Esta tendencia hace que la limitación de solicitudes, el aislamiento de endpoints, la detección de anomalías, la aplicación de políticas de firma y la monitorización de transacciones en tiempo real sean cada vez más importantes para las plataformas de activos digitales.
Qué revela el incidente sobre la infraestructura de Runes
El ecosistema Runes ha ampliado la variedad de activos fungibles que pueden emitirse y negociarse en Bitcoin. Sin embargo, la infraestructura que respalda estos activos todavía está en desarrollo, y muchas aplicaciones dependen de una combinación de indexadores, servicios off-chain, pools bajo custodia y lógica de trading especializada.
Esto genera varias áreas de riesgo:
- Dependencia de los indexadores: Los saldos de las wallets y el estado de los tokens pueden depender de servicios de indexación de terceros.
- Autorización del backend: Una plataforma puede utilizar APIs centralizadas para determinar si una transacción puede firmarse.
- Liquidez bajo custodia: Los usuarios pueden depositar BTC en wallets agrupadas gestionadas por la aplicación.
- Complejidad de contratos y activos: Dar soporte a numerosos activos Runes aumenta la cantidad de rutas, interfaces y casos límite que deben probarse.
- Concentración operativa: Un único servicio de firma comprometido puede afectar simultáneamente a varios pools.
Los usuarios que estén explorando el trading de Runes o la provisión de liquidez deberían revisar el modelo de custodia del proyecto antes de depositar fondos. La interfaz de una plataforma puede parecer descentralizada, mientras que las funciones de control más importantes siguen estando centralizadas.
Para obtener información general sobre el ecosistema de activos de Bitcoin, los usuarios pueden consultar la documentación para desarrolladores de Bitcoin y el boletín Bitcoin Optech, que cubre habitualmente novedades sobre protocolos, wallets e infraestructura de Bitcoin.
Lecciones prácticas de seguridad para los usuarios de criptomonedas
1. Confirma si los fondos siguen bajo tu control
Antes de aportar liquidez o depositar activos, determina si la plataforma puede mover los fondos sin una transacción firmada directamente desde tu wallet.
Conviene plantearse las siguientes preguntas:
- ¿Los depósitos se envían a una dirección controlada por el usuario o por la plataforma?
- ¿Quién posee las claves privadas?
- ¿La firma se realiza localmente, mediante un dispositivo hardware o en un servidor?
- ¿Pueden los administradores pausar los retiros o modificar las reglas de firma?
- ¿Los límites de retiro y los controles de monitorización están documentados públicamente?
Las respuestas pueden modificar sustancialmente el perfil de riesgo del servicio.
2. Considera los productos heredados como posibles superficies de ataque
El incidente de DotSwap V1 demuestra por qué las versiones antiguas de una plataforma no deberían permanecer conectadas a servicios activos. Aunque una nueva versión tenga controles más sólidos, las APIs obsoletas, las rutas de firma y los permisos de cuenta antiguos aún podrían ser explotables.
Los proyectos deberían retirar por completo los productos obsoletos mediante las siguientes medidas:
- Revocar las credenciales de API
- Eliminar los permisos de firma antiguos
- Desactivar los endpoints que ya no se utilicen
- Rotar las claves de servicio
- Separar las bases de datos heredadas de los sistemas de producción
- Monitorizar la infraestructura histórica para detectar actividad inesperada
3. Evita concentrar los activos en una sola aplicación
Los proveedores de liquidez deberían plantearse diversificar entre distintas wallets, protocolos y modelos de custodia. Concentrar una gran cantidad de BTC en una sola aplicación puede aumentar el impacto de un único exploit o fallo operativo.
Esto no elimina el riesgo del protocolo, pero puede reducir la posibilidad de que un solo incidente afecte a toda una cartera.
4. Monitoriza la actividad de la wallet y las autorizaciones
Los usuarios deberían revisar periódicamente los saldos de sus wallets, las aplicaciones conectadas, las sesiones activas y el historial de transacciones. Las solicitudes de firma inesperadas, las direcciones de retiro desconocidas o los nuevos inicios de sesión desde otros dispositivos deben considerarse posibles señales de alerta.
En las transacciones de alto valor, los usuarios deberían verificar de forma independiente:
- La dirección de destino
- El activo y la cantidad
- La red
- La comisión de la transacción
- El dominio de la aplicación
- Los detalles finales de la transacción que muestra la wallet
5. Entiende que la multifirma no equivale a una descentralización total
Los sistemas multifirma pueden mejorar la resiliencia, pero su eficacia depende de cómo se distribuyen los firmantes y de cómo se aplica la autorización.
Si todos los firmantes están controlados por la misma organización, conectados al mismo backend o sujetos al mismo motor de políticas defectuoso, el sistema aún puede tener un punto de fallo centralizado importante.
La seguridad depende de toda la arquitectura de firma, no simplemente de la existencia de varias firmas.
Qué deberían vigilar los usuarios afectados
Los usuarios conectados a DotSwap V1 deberían desconfiar de los mensajes de phishing que prometan reembolsos, compensaciones o herramientas de retiro de emergencia. Los atacantes suelen aprovechar los incidentes públicos para hacerse pasar por los equipos de los proyectos y dirigir a las víctimas a sitios web falsos.
Los usuarios afectados deberían:
- Seguir únicamente los canales de comunicación verificados del proyecto
- Evitar introducir frases semilla o claves privadas en sitios web
- Tratar como sospechosos los formularios de reembolso no solicitados
- Guardar los identificadores de las transacciones y los registros de depósito
- Consultar la blockchain de forma independiente
- Monitorizar el movimiento de las direcciones de wallet relacionadas
- Esperar a que exista un proceso oficial de recuperación o reclamación antes de firmar cualquier cosa
Un equipo legítimo de soporte nunca debería solicitar la frase de recuperación de una wallet para verificar la propiedad o tramitar un reembolso.
Para obtener recomendaciones generales sobre la protección de activos digitales, la guía de ciberseguridad de CISA ofrece información útil sobre phishing, seguridad de las cuentas y actividades maliciosas.
Implicaciones más amplias para DeFi y las aplicaciones de Bitcoin
El exploit de DotSwap V1 no es simplemente la historia de una plataforma vulnerable. Refleja una tensión más amplia dentro de la industria cripto: las aplicaciones pueden ofrecer a los usuarios una interfaz descentralizada mientras dependen de componentes centralizados entre bastidores.
A medida que maduran las aplicaciones financieras basadas en Bitcoin, las revisiones de seguridad deberán abarcar mucho más que el código de los contratos inteligentes. Las auditorías también deberían examinar:
- La autenticación y autorización de las APIs
- Los servicios de firma desde el servidor
- La gestión de claves y el aislamiento de los firmantes
- Los permisos de las bases de datos
- Los sistemas de indexación de activos
- Los procedimientos de actualización y apagado
- La monitorización y la respuesta ante incidentes
- Los mecanismos de retiro de emergencia
En 2025, el uso cada vez mayor de agentes automatizados y el desarrollo asistido por IA hacen que este proceso de revisión sea aún más importante. Un desarrollo de software más rápido y una interacción automatizada pueden ampliar la superficie de ataque si los controles de seguridad no evolucionan al mismo ritmo.
Para los usuarios, la protección más fiable sigue siendo comprender claramente el modelo de custodia. Los activos almacenados directamente en una wallet autocustodiada están expuestos a un conjunto de riesgos diferente al de los activos depositados en un pool controlado por una plataforma. Ninguno de los dos modelos está libre de riesgos, pero la fuente de dichos riesgos es sustancialmente distinta.
Cómo encajan las hardware wallets en una estrategia de autocustodia más segura
Una hardware wallet puede ayudar a reducir la exposición a compromisos de servidores al mantener las claves privadas aisladas de las aplicaciones conectadas a Internet. Al interactuar con aplicaciones descentralizadas, los usuarios pueden revisar y aprobar los detalles de las transacciones desde un dispositivo de firma específico, en lugar de depender exclusivamente de la interfaz del navegador.
Las hardware wallets de OneKey están diseñadas para flujos de trabajo de autocustodia, incluida la protección offline de las claves y la confirmación de transacciones en el propio dispositivo. No eliminan los riesgos de los contratos inteligentes, el phishing, las interfaces maliciosas ni la volatilidad del mercado, pero pueden ayudar a los usuarios a mantener el control de los activos que no hayan depositado intencionadamente en plataformas bajo custodia o pools de liquidez.
El principio fundamental es sencillo: antes de aportar liquidez o autorizar una transacción, los usuarios deben entender quién controla los fondos, qué están firmando y si la plataforma puede mover activos sin su aprobación directa.
La pérdida de aproximadamente 8,5 BTC sufrida por DotSwap V1 refuerza la importancia de prestar a la arquitectura de custodia, los permisos de firma y la seguridad operativa tanta atención como a la utilidad del token o al volumen de trading. En un entorno cripto cada vez más automatizado, la autocustodia informada y la verificación cuidadosa de las transacciones siguen siendo defensas esenciales.
