Más allá del almacenamiento seguro, parte 1: diseño de flujos de trabajo seguros para pagos y firmas

El relato preliminar de Binance sobre el incidente del 30/10/2026 describe cómo un token de despliegue robado permitió acceder al servicio interno de firma y realizar transacciones fuera del proceso habitual de retiro [1]. Según la vía de ataque divulgada, el atacante podía solicitar firmas sin leer antes la clave privada de la billetera.

En este caso, el atacante apunta a la capacidad del sistema para firmar. El almacenamiento seguro, incluidos el cifrado y el aislamiento mediante hardware, puede proteger la clave, pero no puede determinar si un pago cuenta con una autorización comercial válida. Esto plantea la pregunta: ¿cómo obtiene una operación no autorizada una firma válida?

Para responderla, hay que seguir el recorrido de una solicitud comercial hasta convertirse en una transacción firmada y ejecutada. Un pago realizado a través de una billetera pasa por la autorización comercial, la construcción de la transacción, la firma, y la ejecución y liquidación [2, 3]. La figura muestra el abuso de ese flujo de trabajo junto a otra vía para adquirir capacidad de firma: recuperar la clave aprovechando fallos de implementación criptográfica.

La serie Más allá del almacenamiento seguro utiliza incidentes reales para derivar principios de diseño e implementación que permitan abordar estos riesgos. La parte 1, Diseño de flujos de trabajo seguros para pagos y firmas, examina cómo los atacantes hacen un uso indebido de la capacidad de firma del sistema original sin obtener sus claves privadas. La parte 2, Implementación segura de la criptografía de billeteras, examina fallos de implementación que permiten a los atacantes recuperar claves y firmar por su cuenta. Ninguna de las dos vías exige robar directamente el secreto protegido.

La sección 1 utiliza incidentes reales para examinar los riesgos y los supuestos que pueden pasarse por alto a lo largo del flujo de pagos y, a partir de ellos, deriva comprobaciones de diseño e implementación para abordarlos. La sección 2 parte del supuesto de que esas comprobaciones no han impedido una operación no autorizada y examina cómo limitar las pérdidas resultantes. La sección 3 explica cómo las revisiones de diseño, las auditorías, las pruebas de penetración y los ejercicios pueden verificar tanto la prevención como la contención de pérdidas.

1. Diseño para prevenir operaciones no autorizadas

Un mismo flujo de pagos puede servir para distintos fines comerciales. La figura presenta tres operaciones representativas de custodia: los depósitos establecen el derecho del cliente sobre el saldo de su cuenta, los retiros responden a instrucciones de los clientes y las transferencias de tesorería ejecutan decisiones institucionales de financiación.

Los depósitos validados generan un crédito en la cuenta, no una instrucción automática de pago. Un retiro requiere una solicitud y una aprobación independientes del cliente; una transferencia de tesorería parte de una decisión institucional de financiación. Ambos procesos continúan con la construcción de la transacción, la firma, la ejecución y la liquidación. En la custodia mancomunada, el libro contable registra los derechos de los clientes sin exigir que los activos permanezcan en una dirección exclusiva para cada uno.

Tres operaciones representativas de custodia. La separación funcional no establece por sí sola identidades independientes ni límites de permisos.

Estas operaciones responden a motivos distintos para mover fondos. Otras operaciones comerciales pueden seguir las mismas etapas, pero requerir pruebas o aprobaciones diferentes. En cada etapa, la cuestión de seguridad es si el fundamento del pago, la transacción, el uso de la autoridad de firma y la liquidación siguen correspondiendo a la operación prevista.

Cada una de estas etapas puede convertirse en un punto donde un atacante influya en lo que se firma o ejecuta. Una solicitud falsificada puede crear una aparente obligación de pago; la construcción de la transacción puede introducir una operación no aprobada; los permisos comprometidos pueden dar acceso a la firma; y los fallos de ejecución o liquidación pueden dejar utilizable una autorización no deseada o provocar un pago injustificado.

