Cuando una plataforma DeFi sufre un robo de 285 millones de dólares—como acaba de sucederle a Drift Protocol en Solana—la pregunta no es solo cómo fue posible, sino cómo evitar que el próximo nombre en el encabezado sea el propio. La sofisticación del ataque, atribuida a grupos vinculados a Corea del Norte, puso a prueba los límites técnicos y operativos de la seguridad en desarrollos blockchain. Para quienes diseñamos, administramos y auditamos infraestructuras TI, estos incidentes ya no son rarezas: son advertencias que, si se ignoran, acercan el riesgo a los sistemas propios.
El blindaje que se suponía infranqueable
Durante años, mucha de la narrativa alrededor de DeFi y exchanges descentralizadas ha girado en torno a la robustez de las firmas multisig, los timelocks y la trazabilidad on-chain como elementos que harían a estos sistemas más seguros que el sector financiero tradicional. Sin embargo, basta ver cómo en Drift Protocol los atacantes manipularon cuentas nonce duraderas para pre-firmar operaciones maliciosas—técnica que evadió controles sin levantar alertas. Más allá de la espectacularidad del monto robado, lo relevante es la profundidad del trabajo: hasta seis meses de preparación silenciosa, repitiendo lo que hemos visto tantas veces cuando auditores descubren cuentas privilegiadas olvidadas o llaves de API compartidas donde no deberían estar. El diferencial está en la agilidad del adversario: cuando el monitoreo interno es reactivo y los sistemas no logran visibilidad sobre la actividad “dormida” pero peligrosa, el ataque gana meses de ventaja.
Timelocks y multisig bajo el microscopio: ¿resguardos o puntos ciegos?
Muchos protocolos DeFi descansan en la ilusión de que un multisig bien distribuido y un plazo de bloqueo en las operaciones dan suficiente tiempo para reaccionar. Esta confianza fue parte del desastre: durante el ataque a Drift, decisiones clave en la aprobación multisig pasaron bajo ingeniería social y los timelocks sirvieron solo para marcar cuándo comenzaba la carrera de los atacantes para ejecutar su plan. El uso de un token falso inflado para asegurar préstamos es la clásica táctica de “wash trading”, llevada al extremo porque los validadores no detectaron la manipulación a tiempo. Así, el proceso de retiro fue tan breve—apenas 12 minutos—que ningún sistema automatizado de alertas reaccionó en forma útil. Algo similar ocurre cuando equipos de TI caen en la tentación de nodos o firewalls mal segmentados porque “el tráfico parece seguro” o “el proceso de aprobación es suficiente”. La realidad demuestra que el margen de error es brutalmente pequeño y que los mismos mecanismos de confianza pueden servir de palancas a quien busca vulnerarlos.
Monitoreo proactivo: una lección que el sector blockchain debe asimilar ya
Rastrear el staged attack fue posible gracias a investigaciones forenses y firmas como Elliptic y TRM Labs, que vieron señales en los movimientos on-chain semanas antes. Esto confirma que las trazas estaban ahí, pero pasaron inadvertidas al foco del equipo de Drift. El paralelismo con los ambientes corporativos es directo: el staging malicioso es idéntico a cuando un atacante interna recursos en el dominio, espera semanas y recién después despliega el ransomware o extrae bases de datos. El principio es simple: si el monitoreo y los logs existen solo para revisar después del incidente, ya es tarde. La auditoría exhaustiva de contratos, validación cruzada de colaterales y seguimiento de actividad atípica debe estar automatizada y recibir atención diaria, no semanal ni solo tras “una sospecha”.
Hoja de ruta realista para equipos TI y desarrolladores blockchain
La recomendación no es solo “auditar” ni “actualizar el software”. En la práctica, lo indispensable es fijar ventanas de mantenimiento con parches planificados, donde los equipos monitorean en tiempo real las variaciones de los vaults y los contratos principales. En sistemas críticos, todo cambio de configuración de multisig debería ir acompañado de doble verificación y alertas que escalen a responsables externos si algo inusual ocurre. Establecer un monitoreo activo sobre transferencias masivas o tokens que alteran su capitalización de forma anómala reduce el tiempo de detección del staging. Adaptar tecnologías SIEM (security information and event management) para entornos blockchain permite tener alertas más allá del log on-chain tradicional, integrando señales externas y triggers internos antes de que la explotación ocurra.
Mirando hacia adelante: el costo de la pasividad es exponencial
La sofisticación vista en Drift Protocol se va a repetir, no solo a nivel internacional sino localmente, sobre todo a medida que actores de América Latina y Chile aumenten su exposición en staking, lending y otros modelos DeFi. La única alternativa viable es abrazar un modelo de seguridad ofensiva donde se asume que el adversario está adentro o pronto lo estará. Los protocolos pueden ser abiertos, pero la vigilancia y la respuesta no pueden nunca descansar. Hoy, cada ventana sin parcheo y cada cuenta multisig no auditada es una invitación a que el siguiente ataque no sea noticia internacional, sino simplemente un reporte de cierre forzado.
