Frecuentes robos en DeFi, ¿cómo prevenir ataques de hackers en la era de la IA?

Escribir artículo: systs

OpenBuild introducción:

En abril de 2026, DeFi enfrentó su momento más oscuro, con un monto de robos en un solo mes que superó los 625 millones de dólares, alcanzando un récord histórico, solo Drift y KelpDAO absorbieron casi 580 millones de dólares en ataques. La explosión de la IA ha invertido por completo el panorama de ataque y defensa, originalmente se requerían semanas de trabajo manual para detectar vulnerabilidades en protocolos, ahora los grandes modelos pueden hacerlo en pocas horas, los costos de ataque se desploman y la superficie de ataque se expande, cada vez más protocolos se convierten en objetivos.

Aquellos atacantes profesionales con recursos abundantes y experiencia en estrategias a largo plazo, están atentos a cada grieta en los protocolos, mientras que los equipos comunes, dispersos y con defensas pasivas, solo pueden sobrevivir manteniendo una obsesión extrema, construyendo defensas de extremo a extremo con anticipación, controlando estrictamente las pérdidas y preparando planes de contingencia. A continuación, el contenido original, compilado y organizado por OpenBuild.

Después de desarrollar el proyecto @openforage y estudiar numerosos incidentes históricos de ataques a protocolos DeFi, he comenzado a tener precaución respecto a los atacantes con influencia a nivel nacional. Estos adversarios son hábiles, con recursos sólidos, expertos en estrategias a largo plazo; como villanos de élite, inspeccionan cada grieta en tu protocolo e infraestructura en busca de vulnerabilidades explotables. Los equipos de protocolos comunes, dispersos, que gestionan sus negocios y seguridad simultáneamente, no pueden defenderse completamente. No me considero un experto en seguridad, pero he liderado en ambientes de alto riesgo (con experiencia militar y gestión de fondos en grandes instituciones financieras), y tengo experiencia práctica en planes de riesgo y respuesta a emergencias. Creo firmemente: solo los obsesivos sobreviven. Ningún equipo comienza con una mentalidad de “seguridad superficial”, pero los ataques siguen siendo frecuentes. Debemos hacerlo mejor.

/ 01 Era de la IA: Todo es diferente

Los ataques de hackers siempre han existido, pero su frecuencia ha aumentado claramente en los últimos tiempos. En el primer trimestre de 2026, se alcanzó un récord en ataques a DeFi, y en el segundo trimestre, apenas comenzando, ya se espera superar esa cifra.

Mi opinión principal es: la IA ha reducido drásticamente los costos de escaneo y detección de vulnerabilidades, y ha ampliado enormemente la superficie de ataque. Revisar manualmente la configuración de cientos de protocolos lleva semanas; los modelos grandes actuales pueden hacerlo en pocas horas. Esto cambia radicalmente la lógica subyacente de defensa y respuesta ante incidentes en los protocolos. Los viejos protocolos, creados antes del auge de la IA y que aún usan métodos tradicionales de seguridad, enfrentan un riesgo enorme de ser atacados con precisión.

/ 02 Desde la superficie de ataque y la defensa en capas

En la práctica, las tres principales vías de ataque en DeFi son:

• Equipos operativos de protocolos
• Contratos inteligentes e infraestructura subyacente
• Límites de confianza de los usuarios (dominios, redes sociales, etc.)

Tras identificar la superficie de ataque, se construye un sistema de defensa en cinco capas:

Prevención previa: implementar procesos estandarizados, seguir estrictamente las reglas para reducir al máximo la probabilidad de ser vulnerados.

Mitigación de pérdidas: cuando la prevención falle, controlar rápidamente la magnitud de las pérdidas.

Apagado de emergencia: en situaciones de alta presión, nadie puede tomar decisiones óptimas. Al detectar un ataque, activar inmediatamente la función de cierre de emergencia, congelar activos para evitar mayores pérdidas y ganar tiempo para análisis y decisiones.

Recuperación del control: si un módulo malicioso o componente comprometido está fuera de control, desconectarlo o reemplazarlo directamente.

Restauración posterior: recuperar los activos robados. Con alianzas previas, congelar fondos, revertir transacciones y colaborar en investigaciones forenses.

/ 03 Principios clave

Estos principios guían la implementación de todo el sistema de defensa en capas.

Potenciar la defensa con IA de vanguardia

Utilizar modelos grandes para escanear código y configuraciones en busca de vulnerabilidades, realizar pruebas de penetración en la superficie de ataque: detectar vulnerabilidades front-end y verificar si se puede acceder al back-end. Los atacantes harán lo mismo; la defensa puede detectar vulnerabilidades mediante escaneo, y los atacantes también podrán encontrarlas. Se pueden usar herramientas como pashov, nemesis, y plataformas de seguridad IA como Cantina (Apex), Zellic (V12) para realizar una preauditoría rápida del código antes de auditorías formales.