La siguiente tabla relaciona los riesgos con sus etapas del flujo de trabajo y los casos utilizados para examinarlos.

1,1 Fundamento y autorización del pago

Antes de que un pago pase a la construcción y firma de la transacción, la institución debe comprobar que existe una solicitud auténtica, que el solicitante tiene derecho a mover los fondos y que la operación especificada cuenta con una aprobación válida. Ni el saldo de un cliente ni una solicitud interna autenticada, por sí solos, acreditan las tres cosas.

Casos de fallo: fundamento de pago inventado

En el incidente de Bitget del 24/09/2026, el atacante aprovechó un producto de seguridad de terceros para obtener credenciales internas de alto nivel. Según el relato oficial de Bitget, esas credenciales se utilizaron para enviar órdenes de retiro fraudulentas al sistema de billeteras, lo que dio lugar a transferencias que eludieron los controles de riesgo existentes [4]. Las órdenes llegaron al proceso de pagos mediante acceso interno, pero ese acceso no acreditaba una instrucción legítima de un cliente ni una decisión de tesorería.

BigONE comunicó movimientos no autorizados de sus billeteras calientes el 16/07/2025 y afirmó que sus claves privadas seguían protegidas. BigONE Eurasia atribuyó el incidente de la plataforma global a cambios en la lógica de cuentas y de control de riesgos del entorno de producción [5, 6]. Esto apunta a un problema relacionado: los registros y las reglas utilizados para justificar un pago también pueden alterarse. El relato público no revela los registros detallados de las solicitudes ni la API de firma, por lo que no permite establecer que el mecanismo de ataque fuera el mismo que en Bitget.

Estos casos ponen de manifiesto el riesgo de considerar el acceso interno o los registros de cuentas como fundamento suficiente para un pago: un atacante puede alterar las credenciales, los registros o las reglas de los que depende esa decisión.

Controles que deben verificarse

Por lo tanto, las revisiones de diseño e implementación deben comprobar si cada solicitud puede vincularse con un fundamento comercial auténtico y si quien la presenta también puede falsificar los registros que la respaldan o aprobarla.

• Verificar el origen, la integridad y la autorización de las solicitudes. Cada pago debe poder vincularse con una instrucción auténtica de un cliente, un evento comercial o una decisión institucional, con pruebas del derecho a disponer de los fondos y de la aprobación. Verifique que los cambios en la solicitud y en los registros que la respaldan sigan siendo rastreables, y que las pruebas falsificadas o alteradas no puedan acreditar una autorización por el mero hecho de proceder de un servicio interno o coincidir con el saldo de una cuenta.
• Mantener la validación y la aprobación independientes de la creación de solicitudes. Quien presenta una solicitud no debe poder falsificar también las pruebas que la respaldan ni aprobarla. Mantenga esta separación tanto en los permisos operativos como en los administrativos. Verifique si los cambios en los registros, las reglas de aprobación o las asignaciones de roles —incluidas las excepciones manuales y los procedimientos de recuperación— podrían permitir que una sola parte controle la solicitud y las comprobaciones destinadas a rechazarla.

Una vez establecido de forma independiente el fundamento del pago, la siguiente cuestión es si la transacción expresa la operación aprobada.

1.2 Construcción y verificación de la transacción

Una vez aprobada una solicitud de pago, el componente que construye la transacción la convierte en los datos sin firmar que se envían para su firma. La carga útil completa —incluidos el destino, el importe, la operación y cualquier cambio en el control de la billetera— debe expresar la solicitud aprobada. Aprobar una transferencia no autoriza operaciones adicionales; la verificación debe examinar los datos reales que se van a firmar, no solo su descripción en una interfaz.

Casos de fallo: las operaciones firmadas difieren de lo aprobado

