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 en hacks DeFi
Autor original: sysls, openforage
Traducción y compilación original: AididiaoJP, Foresight News

Introducción

Al conocer numerosos incidentes de hackeos en protocolos DeFi, me ha surgido un 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 tus protocolos 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 despreocupación 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

(Fuente de datos: https://defillama.com/hacks)

Los hackeos no son raros, pero claramente están en aumento. El primer trimestre de 2026 fue el trimestre con más hackeos 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 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 solo necesitan unas 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».

Pensar en superficie y jerarquías

(Fuente de datos: https://defillama.com/hacks)

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 añaden capas de defensa:

· Prevención: procesos que, si se aplican estrictamente, maximizan la reducción de la probabilidad de explotación.

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

· Pausa: nadie puede tomar decisiones óptimas bajo presión extrema. Una vez detectado un ataque, se activa inmediatamente la interrupció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.

· Restablecimiento: recuperar lo perdido. Planifica con anticipación contactos con socios 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 avanzados de IA 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 lo habrán detectado con escaneos ofensivos.

Emplea 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 pasos múltiples por crear fricciones para el equipo del protocolo. Ahora, no te preocupes demasiado: la IA puede gestionar fácilmente estas fricciones 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 puede volverse inmanejable.

Equilibrio de poder

Muchas vulnerabilidades provienen de wallets comprometidos. Necesitas una configuración que, incluso si una multisignature se ve comprometida, pueda 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, pero sin reemplazar o anular la gobernanza).

Siempre habrá problemas

Desde el principio, asume: 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 y los interruptores de bloqueo del protocolo serán tus mejores amigos. Limita el daño a un 5-10%, congela y planifica tu respuesta. Nadie puede tomar decisiones perfectas en medio del caos.

La mejor planificación es ahora

Piensa en tu plan de respuesta antes de que ocurra un hackeo. Codifica los procesos tanto como puedas y realiza simulacros con tu equipo, para no estar desorientado cuando llegue 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 haya evidencia de que no te hackearán no significa que no te hackearán. 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 método FREI-PI (Requisitos Funcionales, Efectos, Interacciones, Invariantes del Protocolo): al final de cada función que toque valores, vuelve a verificar los invariantes clave que esa función debe mantener. 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 ser detectadas con estas verificaciones al final de la función.

Buenas pruebas

Las pruebas de fuzzing con estado (Stateful fuzzing) generan secuencias aleatorias de llamadas a la interfaz del protocolo y verifican invariantes en cada paso. 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 exploten.

Usa invariantes en las pruebas para asegurar que las propiedades se mantengan en todas las secuencias generadas por el fuzzing. Combinado con verificación formal, puede demostrar que esas propiedades se mantienen en todos los estados alcanzables. Tus invariantes de la corona deben aceptar este método.

Oráculos y dependencias

La complejidad es la 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 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 de su alcance de auditoría. La infraestructura fuera de la cadena que fue comprometida fue la que causó la brecha final.

Ataques en superficie

La mayoría de los ataques en superficie en DeFi ya han sido 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 vulnerabilidades activamente; esto ya es un estándar en la actualidad.

Tener capacidades de rescate nativas

En gobernanza basada en votación, el poder inicialmente está en las multisignatures 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 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 puede restaurar la estabilidad gobernable en todo momento, sin tener el poder de derrocar la gobernanza. La probabilidad de que pierdas >=4/7 de los guardianes es muy baja (considerando la diversidad de poseedores), y una vez que la gobernanza esté madura y dispersa, esta capa puede eliminarse gradualmente.

Topología de wallets y claves

Las multisignatures son un requisito básico, mínimo 4/7. Nadie controla todas las 7 llaves. Rota frecuentemente los signatarios, y hazlo discretamente.

Las claves nunca deben interactuar con dispositivos de uso diario. Si usas un dispositivo de firma para navegar, enviar correos o abrir Slack, esa wallet ya está comprometida.

Ten varias multisignatures, cada una con diferentes propósitos. Supón que al menos una será comprometida, y planifica desde allí. Ninguna persona debe tener control suficiente para comprometer el protocolo, incluso en escenarios extremos (secuestros, torturas, etc.).

Considera 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 el rango de 7-8 cifras mínimas).