El tiempo y los procesos son en sí mismos una defensa

Todas las operaciones con potencial riesgo deben seguir procesos en múltiples pasos y tener mecanismos de bloqueo temporal. Ante anomalías, reservar suficiente tiempo para intervención humana y congelar activos. Antes, la resistencia a los bloqueos temporales y permisos en múltiples pasos se justificaba por la complejidad y la eficiencia operativa; ahora, la IA puede automatizar estas acciones en segundo plano, haciendo que los protocolos que solo priorizan la simplicidad sean inútiles.

Diseño de invariantes

Los contratos inteligentes pueden definir invariantes centrales inquebrantables: si se violan, toda la lógica del protocolo se considera invalidada. En @openforage, el invariantes clave giran en torno a la solvencia: activos en la bóveda + activos desplegados ≥ créditos no pagados. Solo se deben definir unos pocos invariantes críticos; evitar codificar múltiples verificaciones en cada función, ya que esto hace el código difícil de mantener.

Balance de poderes

Muchas brechas provienen de la exposición de claves privadas o de la ruptura de firmas múltiples. La configuración de permisos debe permitir, incluso si una firma múltiple se compromete, detener rápidamente las pérdidas y poner el protocolo en un estado estable gobernado por decisiones. Los dos principales controles de poder son:

• Permisos de gobernanza: decisiones clave del protocolo
• Permisos de rescate de emergencia: restaurar el orden estable, sin usurpar ni reemplazar la gobernanza original

Prever que algo saldrá mal

Es fundamental aceptar que, por muy profesionales que sean los equipos, tarde o temprano serán atacados. Los contratos inteligentes o componentes pueden fallar, los equipos pueden ser víctimas de ingeniería social, y las actualizaciones pueden introducir vulnerabilidades desconocidas. Con esta mentalidad, las medidas de control de flujo, límites y paradas de emergencia son imprescindibles: limitar las pérdidas a un 5-10%, congelar fondos y planear respuestas con calma. En momentos críticos, evitar decisiones apresuradas.

Planificación anticipada

La mejor respuesta a un ataque es prevenirlo antes de que ocurra. Formalizar y ensayar los planes de emergencia, practicar con el equipo, para evitar confusión y errores en crisis. La era de la IA requiere herramientas y algoritmos que recopilen toda la información en tiempo real, generen resúmenes y detalles completos, y los compartan con los decisores clave.

Sobrevivir es la meta final

No se necesita perfección absoluta, sino garantizar la supervivencia. Ningún sistema es invulnerable desde su lanzamiento; solo mediante revisiones continuas, aprendizaje de errores y mejoras, puede construirse una arquitectura antifrágil. Que nunca haya sido hackeado no significa que sea seguro por naturaleza; los momentos de mayor tranquilidad suelen ser los más peligrosos.

/ 04 Sistema de prevención previa

Diseño de contratos inteligentes

Definir invariantes clave y codificarlos en la lógica de ejecución, seleccionando cuidadosamente las reglas que deben verificarse obligatoriamente. Recomiendo seguir el patrón FREI-PI (Función - Impacto - Interacción externa - Invariante del protocolo): todas las funciones que involucran activos deben verificar los invariantes críticos al finalizar. Muchas vulnerabilidades, como ataques de flash loans, liquidaciones maliciosas o pérdida de capacidad de pago entre funciones, pueden ser bloqueadas con verificaciones de invariantes al final de las funciones.

Mejorar el sistema de pruebas

Pruebas de estado con generación aleatoria de llamadas a todas las interfaces del protocolo, verificando invariantes en cada paso. La mayoría de ataques en cadena involucran múltiples transacciones; las pruebas de estado son la única forma confiable de detectar vulnerabilidades antes de que los atacantes las exploten. Escribir pruebas de invariantes que se mantengan en cualquier secuencia generada, y combinarlas con verificaciones formales que aseguren la validez en todos los estados alcanzables. Los invariantes críticos deben ser formalmente verificados.

Dependencias externas y oráculos

La complejidad es el enemigo principal de la seguridad. Cada capa adicional de dependencia externa amplía la superficie de ataque. Si desarrollas componentes básicos, deja la confianza en manos del usuario; si no puedes eliminar dependencias, implementa redundancia y descentralización para evitar fallos únicos que puedan colapsar todo. La auditoría debe cubrir escenarios de fallos en oráculos y dependencias externas, estableciendo límites y cuotas para limitar daños en caso de anomalías. El ataque a KelpDAO es un ejemplo: usaron la configuración predeterminada de LayerZero con requiredDVNCount=1, que no fue auditada, y esa infraestructura fuera del alcance de la auditoría fue la que fue comprometida.

