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 generado temor hacia los «actores estatales». Son expertos en tecnología, con recursos abundantes, y juegan un juego de 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 desprecio y negligencia 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 aumentando en frecuencia. 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 ampliado enormemente la superficie de ataque. La gente necesita varias semanas para revisar la configuración de cien protocolos en busca de errores; las últimas modelos básicos pueden hacerlo en solo 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».

Pensando 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 dar 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 la colaboración con socios que puedan congelar fondos, revertir transacciones y ayudar 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 habrán detectado con escaneos ofensivos.

Utiliza plataformas de IA como pashov, nemesis, así 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 detectar anomalías.

Antes, se oponía a los bloqueos temporales y procesos en múltiples pasos porque generaban fricción para el equipo del protocolo. Ahora, no te preocupes demasiado: la IA puede gestionar fácilmente estos frenos 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 firma múltiple 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, sin poder derrocar 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 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

Piensa en tu respuesta antes de que te hackeen. Codifica los procesos tanto como puedas y entrena a tu equipo para que practique, así no estarás 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 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 cumplir.

Este es el método FREI-PI (Requisitos Funcionales, Efectos, Interacciones, Invariantes del Protocolo): al final de cada función que toque valor, vuelve a verificar los invariantes que esa función prometió 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 requisito básico hoy en día.

Tener capacidades de rescate nativas

En gobernanza basada en votación, el poder inicialmente está en las multisigs del equipo, y tarda en dispersarse. Aunque los tokens estén distribuidos ampliamente, la delegación a menudo concentra 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 caso de >=4/7, pueden reemplazar rápidamente las delegaciones dañadas por wallets predefinidos en situaciones extremas. Los guardianes nunca pueden proponer gobernanza.

Así, tienes una capa de rescate que puede restaurar la estabilidad gobernable en todo momento, sin poder 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 multisigs son un requisito básico, mínimo 4/7. Nadie controla todas las 7 claves. Rota frecuentemente los signatarios, y hazlo discretamente.

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

Ten varias multisigs, 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

Ya mencioné que, con modelos de lenguaje cada vez más inteligentes, el valor marginal de contratar auditores disminuye. 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 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 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 en reserva hardware y dispositivos 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érdida

El tamaño máximo teórico de pérdida en cualquier ruta de salida que saque valor del protocolo es ese límite. En pocas palabras: una función de emisión sin límite por bloque es como tener 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 la experiencia de usuario en escenarios extremos. Si algo falla, 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 fricción significativa. Los atacantes primero deben 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 estar abierto (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 automatizadas. La ruta final debe llegar a los guardianes en multisig, con suficiente contexto para que puedan decidir en minutos.

Recalibrar y detener

Si te hackearon, primero debes detener la hemorragia, no tomar decisiones en medio del conteo regresivo. 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 posibles de forma atómica.

Solo la gobernanza puede levantar la pausa, por lo que el botón no debe detener el contrato de gobernanza en sí. Si la capa de guardianes puede pausar el contrato de 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 (pequeño grupo, con acuerdos previos) en un canal de comunicación. Mantén la información limitada para evitar filtraciones a atacantes, público o arbitrajistas maliciosos.

Haz roles de simulación para el equipo: 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 experimentado. La primera vulnerabilidad puede ser un señuelo o sembrar semillas 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 investigada, controlada y no explotable. La pausa 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 precomprometidos: 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 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 el alcance, debes lanzar la actualización. Puede ser el código más peligroso que vayas a desplegar: escrito bajo presión, dirigido a atacantes que ya saben mucho sobre 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.

Restablecer

Actúa con rapidez

El dinero robado tiene una vida media; una vez que la vulnerabilidad se explota, entra 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 notificar a los exchanges cuando saltan cadenas para rastrear.

Prepara una lista de terceros con autoridad para congelar fondos, gestionar puentes cross-chain, custodios y otros que puedan detener mensajes o depósitos en tránsito.

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 de la fecha límite, 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 un asesor legal.

Conclusión

Los hackeos no se detendrán, y con la 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 team en nuestros protocolos, monitorear continuamente, y poner límites estrictos a los daños para sobrevivir en el peor escenario.

Enlace original del artículo

Haz clic para conocer las oportunidades laborales en BlockBeats

Ú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