Bybit tenía previsto transferir ETH de una billetera fría a una billetera templada. Su comunicado oficial atribuye la intrusión a la vulneración de las credenciales de un desarrollador de Safe, que permitió acceder a la infraestructura del proveedor y engañar a los firmantes [7]. Safe verifica las firmas de campos de la transacción, entre ellos to, value, data y operation, mediante execTransaction [15]. Sin embargo, la interfaz comprometida conservó la apariencia de la transferencia prevista mientras sustituía campos por otros maliciosos antes de la firma. Las firmas eran válidas para los bytes introducidos mediante esa sustitución [7].

La transacción resultante utilizó DELEGATECALL para cambiar la implementación de la billetera, lo que permitió al atacante vaciar los activos sin una nueva aprobación de los propietarios originales [7, 8]. La operación comercial aprobada era una transferencia; la operación firmada cambió quién podía controlar la billetera. Comprobar el destinatario mostrado o el valor inmediato de la transacción no habría permitido determinar si la operación completa coincidía con lo aprobado.

El incidente de Kiln/SwissBorg muestra que también pueden introducirse transacciones maliciosas modificando un servicio de creación de transacciones en ejecución. Kiln informó de que un token de GitHub comprometido permitió acceder a credenciales de producción a través de flujos de trabajo de CI. El atacante modificó un pod de Kubernetes en ejecución, sin cambiar la imagen desplegada, para que devolviera una transacción que cambiaba la autoridad de retiro junto con una transacción legítima de desactivación de stake en Solana. Los firmantes del servicio de custodia del cliente aprobaron la transacción añadida; Kiln fecha la firma el 31 de agosto y la detección el 08/09/2025 [9]. SwissBorg también atribuyó la manipulación de la transacción a la infraestructura del proveedor. Las partes discreparon sobre la facilidad de uso y la integración de las herramientas de decodificación disponibles en ese momento [10].

Controles que deben verificarse

Los casos de Bybit y Kiln/SwissBorg muestran cómo una transacción puede diferir de lo que el firmante pretendía aprobar. El diseño debe vincular la aprobación a la operación completa, y la verificación debe examinar la transacción real de forma independiente del servicio que la creó o la mostró.

• Vincular la aprobación a la operación completa. La aprobación debe abarcar todos los efectos de la transacción, incluido cualquier cambio en el control de los activos o cualquier delegación de la autoridad de ejecución [16]. Los cambios fuera de ese alcance requieren una nueva aprobación. Debe verificarse que las operaciones sustituidas o añadidas no puedan ampararse en la aprobación de un pago legítimo y que los reintentos no puedan reutilizar una aprobación para autorizar pagos adicionales.
• Verificar de forma independiente la transacción y sus efectos. Deben compararse los datos reales enviados para su firma con la operación comercial aprobada, abarcando cada transacción de un lote y sus efectos sobre los activos y los permisos. La verificación debe ser independiente del servicio que crea o muestra la transacción. Debe comprobarse si ese servicio puede alterar el verificador o eludir sus comprobaciones, y si se rechazan las presentaciones engañosas o las transacciones modificadas.

Las comprobaciones anteriores abordan si la transacción coincide con la solicitud aprobada. La fase de firma plantea otra pregunta: ¿puede alguien utilizar la clave sin la autorización comercial requerida, ya sea directamente o cambiando los permisos de acceso?

1,3 Autorización de firma y uso de claves

Una transacción verificada debe llegar al servicio de firma a través de un solicitante autorizado. Las políticas de claves y los roles administrativos determinan quién puede utilizar la clave pertinente y quién puede modificar ese acceso. El permiso para solicitar una firma no autoriza todas las transacciones, y el permiso para administrar el servicio no debe crear una vía de firma sin controles. Por tanto, esta fase abarca tanto el uso de la clave para la operación aprobada como la autoridad sobre el acceso a la clave.

Casos de fallo: acceso a la firma comprometido