Si enfrentas actores estatales, quizás no negocien, pero aún puedes participar en programas de «white hat» que autoricen a hackers éticos a actuar en tu nombre para proteger fondos, y pagarles un porcentaje de la recompensa (que en realidad lo paga el depositante).

Encuentra buenos auditores

Antes decía que, con modelos de lenguaje cada vez más inteligentes, el valor marginal de contratar auditores disminuye. Sigo pensando eso, pero mi perspectiva ha cambiado.

Primero, los buenos auditores están en la vanguardia. Si haces algo novedoso, tu código y vulnerabilidades pueden no estar 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 firman y aprueban, y tú eres hackeado, estarán muy motivados a ayudar. Relacionarte con profesionales dedicados a 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 multisignature si es necesario. No esperes a que llegue el día D para comprar estos recursos.

Medidas de mitigación

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

El tamaño máximo teórico de pérdida en cualquier ruta de salida, en caso de explotación, es el límite superior del valor que puedas perder. En términos simples: una función de emisión sin límite por bloque es como dar un cheque en blanco para cualquier emisión infinita. Una función de redención sin límite semanal es como dar un cheque en blanco para cualquier saldo de activos.

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. Incluso si son implícitas, estas son límites de confianza que deben formalizarse.

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

Recuperar

Monitoreo algorítmico

Sin monitoreo, el botón de apagado no sirve de nada. Los monitores off-chain deben verificar continuamente los invariantes, y en caso de problema, activar alertas automáticas. La ruta final debe llegar a los guardianes en multisignature, con suficiente contexto para que puedan decidir en minutos.

Recalibrar y detener

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

Solo la gobernanza puede levantar la pausa, por lo que el botón no debe detener la gobernanza en sí. Si la capa de guardianes puede pausar la gobernanza, esa capa puede bloquear permanentemente la recuperación.

Inicia tu sala de crisis

Congela, detén la hemorragia, y reúne a todos los confiables (en un grupo pequeño, con acuerdos previos). Mantén la información en secreto para evitar que los atacantes, el público o los arbitrajistas maliciosos obtengan datos.

Haz simulacros de roles: un decisor; un operador que ejecute defensas y pausas; alguien que reconstruya vulnerabilidades y analice causas raíz; un comunicador con partes clave; y un registrador de observaciones, eventos y decisiones.

Cuando todos conozcan sus roles y hayan practicado, podrás reaccionar según el proceso, sin caos 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 estar diseñado para inducirte a hacer algo totalmente erróneo, que active una vulnerabilidad real.

La pausa debe ser completamente investigada, controlada y no explotable. Debe ser una congelación total del protocolo: no quieres que pausar un componente abra otra vulnerabilidad. Cuando encuentres la causa raíz y el vector, explora superficies expuestas relacionadas y repara todo en una sola 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 un atacante reemplace 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 emergencia es «reemplazar al rol X por su sucesor». Esto también permite evaluar a los sucesores en tiempos de paz: con calma, haciendo due diligence, y reuniéndose con quienes los proponen.

Prueba con cuidado antes de actualizar

Una vez que tienes claro el origen y alcance del problema, debes lanzar la actualización. Puede ser el código más peligroso que hayas desplegado: escrito bajo presión, dirigido a atacantes que ya saben cómo explotar tu protocolo.

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.

Restablecer

Actúa con rapidez

El dinero robado tiene una vida media; una vez que el exploit se concreta, entra rápidamente en procesos 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 notificar a los exchanges cuando saltan cadenas para rastrear.

Prepara una lista de terceros con autoridad para congelar fondos, gestionar puentes cross-chain, y administrar custodios, en coordinación con los departamentos de cumplimiento y seguridad.

Negocia

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 tomarás acciones legales.

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

Antes de hacerlo, consulta con asesores legales.

Conclusión

Los hackeos no van a parar, y con IA más inteligente, solo aumentarán. No basta con que los defensores «se vuelvan más agudos». Necesitamos usar las mismas herramientas que los atacantes, hacer red teaming en nuestros protocolos, monitorear continuamente, y poner límites estrictos a los daños, para poder sobrevivir en el peor escenario.

Enlace original del artículo

Haz clic para conocer cómo BlockBeats recluta en sus vacantes

Únete a la comunidad oficial de BlockBeats:

Grupo de Telegram: https://t.me/theblockbeats

Chat de Telegram: https://t.me/BlockBeats_App

Cuenta oficial de Twitter: https://twitter.com/BlockBeatsAsia