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

Título original: Cómo dejar de perder dinero por hacks en DeFi
Autor original: sysls, openforage
Traducción original: AididiaoJP, Foresight News

Autor original:律动BlockBeats

Fuente original:

Reproducción: 火星财经

Introducción

Al conocer numerosos incidentes de hackeos en protocolos DeFi, me ha generado temor hacia 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 finanzas 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

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

Mi hipótesis principal es: la IA ha reducido drásticamente el costo de encontrar vulnerabilidades y ha ampliado enormemente el área de ataque. A los humanos les lleva varias semanas 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 en niveles

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 aplica estrictamente, puede minimizar la probabilidad de explotación.

· Mitigación: en caso de fallar la prevención, limita la magnitud del daño.

· Pausa: nadie puede tomar decisiones óptimas bajo presión extrema. Una vez detectado un ataque, se activa inmediatamente la palanca de apagado general. Congelar puede detener pérdidas adicionales y ganar tiempo para pensar…

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

· Restablecimiento: recupera lo que perdiste. Planea con anticipación contactos con instituciones 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 la interfaz para ver si alcanzan el backend. Los atacantes hacen esto. Lo que puedas detectar con escaneos defensivos, ellos ya 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 suficiente tiempo para intervenir y congelar en caso de anomalías.

Antes, se oponía a los bloqueos temporales y procesos en múltiples pasos por generar fricción para el equipo del protocolo. Ahora, no te preocupes demasiado: la IA puede gestionar fácilmente estos pasos 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 nivel del código; forzar múltiples invariantes en cada función puede volverse inmanejable.

Balance de poder

Muchas vulnerabilidades provienen de wallets comprometidos. Necesitas una configuración que, incluso si una firma múltiple se ve comprometida, pueda rápidamente limitar el daño 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 poder derrocar 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í, las limitaciones de daño, los límites 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 realiza simulacros con tu equipo, para no estar desorientado cuando ocurra el impacto. 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 detalles 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 te puedan hackear. El punto de máxima comodidad suele ser el punto más peligroso.

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 cumplir.

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

Pruebas sólidas

Las pruebas de fuzzing con estado (Stateful fuzzing) generan secuencias de llamadas aleatorias en toda la superficie pública del protocolo, y en cada paso verifican los invariantes. La mayoría de 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 atacantes lo hagan.

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 clave 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, deja en manos del usuario decidir en quién confiar y en qué confiar. Si no puedes eliminar la dependencia, diversifícala, para que ningún fallo único pueda destruir tu protocolo.

Amplía el alcance de auditoría para incluir simulaciones de 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 en su alcance de auditoría.

Ataques en superficie

La mayoría de las superficies de ataque en DeFi ya han sido listadas. Revisa cada categoría, pregunta si aplica a tu protocolo, y luego implementa 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 estándar en la actualidad.

Tener capacidades nativas de rescate

En gobernanza basada en votación, el poder inicialmente está concentrado en los multisigs 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 estas wallets son comprometidas, el juego termina.

Implementa «wallets guardianes», con permisos estrictamente limitados: solo pueden pausar el protocolo, y en casos extremos, con un umbral de >=4/7, pueden reemplazar las delegaciones dañadas por wallets predefinidos. Los guardianes nunca pueden proponer gobernanza.

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

Wallets y topología de claves

Los multisigs son imprescindibles, 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 múltiples multisigs, cada uno con diferentes propósitos. Supón que al menos uno será comprometido, y planifica desde allí. Nadie debe tener control suficiente para derrocar 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; incluso si eres un protocolo pequeño, la recompensa debe ser generosa (por ejemplo, en 7-8 cifras mínimas).

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 de la recompensa (que en realidad lo 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 ha cambiado.

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 aumentar tokens no ha demostrado ser efectivo para 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 la multisig si es necesario. No esperes a la última hora 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 posible si esa ruta es explotada. En resumen: 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 de activos 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 las necesidades extremas de UX de los usuarios. Si algo sale mal, esto te salvará de la destrucción total.

Listas blancas (y negras)

La mayoría de los protocolos tienen listas de direcciones que pueden llamar, hacer transacciones o recibir, y listas de usuarios que no pueden hacer ciertas acciones. Incluso si son implícitas, estas son límites de confianza y deben formalizarse.

Formalizarlas te permite crear mecanismos de doble paso en los cambios, generando fricción significativa. Los atacantes primero deben agregar a la lista blanca (o eliminar de la negra), y luego actuar. Tener ambas listas significa que, al introducir un vector nuevo, deben 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, la palanca de apagado no sirve de nada. Los monitores off-chain deben verificar continuamente los invariantes, y si detectan problemas, activar alertas automatizadas. La ruta final debe llegar a los guardianes en multisig, con suficiente contexto para decidir en minutos.

Recalibración y pausa

Si te hackearon, primero debes detener la hemorragia, no tomar decisiones en cuenta regresiva. Para el protocolo, esto es la palanca de apagado (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 posibles de forma atómica.

Solo la gobernanza puede levantar la pausa, por lo que la palanca no puede pausar el contrato de gobernanza en sí. Si los guardianes pueden pausar el contrato de gobernanza, un guardián comprometido puede bloquear permanentemente la recuperación.

Inicia tu sala de crisis

Congela, detén la hemorragia, y reúne a todos los confiables (pequeño círculo, con acuerdos previos) en un canal de comunicación. Mantén la información limitada para evitar filtraciones a atacantes, público o actores maliciosos.

Asigna roles específicos: uno que tome decisiones; otro que ejecute defensas y pausas; uno que reconstruya vulnerabilidades y analice causas raíz; uno que comunique con partes clave; y uno 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 sembrar semillas para ataques posteriores. El ataque puede ser para inducirte a hacer algo totalmente erróneo, que active una vulnerabilidad real.

La pausa debe ser completamente controlada, y debe ser una congelación total 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 con sucesores predefinidos, la rotación es segura. Me gusta la idea de un registro de sucesores preacordados: dificulta que atacantes cambien guardianes o wallets de gobernanza sanos por comprometidos. Es coherente con la idea de listas blancas/negras en las medidas de mitigación.

Registra un sucesor para cada rol importante. La única operación de rotación en emergencias es «reemplazar al rol X por su sucesor». Esto también permite evaluar a los sucesores en tiempos de paz: hacer due diligence, reunirse con quienes hacen solicitudes, etc.

Prueba con cuidado antes de actualizar

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

No publiques sin suficiente prueba. Si no hay tiempo para auditoría, usa relaciones con white hats, o realiza 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 en rutas de lavado rápidamente. Prepara con anticipación proveedores de análisis on-chain como Chainalysis, para marcar en tiempo real las direcciones de los atacantes, y notificar plataformas de intercambio cuando hagan saltos entre cadenas.

Prepara una lista de terceros con permisos para congelar fondos, incluyendo exchanges, administradores de puentes cross-chain, custodios y otros que puedan detener 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 con negociación. Ofrece recompensas blancas con límite de tiempo, y declara públicamente que, si devuelven todo antes del plazo, no se tomarán 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 de la recompensa (que en realidad paga el depositante).

Conclusión

Los hackeos no cesarán, y a medida que la IA sea más inteligente, aumentarán en número. Solo hacer que los defensores «se vuelvan más agudos» no basta. Necesitamos usar las mismas herramientas que los atacantes, realizar red team en nuestros protocolos, monitorear continuamente y poner límites estrictos al daño, para poder sobrevivir en el peor escenario.