El incidente de Resolv del 22/03/2026 muestra cómo un cambio en la política de acceso a la clave puede abrir una vía de firma. Su proceso de emisión requería que un usuario depositara garantías y que un servicio autorizado fuera de la cadena finalizara la emisión. El informe oficial posterior al incidente describe cómo el acceso al repositorio y a la nube llevó a un rol con mayores privilegios que modificó la política de acceso de la clave de firma después de que se denegaran intentos de acceso anteriores. Ese cambio otorgó al atacante autoridad de firma en un servicio de gestión de claves en la nube que requería tanto permisos a nivel de identidad como una política de acceso a nivel de clave [11].

Al cambiar quién podía firmar, el atacante pudo autorizar emisiones fuera de la relación prevista con las garantías sin tener que convencer al firmante original. El relato establece que obtuvo control sobre la autoridad de firma, no que extrajo el material de la clave privada en bruto.

La actualización preliminar de Binance sobre su incidente del 30/10/2026 describe otra vía para obtener autoridad de firma. Según Binance, dispositivos de empleados comprometidos y una herramienta interna de IA permitieron acceder a los dispositivos de ingenieros de billeteras; luego se utilizó un token de despliegue de contenedores robado para desplegar un contenedor y ejecutar scripts maliciosos. El atacante obtuvo acceso no autorizado al servicio interno de firma de billeteras e inició transacciones fuera del proceso normal de retiro [1]. Este relato vincula la autoridad de despliegue con el acceso al servicio de firma, pero no revela qué comprobaciones internas de permisos se eludieron exactamente. A diferencia del cambio en la política de claves comunicado por Resolv, la vía de entrada divulgada en este caso pasa por el entorno operativo del servicio de firma.

Controles que deben verificarse

Estos casos ponen de manifiesto el riesgo de obtener o utilizar acceso a la firma fuera del flujo de trabajo comercial previsto. Las revisiones deben comprobar si todas las vías de firma exigen autorización comercial, incluidas las abiertas mediante cambios de políticas o privilegios de despliegue.

• Exigir autorización comercial en todas las vías de firma. El permiso para utilizar una clave no constituye una autorización para una operación concreta [17, 18, 19]. Debe restringirse el uso de la clave al alcance comercial aprobado y verificarse que otros solicitantes o el acceso directo no puedan eludir esa restricción. La aplicación de la autorización debe seguir siendo independiente de cualquier solicitante capaz de enviar solicitudes de firma arbitrarias. Cuando una vía no pueda cumplir este requisito, debe documentarse la brecha y evaluarse sus consecuencias conforme a la sección 2.
• Controlar los cambios en la autoridad de firma. Los permisos administrativos y de despliegue pueden crear acceso a la firma incluso cuando la identidad inicial no puede firmar [20, 21, 22]. Debe separarse el uso de las claves de la autoridad para cambiar las políticas de firma, las identidades o el código desplegado, y exigirse una aprobación independiente de esos cambios. Debe verificarse que ninguna parte pueda combinar sus permisos para concederse acceso a la firma o eliminar los controles comerciales que rigen ese acceso.

Las comprobaciones de autorización no pueden terminar cuando se emite una firma: la transacción aún debe ejecutarse dentro de las condiciones aprobadas, y su resultado debe liquidarse correctamente.

1,4 Ejecución y liquidación

La autorización también debe mantenerse después de la firma, durante la difusión y ejecución de la transacción y la liquidación de los registros comerciales y las reservas de saldo asociados. Una firma no demuestra que se haya completado un pago. La ejecución debe mantenerse dentro del alcance y las condiciones de validez de la autorización; la liquidación debe establecer qué obligación se cumplió y si efectivamente corresponde realizar otro pago. Ni una firma existente ni una transferencia observada bastan por sí solas para establecer una nueva obligación de pago.

Casos de fallo: uso indebido de autoridad firmada y retroalimentación de la liquidación