Revisión exhaustiva de la superficie de ataque

Los vectores de ataque conocidos en DeFi están bien documentados. Revisar cada uno y evaluar su aplicabilidad en el propio protocolo, implementando controles correspondientes. Construir capacidades internas de red y azul, y forzar a los agentes IA a buscar vulnerabilidades activamente; esto ya es un estándar en la industria.

Permisos de rescate nativos

En modelos de gobernanza por votación, el poder inicialmente se concentra en el equipo con múltiples firmas, y luego se dispersa. Aunque los tokens se distribuyen ampliamente, los permisos de delegación suelen concentrarse en unas pocas wallets, y en casos extremos, en una sola dirección clave. Si esa wallet se compromete, el protocolo colapsa. Se recomienda desplegar wallets guardianes, con permisos estrictamente limitados: solo para pausar el protocolo; en casos extremos, requerir un umbral de 4/7 para rotar permisos a wallets predefinidos. Los guardianes no pueden iniciar ni aprobar propuestas de gobernanza.

De esta forma, el protocolo tiene una capa de rescate independiente: puede restaurar un estado estable gobernado, sin usurpar la gobernanza original. La probabilidad de que más del 57% de guardianes sean comprometidos simultáneamente es baja, dado que las direcciones de los poseedores están dispersas; cuando la gobernanza esté madura y descentralizada, esta capa de rescate puede eliminarse.

Estructura de wallets y claves

Las wallets multisig son estándar, con al menos 4/7 firmas, y nadie controla todas las claves. Rotar periódicamente las direcciones de los signatarios. Las claves de firma no deben usarse en dispositivos comunes: si un dispositivo se usa para navegar, enviar correos o acceder a software de oficina, se asume que está comprometido. Usar múltiples wallets multisig con funciones específicas. Prever al menos una wallet que pueda ser completamente comprometida, y diseñar planes en consecuencia. Ningún individuo, incluso bajo coacción o amenazas, debe tener la capacidad de comprometer el protocolo solo.

Planificación de recompensas por vulnerabilidades

Estoy de acuerdo con Nascent en que las recompensas por vulnerabilidades deben ser proporcionales al TVL del protocolo, con recompensas altas incluso en protocolos pequeños (de siete cifras en adelante). Frente a atacantes de nivel estatal, las negociaciones de recompensas suelen ser inútiles; pero se puede implementar un programa de “refugio seguro” para white hats: autorizar a hackers éticos a asegurar fondos robados y pagarles una comisión, asumiendo el costo en parte por los depositantes.

Selección de auditorías de calidad

Antes pensaba que, con el avance de los modelos grandes, la auditoría tradicional perdería valor marginal; ahora, creo que las mejores auditorías siguen siendo clave. Los principales auditores están a la vanguardia; si un protocolo usa diseños innovadores, su código y vulnerabilidades potenciales no están en los datos de entrenamiento del modelo, y la potencia de cálculo no garantiza detectar nuevas vulnerabilidades lógicas. Nadie quiere ser la primera víctima de nuevas técnicas de ataque.

Un aspecto a menudo pasado por alto: los auditores respaldan su reputación con informes. Si un protocolo auditado es hackeado, la auditoría puede ayudar a analizar y limitar daños. La colaboración a largo plazo con equipos de seguridad especializados es un activo valioso.

Seguridad operativa

Incluir la seguridad operativa en los indicadores clave de rendimiento. Realizar simulacros de phishing periódicos; contratar red teams externos confiables para pruebas de ingeniería social. Mantener hardware y wallets de respaldo listos para reemplazar toda la configuración multisig en caso de emergencia, evitando compras apresuradas en crisis.

/ 05 Mitigación de pérdidas

Límite máximo de pérdidas por salida de fondos

Cada canal de salida de activos debe tener un límite de cuota; el máximo daño posible por explotación de vulnerabilidades en ese canal. En términos simples: funciones de emisión sin límite en un bloque, equivalen a un cheque en blanco para emitir ilimitadamente; funciones de retiro sin límite semanal, equivalen a permitir alteraciones en el saldo de activos. Establecer límites estrictos en cada canal de salida, equilibrando la pérdida máxima aceptable y la experiencia del usuario. Cuando se rompen las defensas, estos límites evitan que el protocolo colapse por completo.

Listas blancas y negras

La mayoría de los protocolos tienen listas ocultas de interfaces, activos, direcciones autorizadas, y límites de acciones prohibidas. Aunque sean implícitas, deben formalizarse por escrito. Con listas blancas y negras claras, se pueden implementar mecanismos de doble autorización, dificultando ataques. Los atacantes deben primero modificar listas o eliminar restricciones, y luego ejecutar acciones maliciosas. Con doble capa, los nuevos vectores de ataque deben superar dos barreras: primero, la revisión de acceso (integración y despliegue), y luego, la evasión de las restricciones de seguridad (revisión de riesgos).

