La persona que solicita un pago ha superado la verificación de identidad. El pago ha sido aprobado y la firma de la transacción es válida. ¿Significa eso que los fondos están seguros?
No necesariamente.
En 2025, BigONE perdió alrededor de 27 millones USD, mientras que Bybit sufrió un ataque de 1,5 mil millones USD. En octubre de 2026, Binance informó de un incidente de seguridad que afectó a aproximadamente 6,34 mil millones USD en activos digitales. Estos incidentes muestran por qué el almacenamiento seguro de las claves privadas, por sí solo, no puede garantizar la seguridad de los fondos.
Por tanto, las instituciones deben mirar más allá del almacenamiento seguro de las claves privadas. ¿Qué justifica el pago? ¿Qué se está firmando exactamente? ¿Quién determina si una transacción puede firmarse? Y, tras su ejecución, ¿cómo determina el sistema si el pago se ha completado?
En este artículo, BlockSec utiliza incidentes divulgados públicamente para examinar riesgos de autorización que suelen pasarse por alto a lo largo del ciclo de vida del pago, desde su inicio hasta su liquidación.
Nuestra próxima serie técnica, Más allá del almacenamiento seguro, analizará en detalle dos vías de ataque:
-
Abusar de las capacidades de firma de un sistema sin obtener sus claves privadas.
-
Aprovechar fallos en las implementaciones criptográficas para recuperar esas claves.
¿En qué puntos puede desviarse un pago con criptomonedas?
Un pago efectuado mediante una billetera suele comprender cuatro etapas:
-
Fundamento y autorización del pago.
-
Construcción y verificación de la transacción.
-
Autorización de la firma y uso de las claves.
-
Ejecución y liquidación.
1. Fundamento y autorización del pago
Antes de firmar una transacción, la institución debe verificar que el pago subyacente sea legítimo:
• Para un retiro de un cliente, la plataforma debe verificar la identidad del cliente, confirmar que hay fondos suficientes y comprobar que la solicitud cumple sus reglas de negocio.
• Una transferencia interna también requiere la aprobación correspondiente del área de tesorería.
Pero un atacante puede alterar los registros de las cuentas o la lógica de control de riesgos. El sistema puede entonces seguir su flujo de trabajo habitual y aprobar un pago que nunca debería haberse efectuado.
Por ejemplo, el 16/07/2025, BigONE divulgó un incidente de seguridad relacionado con una billetera caliente, con pérdidas estimadas en 27 millones USD. BigONE afirmó que sus claves privadas seguían estando seguras. La investigación de SlowMist informó de que el atacante había modificado la lógica del servidor relacionada con las cuentas y los controles de riesgos, lo que permitió transferencias no autorizadas.
La cuestión clave es que la información y las reglas utilizadas para aprobar el pago ya habían sido alteradas antes de la firma.
Por tanto, para las instituciones de pago no basta con verificar que una solicitud procede de un servicio interno. Cada pago debe poder vincularse con una instrucción del cliente o una decisión de tesorería verificable de forma independiente. Las instituciones también deben comprobar si una sola identidad comprometida podría fabricar solicitudes, alterar registros y cambiar las reglas de aprobación.
2. Construcción y verificación de la transacción
¿Lo que ves es realmente lo que pretendes firmar?
Una vez aprobado un pago, el sistema debe convertir los datos de negocio, como la dirección del destinatario y el importe, en datos de transacción que la billetera pueda firmar.
Si este proceso se ve comprometido, la interfaz puede mostrar una transferencia mientras que la transacción enviada para su firma cambia, en realidad, quién controla la billetera.
Tu firma podría entonces autorizar a un atacante a tomar el control de la billetera, aunque creas estar aprobando una transferencia.
El ataque contra Bybit por aproximadamente 1,5 mil millones USD en 2025 ilustra este riesgo. Bybit pretendía transferir ETH de una billetera fría a una billetera templada. El atacante comprometió la interfaz de Safe e hizo que una transacción maliciosa pareciera una transferencia rutinaria. Los firmantes la aprobaron y, sin saberlo, autorizaron un cambio en la lógica de control de la billetera.
El atacante utilizó las firmas válidas para sustituir la lógica de control de la billetera y, después, empleó la nueva lógica para mover activos sin obtener una nueva aprobación de los propietarios originales para cada retiro posterior. Para consultar un análisis detallado en cadena, véase el análisis de BlockSec sobre el ataque a Bybit por 1,5 mil millones USD.
La lección es clara:
La verificación previa a la firma debe abarcar la transacción completa que se va a firmar y los efectos de su ejecución. No puede basarse únicamente en lo que muestra la interfaz. Incluso varios firmantes pueden no detectar un problema si todos se basan en la misma vista comprometida.
Las transferencias, las actualizaciones de la billetera y los cambios en los permisos de retiro también deben tener requisitos de autorización distintos. La aprobación de una transferencia ordinaria no debería poder utilizarse para cambiar el control de la billetera.
3. Autorización de la firma y uso de las claves
¿Quién puede firmar y quién puede cambiar las reglas de firma?
Aunque los atacantes no puedan firmar transacciones directamente, pueden obtener un control equivalente cambiando las reglas o sustituyendo el código que se ejecuta en el sistema.
Por ello, los permisos administrativos que rigen el acceso a las claves de firma requieren el mismo escrutinio que los propios permisos de firma.
Según el informe retrospectivo oficial de Resolv sobre su incidente de seguridad de marzo de 2026, los intentos iniciales del atacante de obtener acceso para firmar fracasaron. Después, el atacante utilizó un rol privilegiado para cambiar la política de acceso a la clave y concederse autorización para firmar. Con esa autorización, el atacante emitió 80 million USR mediante dos transacciones no autorizadas.
En otro incidente, el informe inicial de Binance sobre el incidente describe una vía distinta para obtener acceso a la firma. El atacante utilizó el dispositivo comprometido de un empleado y una herramienta interna de IA para acceder a los dispositivos de los ingenieros de billeteras. Con un token robado para el despliegue de contenedores, el atacante desplegó un contenedor y ejecutó un script malicioso. El acceso no autorizado al servicio interno de firma de billeteras permitió entonces que las transacciones eludieran el flujo de trabajo habitual de retiros.
Los puntos de entrada fueron distintos, pero ambos incidentes ponen de manifiesto el mismo problema de fondo:
Proteger las claves también implica controlar quién puede cambiar las políticas de acceso a ellas, modificar el entorno de firma u otorgar permisos de firma.
Por tanto, las instituciones de pago deben examinar las tres preguntas siguientes:
-
¿Quién puede llamar a la API de firma?
-
¿Quién puede conceder permiso para llamarla?
-
¿Quién puede desplegar o modificar el servicio de firma?
La separación de funciones entre la aprobación de negocio, el uso de las claves y los cambios administrativos también debe seguir siendo eficaz cuando se compromete una identidad privilegiada.
4. Ejecución y liquidación
¿Termina el riesgo una vez firmada una transacción?
No necesariamente. Las instituciones también deben considerar cuándo puede ejecutarse una transacción firmada y cómo puede invalidarse.
Riesgo 1: Una transacción firmada puede seguir siendo ejecutable
Una transacción se ha firmado, pero aún no se ha ejecutado. ¿Puede presentarse más adelante?
Bajo algunos mecanismos, sí. Cancelar la solicitud de negocio subyacente no invalida automáticamente una transacción firmada.
En el incidente de Drift Protocol del 01/04/2026, el atacante utilizó el mecanismo de nonce duradero de Solana para mantener válidas transacciones firmadas de antemano más allá del breve período de validez de las transacciones ordinarias. Mientras el nonce correspondiente no se hubiera consumido ni avanzado, las transacciones aún podían presentarse para su ejecución más adelante.
Cuando se cancela una solicitud de negocio o se detecta actividad sospechosa, las instituciones necesitan un procedimiento definido para invalidar las transacciones firmadas pero no ejecutadas. También deben especificar quién está autorizado para hacerlo.
Riesgo 2: Una transferencia interna puede interpretarse erróneamente y dar lugar a un reembolso adicional
El 12/09/2026, Chainflip sufrió una explotación relacionada con USDT en Tron. El atacante añadió un memo elaborado a una transacción que los validadores ya habían firmado. El sistema de Chainflip interpretó erróneamente el memo como un intercambio independiente, consideró que ese intercambio había fallado y emitió un reembolso. Chainflip informó de seis pagos no autorizados por un total aproximado de 736,4 mil USDT.
Una transferencia en cadena no representa necesariamente un nuevo pago de un cliente ni justifica un reembolso. Antes de efectuar un pago o emitir un reembolso, el sistema también debe verificar el origen de los fondos, el tipo de operación de negocio y si la obligación de pago correspondiente ya se ha cumplido.
¿Qué tan resiliente es su sistema de pagos?
Estos casos muestran que los fondos pueden perderse tanto antes como después de la firma. Una firma válida, por sí sola, no demuestra que:
• El pago tenga un fundamento de negocio legítimo.
• La operación firmada coincida con lo aprobado.
• La obligación de pago no se haya cumplido ya.
Por tanto, una evaluación de seguridad útil para una institución de pago debería responder preguntas concretas:
• ¿Puede vincularse cada pago con un fundamento de negocio verificable de forma independiente?
• ¿Coincide la operación completa que se va a firmar con lo aprobado, incluidos los posibles cambios de permisos o las transacciones adicionales?
• Si se compromete una identidad operativa o administrativa, ¿siguen existiendo controles independientes para bloquear o limitar las transferencias de fondos no autorizadas?
• Después de suspender los retiros, ¿pueden seguir utilizándose las firmas existentes y las autorizaciones en cadena para mover fondos? ¿Cómo puede confirmar la institución que la contención es eficaz?
Sin embargo, una revisión puntual de la configuración no puede ofrecer respuestas duraderas a estas preguntas.
Las actualizaciones de software, los cambios de permisos y los cambios en las operaciones de negocio pueden alterar los límites de seguridad existentes. Las instituciones deben volver a evaluar si sus controles siguen siendo eficaces después de esos cambios.
Las herramientas de IA también pueden introducir nuevas superficies de ataque. El monitoreo continuo ayuda a los equipos a detectar actividades sospechosas. Los ejercicios de respuesta a incidentes ponen a prueba si los equipos pueden limitar nuevas salidas de fondos después de que se comprometa una identidad crítica o un entorno de producción.
Para obtener más información sobre cómo evaluar estos riesgos, consulte cómo la solución de seguridad de pagos de BlockSec ayuda a las instituciones a mantenerse seguras en la era de la IA.
Participe en nuestro seminario web: protección de fondos en la era de la IA
Para profundizar en estas preguntas, BlockSec organizará un seminario web, «Protección de fondos en la era de la IA». A partir de incidentes de seguridad recientes que afectaron a plataformas de intercambio y empresas de pagos, la sesión examinará cómo los atacantes acceden a los sistemas que gestionan fondos a través de personas, herramientas y entornos de producción, y cómo las instituciones pueden mejorar la detección de amenazas, las comprobaciones de autorización y la respuesta a incidentes.
Ponentes destacados:
• Yajin Zhou: profesor asociado en The Chinese University of Hong Kong; cofundador y director ejecutivo de BlockSec
• Lei Wu: profesor asociado en Zhejiang University; cofundador y director de tecnología de BlockSec
• Muhui Jiang: director de seguridad de BlockSec
Fecha y hora: miércoles 11/11/2026, a las 7:00 p. m., hora de Singapur (SGT, UTC+8)
Formato: seminario web
Beneficio para los asistentes: durante la sesión se seleccionará a dos instituciones participantes para recibir una evaluación preliminar de seguridad gratuita.
Identificar los riesgos a tiempo es esencial para proteger cada pago.
Invitamos a los directivos, responsables de seguridad y equipos técnicos de las instituciones de pago a examinar con nosotros los puntos ciegos de seguridad a lo largo del ciclo de vida del pago.
Contacte a nuestro equipo de ventas para obtener más información sobre el seminario web.
Visite el sitio web oficial de BlockSec>>>
Únase a nuestra comunidad en Telegram>>>
