Guía de seguridad DeFi: ¿Cómo defenderse eficazmente de los ataques de hackers en la era de la IA?

Escribir artículo: sysls

Compilación: AididiaoJP, Foresight News

Introducción

Al conocer numerosos incidentes de hackeos en protocolos DeFi, me ha generado temor respecto a los «actores estatales». Son expertos en tecnología, con recursos abundantes y juegan a largo plazo; estos supervillanos se enfocan en revisar cada rincón de tu protocolo e infraestructura en busca de vulnerabilidades, mientras que los equipos de protocolos comunes están distraídos en seis o siete áreas de negocio diferentes.

No me considero un experto en seguridad, pero he liderado equipos en entornos de alto riesgo (incluyendo fuerzas armadas y el sector financiero con fondos elevados), y tengo experiencia en pensar y planificar planes de contingencia.

Creo sinceramente que solo los paranoicos sobreviven. Ningún equipo empieza pensando «voy a actuar con indiferencia y superficialidad respecto a la seguridad»; sin embargo, los hackeos aún ocurren. Necesitamos hacerlo mejor.

La IA significa que esto realmente es diferente esta vez

(Origen de datos:

Los hackeos no son raros, pero claramente están en aumento. El primer trimestre de 2026 fue el trimestre con más ataques DeFi registrados hasta la fecha, y aunque el segundo trimestre acaba de comenzar, ya se espera que rompa el récord del trimestre anterior.

Mi hipótesis principal es: la IA ha reducido drásticamente el costo de encontrar vulnerabilidades y ha expandido enormemente la superficie de ataque. La humanidad necesita varias semanas para revisar la configuración de cien protocolos en busca de errores; en cambio, los modelos básicos más recientes pueden hacerlo en unas pocas horas.

Esto debería cambiar radicalmente nuestra forma de pensar y responder a los hackeos. Los protocolos antiguos que confiaban en medidas de seguridad antes de que la IA se volviera poderosa, enfrentan cada vez más el riesgo de ser «eliminados en un segundo».

Pensando en superficie y jerarquías

(Origen de datos:

La superficie de ataque en realidad puede reducirse a tres: el equipo del protocolo, los contratos inteligentes y la infraestructura, y los límites de confianza de los usuarios (DSN, redes sociales, etc.).

Una vez identificadas estas superficies, se superponen capas de defensa:

Prevención: si se implementa estrictamente, puede reducir al máximo la probabilidad de explotación.

Mitigación: cuando la prevención falla, limita la magnitud del daño.

Pausa: nadie puede tomar decisiones óptimas bajo una gran presión. Una vez confirmado un ataque, se activa inmediatamente la desconexión total. Congelar puede detener pérdidas adicionales y ganar tiempo para pensar…

Recuperación: si pierdes control sobre componentes tóxicos o comprometidos, debes descartarlos y reemplazarlos.

Restauración: recupéralo todo lo que hayas perdido. Planifica con anticipación contactos que puedan congelar fondos, revertir transacciones y colaborar en investigaciones.

Principios

Estos principios guían las acciones concretas para implementar cada capa de defensa.

Uso intensivo de IA de vanguardia

Utiliza modelos de IA de última generación para escanear tu código y configuración en busca de vulnerabilidades, y realiza pruebas de red en superficie amplia: intenta encontrar fallos en el frontend para ver si alcanzan el backend. Los atacantes hacen esto. Lo que puedas detectar con escaneos defensivos, ellos ya lo habrán detectado con escaneos ofensivos.

Usa habilidades como pashov, nemesis, y plataformas de IA como Cantina (Apex) y Zellic (V12) para escanear rápidamente tu código antes de una auditoría completa.

El tiempo y la fricción son buenas defensas

Agrega pasos adicionales y bloqueos temporales a cualquier operación que pueda causar daño. Necesitas tiempo suficiente para intervenir y congelar cuando detectes anomalías.

Antes, la resistencia a los bloqueos temporales y pasos múltiples se justificaba por la fricción que generaban para el equipo del protocolo. Ahora, con IA, esa fricción puede ser superada fácilmente en segundo plano.

Invariantes

Los contratos inteligentes pueden construirse defensivamente escribiendo «hechos» inmutables: si estos hechos se rompen, toda la lógica del protocolo colapsa.

Normalmente, solo tienes unos pocos invariantes. Debes elevarlos cuidadosamente al código; forzar múltiples invariantes en cada función se vuelve difícil de gestionar.

Balance de poder

Muchas brechas provienen de wallets comprometidos. Necesitas configuraciones que, incluso si una firma múltiple se ve comprometida, puedan rápidamente limitar daños y devolver el protocolo a un estado gobernable.

Esto requiere un equilibrio entre Gobernanza (que decide todo) y Rescate (que restaura la estabilidad gobernable sin reemplazar o anular la gobernanza).

Siempre habrá problemas

Desde el principio, debes asumir: por muy inteligente que seas, serás hackeado. Tus contratos o dependencias pueden fallar. Podrías ser víctima de ingeniería social, y las nuevas actualizaciones pueden introducir vulnerabilidades imprevistas.

Pensando así, los límites de daño, las restricciones de velocidad y los interruptores de corte del protocolo serán tus mejores aliados. Limita el daño al 5-10%, congela y planifica tu respuesta. Nadie puede tomar decisiones óptimas en medio del fuego cruzado.

El mejor momento para planear es ahora

Antes de ser hackeado, piensa en tu respuesta. Codifica los procesos tanto como puedas y entrena a tu equipo para que no se confundan en el momento crítico. En la era de la IA, esto significa tener habilidades y algoritmos que puedan presentar rápidamente mucha información, y compartir resúmenes y análisis en formatos cortos y largos con tu núcleo.

No necesitas ser perfecto, pero sí sobrevivir. Ningún sistema es invulnerable desde el día uno; a través de iteraciones, aprenderás y te volverás antifrágil.

Que no te hackeen no significa que no puedas ser hackeado. El punto de máxima comodidad suele ser el mayor riesgo.

Medidas preventivas

Diseño de contratos inteligentes

Una vez definidos los invariantes, eleválos a verificaciones en tiempo de ejecución. Piensa cuidadosamente cuáles invariantes realmente valen la pena hacer obligatorios.

Este es el patrón FREI-PI (Requisitos Funcionales, Efectos, Interacciones, Invariantes del Protocolo): al final de cada función que afecta valor, vuelve a verificar los invariantes clave. Muchas de las explotaciones por CEI (Checks-Effects-Interactions) (como ataques de flash loans, liquidaciones con oráculos, o agotamiento de capacidad entre funciones) pueden capturarse con verificaciones de invariantes al final de la función.

Buenas pruebas

Las pruebas de fuzzing con estado (Stateful fuzzing) generan secuencias aleatorias de llamadas a partir de la superficie pública del protocolo, y verifican invariantes en cada paso. La mayoría de las vulnerabilidades en producción son transacciones múltiples, y el fuzzing con estado es casi la única forma confiable de detectar estos caminos antes de que los exploten.

Usa invariantes para afirmar que las propiedades se mantienen en todas las secuencias generadas por el fuzzing. Complementa con verificación formal, que puede demostrar que las propiedades se mantienen en todos los estados alcanzables. Tus invariantes de corona deben aceptar este enfoque.

Oráculos y dependencias

La complejidad es enemiga de la seguridad. Cada dependencia externa amplía la superficie de ataque. Cuando diseñes primitivas, da a los usuarios la opción de confiar en quién y en qué confiar. Si no puedes eliminar dependencias, diversifícalas para que ningún fallo único pueda destruir tu protocolo.

Amplía el alcance de auditoría para simular fallos en oráculos y dependencias, y aplica límites de tasa a los posibles desastres que puedan causar si fallan.

El reciente fallo de KelpDAO es un ejemplo: heredaron la configuración predeterminada de LayerZero requiredDVNCount=1, que estaba fuera del alcance de su auditoría. La infraestructura fuera de la cadena que fue comprometida fue la que no estaba auditada.

Ataques en superficie

La mayoría de los ataques en superficie en DeFi ya están listados. Revisa cada categoría, pregunta si aplica a tu protocolo, y aplica controles específicos para cada vector. Desarrolla habilidades de red team, y haz que tus IA busquen activamente vulnerabilidades en tu protocolo; esto ya es un requisito básico hoy en día.

Capacidades nativas de rescate

En gobernanza basada en votación, el poder inicialmente está concentrado en las firmas múltiples del equipo, y tarda en dispersarse. Aunque los tokens estén distribuidos ampliamente, la delegación suele concentrar autoridad en unas pocas wallets (a veces solo una). Cuando esas wallets se comprometen, el juego termina.

Implementa «wallets guardianes», con permisos estrictamente limitados: solo pueden pausar el protocolo, y en un umbral de >=4/7, pueden en casos extremos rotar los fondos dañados a wallets de reemplazo predefinidos. Los guardianes nunca pueden proponer gobernanza.

Así, tienes una capa de rescate que puede restaurar la estabilidad gobernable en todo momento, sin tener el poder de derrocar la gobernanza. La probabilidad de que >=4/7 guardianes fallen en el peor escenario (considerando la diversidad de poseedores) es muy baja, y una vez que la gobernanza esté madura y dispersa, esta capa puede eliminarse gradualmente.

Wallets y topología de claves

Las wallets con firma múltiple son un requisito básico, mínimo 4/7. Nadie controla todas las claves. Rota frecuentemente los signatarios, y hazlo de forma discreta.

Las claves nunca deben interactuar con dispositivos de uso diario. Si usas un hardware para firmar mientras navegas, envías correos o abres Slack, esa firma ya está comprometida.

Ten varias wallets con firmas múltiples, cada una con diferentes propósitos. Supón que al menos una firma múltiple completa será comprometida, y planifica desde allí. Nadie debe tener control suficiente para comprometer el protocolo, incluso en escenarios extremos (secuestros, torturas, etc.).

Considera las recompensas

Si tienes recursos, establecer una recompensa por vulnerabilidades alta en relación con el TVL del protocolo vale mucho la pena; incluso si eres un protocolo pequeño, la recompensa debe ser generosa (mínimo 7-8 cifras).

Si enfrentas actores estatales, quizás no negocien, pero aún puedes participar en programas de «white hat» y autorizar a hackers éticos a actuar en tu nombre para proteger fondos, pagando un porcentaje del bounty como comisión (que en realidad paga el depositante).

Encuentra buenos auditores

Antes pensaba que, con modelos de lenguaje grandes más inteligentes, el valor marginal de contratar auditores disminuiría. Sigo creyéndolo, pero mi perspectiva cambió.

Primero, los buenos auditores están en la vanguardia. Si haces algo novedoso, tu código y sus vulnerabilidades quizás no estén en sus datos de entrenamiento, y simplemente aumentar tokens no ha demostrado detectar vulnerabilidades nuevas. No quieres ser el primer ejemplo de vulnerabilidad única.

Segundo, un beneficio subestimado es que contratar auditores es usar su reputación como garantía. Si aprueban y tú eres hackeado, estarán muy motivados a ayudar. Relacionarte con profesionales en seguridad es una gran ventaja.

Practica seguridad operativa

Considera la seguridad operativa como un indicador de éxito. Realiza simulacros de phishing; contrata (confiables) red teams para intentar ataques de ingeniería social. Ten hardware y dispositivos de respaldo listos para reemplazar toda firma múltiple si es necesario. No esperes al día D para comprar estos recursos.

Medidas de mitigación

Tu ruta de salida es el límite de pérdidas

El tamaño máximo teórico de pérdida en cualquier ruta de salida que saque valor del protocolo es el límite superior de daño. En pocas palabras: una función de emisión sin límite por bloque es un cheque en blanco para cualquier vulnerabilidad de emisión infinita. Una función de redención sin límite semanal es un cheque en blanco para cualquier saldo dañado.

Piensa cuidadosamente en los valores claros de tus rutas de salida. Este número debe equilibrar el daño máximo que estás dispuesto a aceptar y la experiencia de usuario en escenarios extremos. Si algo sale mal, esto puede salvarte de la destrucción total.

Listas blancas (y negras)

La mayoría de los protocolos tienen listas de llamadas, transacciones o destinatarios permitidos, y listas de acciones prohibidas para los usuarios. Incluso si son implícitas, esas son fronteras de confianza que deben formalizarse.

Formalizarlas te permite crear mecanismos de doble paso, generando fricciones significativas. El atacante primero debe agregar a la lista blanca (o eliminar de la negra), y luego actuar. Tener ambas listas significa que, al introducir un vector nuevo, el atacante debe vulnerar dos procesos: que el mercado permita (listado / integración) y que la acción no sea prohibida (revisión de seguridad).

Recuperación

Monitoreo algorítmico

Sin monitoreo, el interruptor de corte no sirve de nada. Los monitores off-chain deben verificar invariantes continuamente, y si detectan problemas, activar alertas automáticas. La ruta final debe llegar a los guardianes en la firma múltiple, con suficiente contexto para decidir en minutos.

Recalibración y parada

Si te hackearon, primero debes detener la hemorragia, no tomar decisiones en cuenta regresiva. Para el protocolo, esto es el botón de emergencia (que también debe reflejarse en la interfaz): un botón que pausa todos los movimientos de valor en una sola transacción. Prepara un script auxiliar para pausar todos los componentes de forma atómica.

Solo la gobernanza puede levantar la pausa, por lo que el botón de emergencia no debe detener la gobernanza misma. Si los guardianes pueden pausar la gobernanza, un guardián comprometido puede bloquear permanentemente la recuperación.

Activa tu sala de crisis

Congela, detén y reúne a todos los confiables (grupo reducido, con acuerdos previos) en un canal de comunicación. Mantén la información en un nivel reducido para evitar filtraciones a atacantes, público o actores maliciosos.

Asigna roles específicos: un decisor; un operador que ejecute scripts de defensa y pausas; alguien que reconstruya vulnerabilidades y analice causas raíz; un comunicador con partes clave; y alguien que registre observaciones, eventos y decisiones en línea de tiempo.

Cuando todos conozcan sus roles y hayan practicado, podrás reaccionar según el plan, en lugar de estar desorientado en el peor momento.

Considera reacciones en cadena

Supón que tu atacante es muy hábil. La primera vulnerabilidad puede ser un señuelo o una semilla para ataques posteriores. El ataque puede ser para inducirte a hacer algo completamente erróneo, que active una vulnerabilidad real.

La pausa debe ser completamente controlada, y debe congelar toda la red del protocolo: no quieres que te induzcan a pausar un componente y abrir otro. Cuando encuentres la causa raíz y el vector, explora superficies expuestas adyacentes y reacciones en cadena, y corrige todo de una vez.

Rotación de sucesores preacordados

Solo si conoces a tus sucesores con anticipación, la rotación será segura. Me gusta la idea de un registro preacordado de sucesores: dificulta que atacantes conviertan guardianes o wallets de gobernanza sanos en comprometidos. Es coherente con la idea de listas blancas/negras en las medidas de rescate.

Registra una dirección sucesora para cada rol importante. La única operación de rotación en emergencias es «reemplazar al rol X por su sucesor». Esto también te permite evaluar a los sucesores en tiempos de paz: con calma, haciendo due diligence y reuniéndote con quienes hacen la solicitud.

Prueba con cuidado antes de actualizar

Una vez que determines la causa raíz y el alcance, debes desplegar la actualización. Este puede ser el código más peligroso que vayas a implementar: escrito bajo presión, dirigido a atacantes que ya saben y han encontrado vulnerabilidades en tu protocolo.

No publiques sin suficiente prueba. Si no hay tiempo para auditoría, usa relaciones con white hats, o programa una competencia de 48 horas antes del despliegue para obtener una revisión adversarial fresca.

Restauración

Acción rápida

Los fondos robados tienen una vida media; una vez que la vulnerabilidad se explota, entran rápidamente en canales de lavado. Prepara con anticipación proveedores de análisis on-chain como Chainalysis, para marcar en tiempo real las direcciones de los atacantes, y notifica a los exchanges para rastrear y bloquear.

Prepara una lista de entidades confiables: departamentos de cumplimiento en exchanges, administradores de puentes cross-chain, custodios y otros terceros con permisos para congelar mensajes cross-chain o depósitos en tránsito.

Negociación

Sí, duele, pero aún debes intentar dialogar con los atacantes. Muchas cosas en la vida se resuelven por negociación. Ofrece recompensas blancas con plazo, y declara públicamente que si devuelven todo antes del plazo, no tomarás acciones legales.

Si enfrentas actores estatales, quizás no negocien, pero aún puedes participar en programas de «white hat» y autorizar a hackers éticos a actuar en tu nombre para proteger fondos, pagando un porcentaje del bounty.

Encuentra buenos auditores

Antes pensaba que, con modelos de lenguaje grandes, el valor marginal de contratar auditores disminuiría. Sigo creyéndolo, pero mi perspectiva cambió.

Primero, los buenos auditores están en la vanguardia. Si haces algo innovador, tu código y vulnerabilidades quizás no estén en sus datos de entrenamiento, y solo aumentar tokens no garantiza detectar vulnerabilidades nuevas. No quieres ser el primer ejemplo de vulnerabilidad única.

Segundo, contratar auditores es usar su reputación como garantía. Si aprueban y tú eres hackeado, estarán muy motivados a ayudar. Relacionarte con profesionales en seguridad es una gran ventaja.

Practica seguridad operativa

Considera la seguridad operativa como un indicador de éxito. Realiza simulacros de phishing; contrata (confiables) red teams para intentar ataques de ingeniería social. Ten hardware y dispositivos de respaldo listos para reemplazar toda firma múltiple si es necesario. No esperes al día D para comprar estos recursos.

Medidas de mitigación

Tu ruta de salida es el límite de pérdidas

El tamaño máximo teórico de pérdida en cualquier ruta de salida que saque valor del protocolo es el límite superior de daño. En pocas palabras: una función de emisión sin límite por bloque es un cheque en blanco para cualquier vulnerabilidad de emisión infinita. Una función de redención sin límite semanal es un cheque en blanco para cualquier saldo dañado.

Piensa cuidadosamente en los valores claros de tus rutas de salida. Este número debe equilibrar el daño máximo que estás dispuesto a aceptar y la experiencia de usuario en escenarios extremos. Si algo sale mal, esto puede salvarte de la destrucción total.

Listas blancas (y negras)

La mayoría de los protocolos tienen listas de llamadas, transacciones o destinatarios permitidos, y listas de acciones prohibidas para los usuarios. Incluso si son implícitas, esas son fronteras de confianza que deben formalizarse.

Formalizarlas te permite crear mecanismos de doble paso, generando fricciones significativas. El atacante primero debe agregar a la lista blanca (o eliminar de la negra), y luego actuar. Tener ambas listas significa que, al introducir un vector nuevo, el atacante debe vulnerar dos procesos: que el mercado permita (listado / integración) y que la acción no sea prohibida (revisión de seguridad).

Recuperación

Monitoreo algorítmico

Sin monitoreo, el interruptor de corte no sirve de nada. Los monitores off-chain deben verificar invariantes continuamente, y si detectan problemas, activar alertas automáticas. La ruta final debe llegar a los guardianes en la firma múltiple, con suficiente contexto para decidir en minutos.

Recalibración y parada

Si te hackearon, primero debes detener la hemorragia, no tomar decisiones en cuenta regresiva. Para el protocolo, esto es el botón de emergencia (que también debe reflejarse en la interfaz): un botón que pausa todos los movimientos de valor en una sola transacción. Prepara un script auxiliar para pausar todos los componentes de forma atómica.

Solo la gobernanza puede levantar la pausa, por lo que el botón de emergencia no debe detener la gobernanza misma. Si los guardianes pueden pausar la gobernanza, un guardián comprometido puede bloquear permanentemente la recuperación.

Activa tu sala de crisis

Congela, detén y reúne a todos los confiables (grupo reducido, con acuerdos previos) en un canal de comunicación. Mantén la información en un nivel reducido para evitar filtraciones a atacantes, público o actores maliciosos.

Asigna roles específicos: un decisor; un operador que ejecute scripts de defensa y pausas; alguien que reconstruya vulnerabilidades y analice causas raíz; un comunicador con partes clave; y alguien que registre observaciones, eventos y decisiones en línea de tiempo.

Cuando todos conozcan sus roles y hayan practicado, podrás reaccionar según el plan, en lugar de estar desorientado en el peor momento.

Considera reacciones en cadena

Supón que tu atacante es muy hábil. La primera vulnerabilidad puede ser un señuelo o una semilla para ataques posteriores. El ataque puede ser para inducirte a hacer algo completamente erróneo, que active una vulnerabilidad real.

La pausa debe ser completamente controlada, y debe congelar toda la red del protocolo: no quieres que te induzcan a pausar un componente y abrir otro. Cuando encuentres la causa raíz y el vector, explora superficies expuestas adyacentes y reacciones en cadena, y corrige todo de una vez.

Rotación de sucesores preacordados

Solo si conoces a tus sucesores con anticipación, la rotación será segura. Me gusta la idea de un registro preacordado de sucesores: dificulta que atacantes conviertan guardianes o wallets de gobernanza sanos en comprometidos. Es coherente con la idea de listas blancas/negras en las medidas de rescate.

Registra una dirección sucesora para cada rol importante. La única operación de rotación en emergencias es «reemplazar al rol X por su sucesor». Esto también te permite evaluar a los sucesores en tiempos de paz: con calma, haciendo due diligence y reuniéndote con quienes hacen la solicitud.

Prueba con cuidado antes de actualizar

Una vez que determines la causa raíz y el alcance, debes desplegar la actualización. Este puede ser el código más peligroso que vayas a implementar: escrito bajo presión, dirigido a atacantes que ya saben y han encontrado vulnerabilidades en tu protocolo.

No publiques sin suficiente prueba. Si no hay tiempo para auditoría, usa relaciones con white hats, o programa una competencia de 48 horas antes del despliegue para obtener una revisión adversarial fresca.

Restauración

Acción rápida

Los fondos robados tienen una vida media; una vez que la vulnerabilidad se explota, entran rápidamente en canales de lavado. Prepara con anticipación proveedores de análisis on-chain como Chainalysis, para marcar en tiempo real las direcciones de los atacantes, y notifica a los exchanges para rastrear y bloquear.

Prepara una lista de entidades confiables: departamentos de cumplimiento en exchanges, administradores de puentes cross-chain, custodios y otros terceros con permisos para congelar mensajes cross-chain o depósitos en tránsito.

Negociación

Sí, duele, pero aún debes intentar dialogar con los atacantes. Muchas cosas en la vida se resuelven por negociación. Ofrece recompensas blancas con plazo, y declara públicamente que si devuelven todo antes del plazo, no tomarás acciones legales.

Si enfrentas actores estatales, quizás no negocien, pero aún puedes participar en programas de «white hat» y autorizar a hackers éticos a actuar en tu nombre para proteger fondos, pagando un porcentaje del bounty.

Encuentra buenos auditores

Antes pensaba que, con modelos de lenguaje grandes, el valor marginal de contratar auditores disminuiría. Sigo creyéndolo, pero mi perspectiva cambió.

Primero, los buenos auditores están en la vanguardia. Si haces algo innovador, tu código y vulnerabilidades quizás no estén en sus datos de entrenamiento, y solo aumentar tokens no garantiza detectar vulnerabilidades nuevas. No quieres ser el primer ejemplo de vulnerabilidad única.

Segundo, contratar auditores es usar su reputación como garantía. Si aprueban y tú eres hackeado, estarán muy motivados a ayudar. Relacionarte con profesionales en seguridad es una gran ventaja.

Practica seguridad operativa

Considera la seguridad operativa como un indicador de éxito. Realiza simulacros de phishing; contrata (confiables) red teams para intentar ataques de ingeniería social. Ten hardware y dispositivos de respaldo listos para reemplazar toda firma múltiple si es necesario. No esperes al día D para comprar estos recursos.

Medidas de mitigación

Tu ruta de salida es el límite de pérdidas

El tamaño máximo teórico de pérdida en cualquier ruta de salida que saque valor del protocolo es el límite superior de daño. En pocas palabras: una función de emisión sin límite por bloque es un cheque en blanco para cualquier vulnerabilidad de emisión infinita. Una función de redención sin límite semanal es un cheque en blanco para cualquier saldo dañado.

Piensa cuidadosamente en los valores claros de tus rutas de salida. Este número debe equilibrar el daño máximo que estás dispuesto a aceptar y la experiencia de usuario en escenarios extremos. Si algo sale mal, esto puede salvarte de la destrucción total.

Listas blancas (y negras)

La mayoría de los protocolos tienen listas de llamadas, transacciones o destinatarios permitidos, y listas de acciones prohibidas para los usuarios. Incluso si son implícitas, esas son fronteras de confianza que deben formalizarse.

Formalizarlas te permite crear mecanismos de doble paso, generando fricciones significativas. El atacante primero debe agregar a la lista blanca (o eliminar de la negra), y luego actuar. Tener ambas listas significa que, al introducir un vector nuevo, el atacante debe vulnerar dos procesos: que el mercado permita (listado / integración) y que la acción no sea prohibida (revisión de seguridad).

Recuperación

Monitoreo algorítmico

Sin monitoreo, el interruptor de corte no sirve de nada. Los monitores off-chain deben verificar invariantes continuamente, y si detectan problemas, activar alertas automáticas. La ruta final debe llegar a los guardianes en la firma múltiple, con suficiente contexto para decidir en minutos.

Recalibración y parada

Si te hackearon, primero debes detener la hemorragia, no tomar decisiones en cuenta regresiva. Para el protocolo, esto es el botón de emergencia (que también debe reflejarse en la interfaz): un botón que pausa todos los movimientos de valor en una sola transacción. Prepara un script auxiliar para pausar todos los componentes de forma atómica.

Solo la gobernanza puede levantar la pausa, por lo que el botón de emergencia no debe detener la gobernanza misma. Si los guardianes pueden pausar la gobernanza, un guardián comprometido puede bloquear permanentemente la recuperación.

Activa tu sala de crisis

Congela, detén y reúne a todos los confiables (grupo reducido, con acuerdos previos) en un canal de comunicación. Mantén la información en un nivel reducido para evitar filtraciones a atacantes, público o actores maliciosos.

Asigna roles específicos: un decisor; un operador que ejecute scripts de defensa y pausas; alguien que reconstruya vulnerabilidades y analice causas raíz; un comunicador con partes clave; y alguien que registre observaciones, eventos y decisiones en línea de tiempo.

Cuando todos conozcan sus roles y hayan practicado, podrás reaccionar según el plan, en lugar de estar desorientado en el peor momento.

Considera reacciones en cadena

Supón que tu atacante es muy hábil. La primera vulnerabilidad puede ser un señuelo o una semilla para ataques posteriores. El ataque puede ser para inducirte a hacer algo completamente erróneo, que active una vulnerabilidad real.

La pausa debe ser completamente controlada, y debe congelar toda la red del protocolo: no quieres que te induzcan a pausar un componente y abrir otro. Cuando encuentres la causa raíz y el vector, explora superficies expuestas adyacentes y reacciones en cadena, y corrige todo de una vez.

Rotación de sucesores preacordados

Solo si conoces a tus sucesores con anticipación, la rotación será segura. Me gusta la idea de un registro preacordado de sucesores: dificulta que atacantes conviertan guardianes o wallets de gobernanza sanos en comprometidos. Es coherente con la idea de listas blancas/negras en las medidas de rescate.

Registra una dirección sucesora para cada rol importante. La única operación de rotación en emergencias es «reemplazar al rol X por su sucesor». Esto también te permite evaluar a los sucesores en tiempos de paz: con calma, haciendo due diligence y reuniéndote con quienes hacen la solicitud.

Prueba con cuidado antes de actualizar

Una vez que determines la causa raíz y el alcance, debes desplegar la actualización. Este puede ser el código más peligroso que vayas a implementar: escrito bajo presión, dirigido a atacantes que ya saben y han encontrado vulnerabilidades en tu protocolo.

No publiques sin suficiente prueba. Si no hay tiempo para auditoría, usa relaciones con white hats, o programa una competencia de 48 horas antes del despliegue para obtener una revisión adversarial fresca.

Restauración

Acción rápida

Los fondos robados tienen una vida media; una vez que la vulnerabilidad se explota, entran rápidamente en canales de lavado. Prepara con anticipación proveedores de análisis on-chain como Chainalysis, para marcar en tiempo real las direcciones de los atacantes, y notifica a los exchanges para rastrear y bloquear.

Prepara una lista de entidades confiables: departamentos de cumplimiento en exchanges, administradores de puentes cross-chain, custodios y otros terceros con permisos para congelar mensajes cross-chain o depósitos en tránsito.

Negociación

Sí, duele, pero aún debes intentar dialogar con los atacantes. Muchas cosas en la vida se resuelven por negociación. Ofrece recompensas blancas con plazo, y declara públicamente que si devuelven todo antes del plazo, no tomarás acciones legales.

Si enfrentas actores estatales, quizás no negocien, pero aún puedes participar en programas de «white hat» y autorizar a hackers éticos a actuar en tu nombre para proteger fondos, pagando un porcentaje del bounty.

Encuentra buenos auditores

Antes pensaba que, con modelos de lenguaje grandes, el valor marginal de contratar auditores disminuiría. Sigo creyéndolo, pero mi perspectiva cambió.

Primero, los buenos auditores están en la vanguardia. Si haces algo innovador, tu código y vulnerabilidades quizás no estén en sus datos de entrenamiento, y solo aumentar tokens no garantiza detectar vulnerabilidades nuevas. No quieres ser el primer ejemplo de vulnerabilidad única.

Segundo, contratar auditores es usar su reputación como garantía. Si aprueban y tú eres hackeado, estarán muy motivados a ayudar. Relacionarte con profesionales en seguridad es una gran ventaja.

Practica seguridad operativa

Considera la seguridad operativa como un indicador de éxito. Realiza simulacros de phishing; contrata (confiables) red teams para intentar ataques de ingeniería social. Ten hardware y dispositivos de respaldo listos para reemplazar toda firma múltiple si es necesario. No esperes al día D para comprar estos recursos.

Medidas de mitigación

Tu ruta de salida es el límite de pérdidas

El tamaño máximo teórico de pérdida en cualquier ruta de salida que saque valor del protocolo es el límite superior de daño. En pocas palabras: una función de emisión sin límite por bloque es un cheque en blanco para cualquier vulnerabilidad de emisión infinita. Una función de redención sin límite semanal es un cheque en blanco para cualquier saldo dañado.

Piensa cuidadosamente en los valores claros de tus rutas de salida. Este número debe equilibrar el daño máximo que estás dispuesto a aceptar y la experiencia de usuario en escenarios extremos. Si algo sale mal, esto puede salvarte de la destrucción total.

Listas blancas (y negras)

La mayoría de los protocolos tienen listas de llamadas, transacciones o destinatarios permitidos, y listas de acciones prohibidas para los usuarios. Incluso si son implícitas, esas son fronteras de confianza que deben formalizarse.

Formalizarlas te permite crear mecanismos de doble paso, generando fricciones significativas. El atacante primero debe agregar a la lista blanca (o eliminar de la negra), y luego actuar. Tener ambas listas significa que, al introducir un vector nuevo, el atacante debe vulnerar dos procesos: que el mercado permita (listado / integración) y que la acción no sea prohibida (revisión de seguridad).

Recuperación

Monitoreo algorítmico

Sin monitoreo, el interruptor de corte no sirve de nada. Los monitores off-chain deben verificar invariantes continuamente, y si detectan problemas, activar alertas automáticas. La ruta final debe llegar a los guardianes en la firma múltiple, con suficiente contexto para decidir en minutos.

Recalibración y parada

Si te hackearon, primero debes detener la hemorragia, no tomar decisiones en cuenta regresiva. Para el protocolo, esto es el botón de emergencia (que también debe reflejarse en la interfaz): un botón que pausa todos los movimientos de valor en una sola transacción. Prepara un script auxiliar para pausar todos los componentes de forma atómica.

Solo la gobernanza puede levantar la pausa, por lo que el botón de emergencia no debe detener la gobernanza misma. Si los guardianes pueden pausar la gobernanza, un guardián comprometido puede bloquear permanentemente la recuperación.

Activa tu sala de crisis

Congela, detén y reúne a todos los confiables (grupo reducido, con acuerdos previos) en un canal de comunicación. Mantén la información en un nivel reducido para evitar filtraciones a atacantes, público o actores maliciosos.

Asigna roles específicos: un decisor; un operador que ejecute scripts de defensa y pausas; alguien que reconstruya vulnerabilidades y analice causas raíz; un comunicador con partes clave; y alguien que registre observaciones, eventos y decisiones en línea de tiempo.

Cuando todos conozcan sus roles y hayan practicado, podrás reaccionar según el plan, en lugar de estar desorientado en el peor momento.

Considera reacciones en cadena

Supón que tu atacante es muy hábil. La primera vulnerabilidad puede ser un señuelo o una semilla para ataques posteriores. El ataque puede ser para inducirte a hacer algo completamente erróneo, que active una vulnerabilidad real.

La pausa debe ser completamente controlada, y debe congelar toda la red del protocolo: no quieres que te induzcan a pausar un componente y abrir otro. Cuando encuentres la causa raíz y el vector, explora superficies expuestas adyacentes y reacciones en cadena, y corrige todo de una vez.

Rotación de sucesores preacordados

Solo si conoces a tus sucesores con anticipación, la rotación será segura. Me gusta la idea de un registro preacordado de sucesores: dificulta que atacantes conviertan guardianes o wallets de gobernanza sanos en comprometidos. Es coherente con la idea de listas blancas/negras en las medidas de rescate.

Registra una dirección sucesora para cada rol importante. La única operación de rotación en emergencias es «reemplazar al rol X por su sucesor». Esto también te permite evaluar a los sucesores en tiempos de paz: con calma, haciendo due diligence y reuniéndote con quienes hacen la solicitud.

Prueba con cuidado antes de actualizar

Una vez que determines la causa raíz y el alcance, debes desplegar la actualización. Este puede ser el código más peligroso que vayas a implementar: escrito bajo presión, dirigido a atacantes que ya saben y han encontrado vulnerabilidades en tu protocolo.

No publiques sin suficiente prueba. Si no hay tiempo para auditoría, usa relaciones con white hats, o programa una competencia de 48 horas antes del despliegue para obtener una revisión adversarial fresca.

Restauración

Acción rápida

Los fondos robados tienen una vida media; una vez que la vulnerabilidad se explota, entran rápidamente en canales de lavado. Prepara con anticipación proveedores de análisis on-chain como Chainalysis, para marcar en tiempo real las direcciones de los atacantes, y notifica a los exchanges para rastrear y bloquear.

Prepara una lista de entidades confiables: departamentos de cumplimiento en exchanges, administradores de puentes cross-chain, custodios y otros terceros con permisos para congelar mensajes cross-chain o depósitos en tránsito.

Negociación

Sí, duele, pero aún debes intentar dialogar con los atacantes. Muchas cosas en la vida se resuelven por negociación. Ofrece recompensas blancas con plazo, y declara públicamente que si devuelven todo antes del plazo, no tomarás acciones legales.

Si enfrentas actores estatales, quizás no negocien, pero aún puedes participar en programas de «white hat» y autorizar a hackers éticos a actuar en tu nombre para proteger fondos, pagando un porcentaje del bounty.

Encuentra buenos auditores

Antes pensaba que, con modelos de lenguaje grandes, el valor marginal de contratar auditores disminuiría. Sigo creyéndolo, pero mi perspectiva cambió.

Primero, los buenos auditores están en la vanguardia. Si haces algo innovador, tu código y vulnerabilidades quizás no estén en sus datos de entrenamiento, y solo aumentar tokens no garantiza detectar vulnerabilidades nuevas. No quieres ser el primer ejemplo de vulnerabilidad única.

Segundo, contratar auditores es usar su reputación como garantía. Si aprueban y tú eres hackeado, estarán muy motivados a ayudar. Relacionarte con profesionales en seguridad es una gran ventaja.

Practica seguridad operativa

Considera la seguridad operativa como un indicador de éxito. Realiza simulacros de phishing; contrata (confiables) red teams para intentar ataques de ingeniería social. Ten hardware y dispositivos de respaldo listos para reemplazar toda firma múltiple si es necesario. No esperes al día D para comprar estos recursos.

Medidas de mitigación

Tu ruta de salida es el límite de pérdidas

El tamaño máximo teórico de pérdida en cualquier ruta de salida que saque valor del protocolo es el límite superior de daño. En pocas palabras: una función de emisión sin límite por bloque es un cheque en blanco para cualquier vulnerabilidad de emisión infinita. Una función de redención sin límite semanal es un cheque en blanco para cualquier