/ 06 Recuperación del control

Monitoreo automatizado de algoritmos

Contar con un sistema de monitoreo off-chain, que inspeccione en tiempo real los invariantes críticos, y en caso de anomalías, active alertas automáticas. Las alertas deben llegar a los responsables de la firma múltiple, con toda la información contextual, para decisiones en minutos.

Primero, detenerse, luego analizar

En caso de ataque, priorizar la contención, sin decisiones apresuradas. En el protocolo, activar la función de cierre de emergencia (mostrada en la interfaz): una sola transacción puede detener todos los movimientos de activos. Preparar scripts de “pausa total” que recorran automáticamente todos los módulos pausables y los detengan de forma atómica. Los permisos de gobernanza no pueden ser desactivados; si los guardianes pueden pausar contratos de gobernanza, y estos son comprometidos, el proceso de recuperación se bloqueará permanentemente.

Crear un centro de operaciones de emergencia

Tras congelar fondos y detener pérdidas, convocar a los responsables clave, establecer canales de comunicación exclusivos. Limitar la información a los necesarios, para evitar filtraciones a atacantes, medios o actores interesados. Ensayar roles y procedimientos:

• Responsable de decisiones: coordina y aprueba
• Ejecutores de operaciones: implementan scripts y pausas
• Analistas de ataques: reconstruyen la cadena de ataque y hallazgos
• Enlaces externos: coordinan con socios y plataformas
• Registradores: documentan todo el proceso y decisiones

Todos deben estar claros en sus roles y haber practicado, para actuar según el plan en la crisis.

Prever riesgos en cadena

Asumir que los atacantes son expertos: la primera vulnerabilidad puede ser un señuelo, o una preparación para ataques en cadena. La intrusión puede ser un señuelo para inducir errores, o una trampa para explotar vulnerabilidades profundas. La parada de emergencia debe ser evaluada cuidadosamente, asegurando que el protocolo esté completamente congelado, sin dejar puertas abiertas en módulos aislados. Tras identificar las causas y vectores, revisar las superficies relacionadas y los riesgos en cadena, y corregir todo en una sola operación.

Implementar mecanismos de rotación de roles

La rotación de permisos solo es segura si las direcciones de reemplazo están predefinidas. Recomiendo un registro de direcciones de sucesores: es difícil que un atacante reemplace secretamente guardianes o wallets de gobernanza con wallets maliciosos. La lógica es similar a las listas blancas y negras. Registrar previamente las direcciones de sucesores para cada rol. Los permisos de emergencia solo deben permitir reemplazar a un rol por su sucesor predefinido. Durante la operación normal, seleccionar cuidadosamente a los sucesores, sin decisiones apresuradas en crisis.

Pruebas rigurosas antes de actualizar

Tras identificar causas y alcance, se lanza una actualización del contrato. Esto suele ser la operación más arriesgada: en la presión, se puede cometer errores, y los atacantes ya conocen la lógica del protocolo y las vulnerabilidades. No omitir pruebas, y si no hay tiempo para auditorías formales, usar redes de white hats o lanzar recompensas por vulnerabilidades 48 horas antes de la implementación, para obtener perspectivas externas y reducir riesgos.

/ 07 Restablecimiento posterior

Actuación rápida

Los fondos robados tienen un período de lavado, y los atacantes dividen y transfieren en múltiples cadenas. Conectar con Chainalysis u otros servicios de análisis en cadena, para marcar en tiempo real las direcciones de los atacantes y sus clusters, y alertar a los exchanges para bloquear transacciones. Preparar listas de contactos: departamentos de cumplimiento en exchanges, operadores de puentes cross-chain, administradores de custodios y terceros con permisos de congelación y bloqueo de fondos en tránsito.

Negociación y mediación

Aunque sea frustrante, se recomienda comunicarse con los atacantes. Siempre hay espacio para negociar. Publicar anuncios de recompensas blancas con plazo, prometiendo devolver fondos en tiempo y forma, y renunciar a acciones legales. Si los atacantes son de nivel estatal, probablemente no haya acuerdo; pero muchos solo buscan obtener beneficios discretos, y aún hay margen para negociar. Es imprescindible contar con asesoría legal en todo momento.

/ 08 Los ataques de hackers no desaparecerán, y con la evolución de la IA, solo serán más frecuentes. La defensa no puede confiar solo en la mejora interna; debe usar herramientas de IA similares a las de los atacantes, mantener una vigilancia constante, realizar simulacros de red y azul, y establecer límites estrictos de pérdida, para resistir riesgos extremos y sobrevivir en la industria.