Drift ilustra cómo una solicitud de firma engañosa puede dejar una autoridad utilizable más adelante. En su incidente del 01/04/2026, las aprobaciones obtenidas por adelantado se conservaron en transacciones de Solana con nonces duraderos y se enviaron posteriormente para tomar el control de la autoridad administrativa [12]. Un nonce duradero controla la validez de la transacción; es distinto del nonce secreto utilizado en la firma criptográfica. Permite enviar transacciones sin conexión o con retraso sin que se aplique el vencimiento habitual del hash de bloque reciente, aunque los cambios en el estado de una cuenta o un programa aún pueden impedir la ejecución. Al avanzar el nonce, se invalidan las transacciones vinculadas al valor anterior [23].

La actualización de Drift sobre la recuperación, publicada el 16 de abril, propuso dispositivos dedicados a la firma, verificación fuera de la interfaz principal de firma, períodos de espera para las acciones administrativas críticas y la desactivación de los nonces duraderos para los firmantes [24]. Estas medidas abordan tanto lo que aprueban los firmantes como el momento en que puede ejecutarse la operación firmada. Se anunciaron como un plan de recuperación; la actualización no establece que ya se hubieran implementado.

Chainflip distingue entre los intercambios de clientes, los retiros de proveedores de liquidez (LP) y las operaciones internas de recogida de depósitos denominadas fetches [25]. En Tron, los memos de las transacciones pueden contener instrucciones de intercambio. En el relato que Chainflip publicó el 15 de septiembre sobre su incidente del 12/09/2026, un atacante presentó un fetch firmado por validadores con un memo malformado bajo su control. La capa de observación interpretó erróneamente el contexto como un intercambio fallido y emitió reembolsos además de los retiros normales de LP, lo que provocó que seis retiros se pagaran dos veces [13, 14].

El error convirtió un movimiento interno de activos en prueba de una nueva obligación frente a un cliente. Chainflip había interpretado los memos incluso cuando las transferencias a su bóveda estaban encapsuladas en otras llamadas a contratos. La corrección restringió la interpretación de los memos de intercambio a transferencias simples de TRX o transferencias directas de TRC-20, y excluyó las llamadas encapsuladas [14]. Un fetch firmado válidamente tenía su propia finalidad; su ejecución no justificaba un reembolso adicional.

Controles que deben verificarse

Las transacciones firmadas pueden seguir siendo ejecutables durante más tiempo del previsto, y la información sobre su ejecución puede confundirse con una nueva obligación de pago. Por ello, las revisiones deben comprobar que las condiciones de ejecución se apliquen efectivamente y que cada pago o reembolso corresponda a una obligación real y pendiente de liquidación.

• Aplicar las condiciones de ejecución aprobadas. Las transacciones firmadas deben seguir sujetas al alcance, el período de validez y las condiciones de cancelación aprobados. Verifique si las transacciones antiguas aún pueden ejecutarse después de su vencimiento o cancelación, o tras un cambio en la autorización. Vincule las condiciones pertinentes a la operación firmada y verifique que las reglas de la cadena o la lógica de ejecución de la billetera las apliquen; un registro en el sistema de negocio, por sí solo, no es suficiente.
• Liquidar únicamente obligaciones reales y pendientes. Cada pago o reembolso debe corresponder a una obligación real que aún no se haya liquidado. Conserve el vínculo entre el evento de negocio original, los intentos de pago y los resultados confirmados. Verifique que los reintentos, las notificaciones duplicadas, los resultados inciertos o las transferencias internas no puedan generar un pago injustificado, y que las reglas para interpretar las pruebas de ejecución no puedan modificarse para eludir estas comprobaciones.

2. Diseñar para limitar las pérdidas y permitir la respuesta a incidentes

La sección 1 utilizó pruebas de incidentes para identificar los riesgos de los flujos de trabajo y las verificaciones de diseño e implementación necesarias para abordarlos. Aquí suponemos que esas verificaciones no han impedido una operación no autorizada, ya sea por una omisión, un error de implementación o una elusión. En ese caso, el diseño debe limitar cuánto puede mover el atacante, contabilizar los fondos que siguen expuestos y preservar la capacidad de detectar abusos y detener nuevas salidas de fondos. Estas medidas de contención de pérdidas deben diseñarse y probarse antes de un incidente, junto con los controles preventivos.

La tabla resume tres objetivos de diseño para limitar las pérdidas y permitir la respuesta a incidentes.

2,1 Límites de gasto aplicados de forma independiente

Aunque un pago no autorizado supere las verificaciones anteriores, el sistema debe limitar cuánto pueden mover ese pago y los posteriores. Esto requiere un presupuesto cuyos límites se apliquen fuera del ámbito que se supone bajo el control del atacante y que abarque tanto las transacciones individuales como el gasto acumulado. Un límite configurado no establece tal cota si el servicio de aprobación o el firmante comprometidos pueden desactivarlo o eludirlo.

• Aplicar los límites de forma independiente de la aprobación de pagos. Un pago que supere las verificaciones de autorización debe seguir sujeto a límites de gasto aplicados fuera del ámbito que se supone bajo el control del atacante. Verifique que todas las vías de firma y ejecución respeten estos límites, incluidas las vías de ejecución alternativas [26, 27], y que el atacante no pueda modificar ni desactivar su aplicación. Cuando no pueda aplicarse un límite independiente, no presente un presupuesto configurado como una cota de las pérdidas.
• Limitar el gasto acumulado, no solo los pagos individuales. Defina el alcance, el período y la base de valoración de cada presupuesto, con una contabilización coherente de los pagos completados y los importes reservados. Verifique que las solicitudes repetidas, las operaciones concurrentes y los reintentos no puedan superar el límite en conjunto ni liberar las reservas antes de tiempo. Cuando los límites dependan de los precios de los activos, verifique que los precios manipulados, desactualizados o no disponibles no puedan aumentar el gasto permitido.

2,2 Fondos disponibles, reposiciones y transacciones firmadas pendientes

La siguiente pregunta es qué fondos siguen en riesgo mientras la institución detecta y contiene el ataque. Los saldos de las billeteras, las reposiciones y las autorizaciones firmadas pendientes determinan esa exposición, incluidos los fondos que llegan después de que comienza el incidente. Evalúelos junto con los límites aplicables de la sección 2,1; un saldo actual, por sí solo, no constituye una estimación de las pérdidas.

• Limitar los fondos a los que podría acceder un atacante. Evalúe el alcance total de la autorización de firma afectada sobre los activos, incluidas otras billeteras, cadenas y contratos. Incluya los saldos existentes y las entradas posteriores de fondos. La reposición debe contar con una autorización independiente y un límite acumulado. Verifique que las salidas repetidas de fondos no puedan provocar reposiciones continuas desde la tesorería y que la aportación de nuevos fondos pueda redirigirse o detenerse sin pasar por alto los depósitos que sigan llegando.
• Incluir los fondos expuestos por autorizaciones firmadas pendientes. Detener la emisión de nuevas firmas no invalida necesariamente las transacciones o autorizaciones ya emitidas. Identifique los fondos que estas aún pueden mover sin contabilizar los mismos activos dos veces. Verifique que los pagos confirmados se registren como gastados y que sus reservas se concilien, mientras que las transacciones no ejecutadas conserven sus reservas hasta que existan pruebas fiables de que ya no pueden ejecutarse. Un tiempo de espera local o una solicitud de cancelación, por sí solos, no deben reducir la exposición registrada.

2,3 Monitoreo independiente y respuesta a incidentes

Los límites y los controles de financiación restringen las posibles pérdidas; el monitoreo y la respuesta determinan durante cuánto tiempo puede seguir operando un atacante. La institución necesita pruebas que revelen el abuso incluso cuando el servicio de pagos considere válidas las operaciones, así como una vía de respuesta que siga siendo utilizable si el entorno operativo habitual no está disponible o está comprometido.

El relato preliminar de Binance muestra por qué apagar una aplicación, por sí solo, podría no bastar: apagarla no eliminó una delegación EIP-7702 existente. La revocación requirió transacciones en cadena y, en su implementación de MPC, un procedimiento diseñado por separado [1]. Se trataba de una limitación de esa implementación, no de una incapacidad inherente de MPC para revocar autorizaciones. Por tanto, la detección y la contención necesitan validaciones separadas: las pruebas fiables deben conducir a una acción que interrumpa efectivamente la vía de pérdida.

• Detectar la actividad no autorizada mediante pruebas protegidas de forma independiente. Compare las aprobaciones de negocio con la actividad de firma y los resultados de ejecución, y monitoree los cambios en los permisos y las reglas de control. El servicio afectado no debe poder reescribir las pruebas en las que se basa el monitoreo. Verifique que las operaciones aceptadas por el flujo de trabajo aún puedan activar alertas que permitan actuar cuando sean incompatibles con la autorización de negocio, incluso si faltan registros locales o estos han sido manipulados.
• Mantener disponibles y eficaces los controles de respuesta. Mantenga una autoridad independiente para detener la emisión de nuevas firmas y la aportación de fondos, e invalidar las transacciones pendientes o revocar las autorizaciones continuas cuando sea posible. Verifique que la respuesta siga siendo posible cuando el acceso operativo habitual no esté disponible o esté comprometido, y que las medidas bloqueen efectivamente nuevas salidas de fondos. Identifique la exposición residual y las necesidades de coordinación externa; detener una aplicación no revoca por sí mismo una autorización firmada, y no puede darse por sentada la recuperación de los activos.

3. Validación del diseño y la implementación

Las secciones anteriores plantean si las comprobaciones del flujo de trabajo impiden las operaciones no autorizadas y si es posible limitar las pérdidas cuando no lo consiguen. La validación debe examinar ambos objetivos en el sistema desplegado, incluida la forma en que interactúan los controles a lo largo del flujo de fondos. Los siguientes métodos aportan pruebas complementarias:

• Evaluación de la arquitectura y del diseño de seguridad comprueba si el flujo de fondos, los límites de autoridad y las dependencias entre controles respaldan los objetivos previstos de prevención y contención de pérdidas. Debe hacer explícitos los supuestos en los que se basan la independencia de los controles y los límites de pérdidas.
• Auditoría del código y la configuración verifica que el código, la configuración y los permisos desplegados implementen las comprobaciones previstas, incluidas las excepciones y las rutas alternativas que podrían eludirlas.
• Pruebas de penetración examinan si es posible combinar vulnerabilidades de las aplicaciones y la infraestructura para eludir los controles de autorización o de pérdidas. Su alcance debe seguir las rutas completas de los fondos, sin detenerse en componentes individuales.
• Ejercicios de ataque y respuesta verifican que la supervisión dé lugar a medidas oportunas y que los límites de gasto, las pausas y la revocación funcionen de manera conjunta. Deben determinar qué fondos siguen en riesgo y cuánto tiempo lleva contener eficazmente las pérdidas.

Para cada escenario de validación, especifique la operación que debería rechazarse o la pérdida que debería contenerse, junto con las capacidades que se atribuyen al atacante. Registre el resultado observado, cualquier exposición residual y las condiciones de las que depende el límite de pérdidas declarado. Repita las comprobaciones pertinentes tras cambios sustanciales en el código, la configuración o los permisos.

Los equipos o expertos externos en seguridad pueden complementar a los equipos internos en estas evaluaciones, auditorías, pruebas y ejercicios. Su revisión debe abarcar cómo interactúan la lógica de pagos, la infraestructura de firma y los permisos operativos, y aportar pruebas de la capacidad del sistema para prevenir operaciones no autorizadas y contener las pérdidas.

4. Conclusión

Los ataques examinados aquí ponen de manifiesto fallos de autorización desde la solicitud inicial de pago hasta la construcción, firma, ejecución y liquidación de la transacción. También muestran qué necesita un sistema para limitar las pérdidas cuando un atacante logra superar los controles. Los principios de diseño resultantes abarcan la prevención, la contención y las pruebas necesarias para evaluar ambas en la práctica.

La conclusión central es que proteger las claves privadas no garantiza, por sí solo, que las operaciones firmadas estén autorizadas. La operación que finalmente se ejecuta debe corresponder a una decisión de negocio genuina, y los controles independientes deben limitar las consecuencias cuando las comprobaciones del flujo de trabajo no consiguen impedir una operación no autorizada. Esto exige revisar el flujo de trabajo completo, incluidos los permisos que pueden modificar sus comprobaciones y las herramientas necesarias para detectar y detener pérdidas adicionales.

Este análisis se centró en el uso indebido de la capacidad de firma del sistema original. La parte 2, Implementación segura de la criptografía de billeteras, aborda una vía distinta: fallos de implementación que permiten a los atacantes predecir o recuperar claves privadas sin robar directamente los secretos protegidos y, después, firmar fuera del flujo de trabajo original.

Referencias

• [1] Binance, en chino: Incidente de seguridad del 30/10/2026: conclusiones preliminares y actualización sobre la respuesta (03/11/2026); en inglés: Incidente de seguridad del 30/10/2026: conclusiones preliminares y actualización sobre la respuesta (03/11/2026).
• [2] BlockSec, Gestión de claves y seguridad operativa para pagos con criptomonedas.
• [3] BlockSec, Arquitectura de los sistemas de pago con criptomonedas: las 6 capas y cómo circula el dinero a través de ellas.
• [4] Bitget, Explicación del hackeo de Bitget: cronología, impacto y respuesta de seguridad (actualizado el 20/10/2026).
• [5] BigONE, Anuncio sobre el incidente de seguridad de BigONE del 16/07/2025.
• [6] BigONE Eurasia, Mantenimiento temporal de la plataforma (16/07/2025).
• [7] Bybit, Confirma la integridad de su seguridad tras el incidente de Safe{Wallet} (26/02/2025).
• [8] BlockSec, Hackeo de Bybit por 1,5 mil millones USD: análisis detallado del ataque mediante una actualización maliciosa de Safe Wallet.
• [9] Kiln, Restablecimiento de los servicios de Kiln e información sobre el incidente de seguridad (07/10/2025).
• [10] SwissBorg, Información de seguridad sobre la brecha de Kiln del 8 de septiembre de 2025 y su impacto en SwissBorg.
• [11] Resolv, Análisis retrospectivo de Resolv: incidente del 22/03/2026 (04/04/2026).
• [12] BlockSec, Incidente de Drift Protocol: compromiso de la gobernanza multifirma mediante la explotación de un nonce duradero.
• [13] Chainflip, Explotación de Tron USDT: qué ocurrió y qué sucederá después (13/09/2026).
• [14] Chainflip, Restablecimiento del funcionamiento de Chainflip (15/09/2026).
• [15] Safe, execTransaction.
• [16] Ethereum, EIP-7702: establecer código para las EOA.
• [17] AWS KMS, API Sign.
• [18] Google Cloud KMS, cryptoKeyVersions.asymmetricSign.
• [19] Azure Key Vault, API Sign.
• [20] Google Cloud KMS, Separación de funciones.
• [21] Google Cloud IAM, Roles para la autenticación de cuentas de servicio.
• [22] AWS IAM, Conceder permisos para pasar un rol a un servicio de AWS.
• [23] Solana, Firma de transacciones duraderas y sin conexión mediante nonces.
• [24] Drift, Actualización sobre la recuperación tras el incidente (16/04/2026).
• [25] Chainflip, Diseño de la bóveda EVM (Ethereum).
• [26] Safe, Guardas.
• [27] Safe, Módulos.