Verus y Ostium: Mismos Protocolos, Hackeados Dos Veces, Misma Excusa
Una vez es mala suerte. Dos veces es un modelo de negocio.
Le dieron el palo a Verus. Luego le volvieron a zumbar. Que si Ostium, que si Ostium otra vez. Da igual los protocolos, la jugada es la misma — una "clave comprometida", un multisig a estrenar, la promesa de que ahora sí, que esto va en serio, y la procesión de ilusos listos para soltar la gallina por tercera vez. Nosotros, en vez de tragarnos el cuento, miramos la movida por detrás del comunicado oficial.
El Esquema
Dos protocolos — Verus (una cadena ZK-friendly que sigue reconstruyendo su puente) y Ostium (un DEX de perpetuos en Arbitrum) — fueron explotados con semanas de diferencia, parcheados y explotados de nuevo por la misma clase de bug: claves que no deberían estar 'hot,' firmantes de oráculo reutilizables y rutas de upgrade privilegiadas sin time-lock. Las pérdidas combinadas rondan las decenas de millones.
El parche cerró la puerta por la que entró el atacante. No cerró la puerta de al lado.
La Parte Incómoda: Esto No Fue Un Zero-Day
En crypto, 'ataque sofisticado' suele traducirse como 'olvidamos rotar una clave.' Verus y Ostium cayeron por una clase de fallo que está en toda checklist desde 2022: direcciones privilegiadas con poder permanente, firmantes de oráculo con secretos compartidos y funciones de upgrade sin time-lock delante.
Verus fue drenado, culpó a un firmante comprometido, redeployó y volvió a ser drenado — porque el redeploy heredó el mismo modelo operativo. Ostium fue drenado vía abuso de oráculo, parcheó ese oráculo específico y volvió a ser drenado vía una ruta de mispricing relacionada. Mismo edificio, otra ventana.
Lo grave no es que existan estos bugs. Es que ambos equipos enviaron 'el fix' lo bastante rápido como para parecer decididos, pero no lo bastante lento como para entender qué se rompió de verdad. En DeFi, la velocidad del anuncio ya correlaciona a la inversa con la calidad de la remediación.
'Lo hemos parcheado' es marketing. 'Lo hemos rearquitecturado' es seguridad. Aprende la diferencia.
Anatomía De Un Exploit Repetido
Un exploit repetido no es coincidencia. Es una firma. Significa que la causa raíz se diagnosticó mal la primera vez, que la revisión del incidente se optimizó para el tuit-explicación y que la suposición de confianza subyacente — 'esta clave está a salvo,' 'este set de firmantes es honesto,' 'este feed de precio es monótono' — nunca fue realmente cuestionada.
En el caso de Verus, la suposición era que un set pequeño de operadores podía custodiar reservas de puente sin un esquema de threshold-signing que sobreviva a un solo portátil comprometido. En Ostium, era que un DEX de perpetuos podía apoyarse en una ruta de oráculo que no había sido testada contra una mecha coordinada.
Ambos equipos publicaron el post-mortem — bien hecho — y ambos evitaron publicar un threat model completo. Así es como se llega a la ronda dos. El público ve un fix. El atacante ve una pista.
El primer exploit es un bug. El segundo exploit es una política.
Vocabulario Decodificado: El Manual Del Segundo Hackeo
Lo que dijo el comunicado vs lo que realmente significaba:
"Clave privada comprometida"
Cómo suena:
Un ataque desafortunado y muy dirigido contra un hardware wallet en manos de un miembro concreto del equipo.
Qué pasó de verdad:
Una clave hot, en una máquina conectada a internet, con autoridad permanente sobre el protocolo, usada por comodidad. Fue phisheada, malwareada o filtrada por un paquete de la supply-chain. 'Comprometida' es voz pasiva para 'elegimos velocidad sobre ceremonia.'
"Manipulación de oráculo"
Cómo suena:
Un ataque de precio on-chain sofisticado que ningún equipo razonable podría haber predicho.
Qué pasó de verdad:
El protocolo eligió un oráculo con liquidez fina y sin fallback TWAP, porque un oráculo de verdad cuesta dinero y hacer fork del testnet cuesta cero. El atacante imprimió una mecha y drenó el lado perp. No es manipulación si el diseño la invitó.
"Hemos actualizado los contratos"
Cómo suena:
El código vulnerable ha sido sustituido por código endurecido, auditado y con time-lock.
Qué pasó de verdad:
Una sola clave admin subió una nueva implementación tras un proxy upgradeable, a veces sin time-lock, a veces sin auditoría nueva. 'Actualizado' puede significar 'cambiamos una función.' Rara vez significa 'cambiamos el modelo de confianza.'
Todo post-mortem de segundo hackeo usa las mismas tres frases. Pregunta por qué.
Cómo Un Protocolo Cae Dos Veces
Cuatro pasos, siempre los mismos. Cambian los nombres, no la secuencia.
Paso 1: Envía Rápido, Confía Ancho
Lanza con un multisig pequeño, un firmante hot y un proxy upgradeable tras una sola admin key. El TVL crece antes que la gobernanza. La superficie de confianza ya es mayor de lo que el equipo admite en público.
Todo protocolo 'descentralizado' tiene un portátil de fundador en el loop. Solo hay que buscar el enchufe.
Paso 2: Sé Golpeado, Anuncia Rápido
El atacante encuentra la palanca obvia — firmante comprometido, oráculo mal valorado, upgrade sin control. Los fondos se mueven. El equipo publica 200 palabras con las palabras 'aislado,' 'contenido' y 'comprometido.' El parche llega en menos de 48h.
El reloj del segundo exploit empieza cuando se anuncia el primer parche. Porque ahora el atacante sabe qué se les escapó.
Paso 3: Arregla El Síntoma, No El Sistema
El parche cierra la función exacta. El modelo de confianza — quién tiene qué llave, qué oráculo alimenta qué mercado, quién puede upgradear qué proxy — no cambia. El equipo está agotado, los usuarios quieren volver online, y 'rearquitecturar' pierde contra 'redeployar.'
'El botón de pausa funcionó' no es un logro cuando el botón de pausa es lo único entre los usuarios y una repetición.
Paso 4: Sé Golpeado De Nuevo, Culpa Al Atacante
Una ruta relacionada — mismo set de claves, misma familia de oráculo, misma superficie de upgrade — es explotada dos a ocho semanas después. El segundo comunicado es más corto que el primero. Dice 'sofisticado' y 'coordinado.' No dice 'nosotros.'
Sofisticado significa que el atacante leyó bien el primer post-mortem. Cosa que, seamos honestos, es más de lo que hicieron los usuarios.
Kill Chain Técnica: El Patrón Repetido
Reconstruida desde las notas públicas de ambos protocolos, más alertas de SlowMist y PeckShield:
T-0: Primer Exploit
Un firmante privilegiado o ruta de oráculo es abusada. Los fondos salen por un puente o un payout perp. El equipo se entera por un ping en Discord de un whitehat, no por monitoreo interno.
'Nos alertaron miembros de la comunidad' es la frase que termina todo incident review que ningún equipo de seguridad quiere escribir.
T+24h: El Comunicado
Se publica un post-mortem. Identifica correctamente la causa inmediata. No publica el threat model, el diagrama de custodia de claves ni el grafo de dependencias de oráculos. Se pide paciencia.
El post-mortem está optimizado para el equipo legal, no para seguridad. Por eso se lee como una nota de prensa con un gráfico.
T+3–14d: El Redeploy
Se despliegan nuevos contratos. A veces con multisig nuevo, a veces no. La ruta de upgrade se preserva. Se cambia el proveedor de oráculo, no la arquitectura del oráculo. El TVL vuelve más rápido que la auditoría.
Redeployar dentro del mismo modelo de confianza no es un fix. Es un reroll.
T+2–8sem: Ronda Dos
Un segundo exploit — a menudo de un atacante distinto que leyó el primer post-mortem — golpea una superficie relacionada. Las pérdidas son menores que en la ronda uno porque los usuarios ya retiraron. La reputación cae más, porque ya es un patrón.
El segundo hack es donde los bagholders descubren cuánto cuesta 'battle-tested' de verdad.
Dos exploits. Mismo modelo de confianza. Misma excusa. Distinto atacante. Eso no es mala suerte — es un spec.
Ficha Del Reincidente: Ronda 1 vs Ronda 2
Dos protocolos, cuatro incidentes, un solo modelo de confianza. Puesto lado a lado, el patrón deja de parecer mala suerte y empieza a parecer un plan de negocio del atacante.
| Expediente | Ronda 1 | El 'parche' | Ronda 2 |
|---|---|---|---|
| Verus | Firmante del puente comprometido; reservas drenadas | Redespliegue en días, mismo set de claves | Drenado otra vez — la clave nunca fue el bug |
| Ostium | Ruta de oráculo abusada en el lado perp | Se cambia el proveedor, no la arquitectura | Mispricing relacionado, misma familia de feeds |
| Ambos | Aviso vía Discord, no vía monitoreo | Post-mortem de 200 palabras | Segundo comunicado más corto que el primero |
Un ladrón que vuelve a la misma casa no es audaz. Sabe que nadie cambió la cerradura, sólo barnizó la puerta.
Quién Más Corre Este Patrón
El patrón no murió con Verus y Ostium. Tres comprobaciones de tres minutos te dicen si el protocolo que tienes abierto en otra pestaña es el siguiente de la lista.
1. Upgrade sin time-lock
Busca el proxy en el explorer: si el admin puede cambiar la implementación al instante, no hay perímetro.
2. Firmantes que no cambiaron
Compara el multisig de hoy con el de antes del incidente. Mismas direcciones = mismo riesgo.
3. Un solo feed de precio
Si la doc menciona un proveedor y ningún TWAP ni límite de desviación, ya viste el final.
Tres pestañas, tres minutos. Más due diligence que la que hizo la mitad de la ronda semilla.
Por Qué Los Usuarios Vuelven Igual
La verdad incómoda es que los usuarios drenados en la ronda dos suelen ser los que vieron la ronda uno desde fuera y pensaron que el parche hacía las cosas más seguras. No lo hizo. Las hizo objetivo.
Amnesia De Yield
Un 18% APY en un contrato redeployado parece un chollo. Es un descuento por aceptar riesgo no documentado. El mercado olvida en seis semanas.
'Ya Pasaron Por Esto'
Existe la creencia popular de que un protocolo que sobrevivió a un exploit es más seguro. Es al revés. Un protocolo que sobrevivió es uno que ha demostrado que anuncia primero y rearquitectura después.
Miedo A Perderse La Recuperación
'Nunca estará tan barato' es la segunda frase más cara en DeFi. La primera es 'el equipo lo tiene controlado.'
El Aval Del Ecosistema
Un inversor tier-1 tuitea 'seguimos confiando.' Un protocolo partner whitelistea la nueva dirección. Los usuarios lo leen como due diligence. Es material de marketing.
Los exploits repetidos no sobreviven por estupidez del usuario. Sobreviven por esperanza — y la esperanza es el único activo con supply ilimitado en crypto.
Cómo No Financiar La Ronda Tres
Seis reglas para la próxima vez que caiga un 'nos han explotado' en tu feed:
- Regla 1: Espera 60 días mínimo tras cualquier post-mortem No 6 horas. No 6 días. Dos meses completos de operación limpia sobre los contratos redeployados, con monitoreo público, antes de reentrar.
- Regla 2: Lee el threat model, no el tuit Si el equipo no publicó diagrama de custodia de claves, grafo de dependencias de oráculos y política de time-lock, no terminó el incident review.
- Regla 3: Verifica si la ruta de upgrade tiene time-lock Un protocolo cuya admin key puede subir código al instante no tiene perímetro de seguridad real. Gobernanza sin delay es teatro.
- Regla 4: Mira el set de firmantes, no el branding Si los firmantes del multisig no cambiaron tras un firmante comprometido, no cambió nada. Un rebrand no es una rotación.
- Regla 5: Asume que los parches de oráculo son parciales Cambiar de proveedor no es cambiar de arquitectura. Pregunta si añadieron TWAP, circuit breakers y caps de manipulación — o solo una URL nueva.
- Regla 6: Dimensiona para la ronda dos, no la uno Si tienes que volver, dimensiona la posición para la pérdida que aceptarías en un segundo exploit. En un patrón repetido, la ronda dos ya está en precio.
¿Recibiste un Mensaje Sospechoso?
Usa nuestro detector con IA para analizar posibles estafas al instante.
Conclusiones Clave
- 1Verus y Ostium fueron explotados dos veces por la misma clase de fallo — claves privilegiadas y suposiciones de oráculo que el primer parche no tocó.
- 2Un exploit repetido es un diagnóstico, no una coincidencia. El modelo de confianza no cambió, solo la función abusada.
- 3'Clave privada comprometida,' 'manipulación de oráculo' y 'hemos actualizado los contratos' son las tres frases que aparecen antes de toda ronda dos. Rastréalas.
- 4La velocidad del anuncio correlaciona a la inversa con la calidad de la remediación. Un parche en 24h es síntoma de presión, no de competencia.
- 5Los avales del ecosistema tras un exploit son marketing, no due diligence. El tuit de un inversor tier-1 no es una auditoría.
- 6Si vas a reentrar en un protocolo drenado: espera 60 días, verifica que cambió el set de firmantes, que el upgrade tiene time-lock y dimensiona para un segundo golpe.
Una vez es un bug.
Dos veces es una política.
Preguntas Frecuentes
Fuentes y Citas
Investigación compilada de datos de blockchain disponibles públicamente, informes de seguridad y documentación de la comunidad.
ostium.io
slowmist.com
peckshield.com
Verificación: Todas las transacciones y direcciones de blockchain referenciadas en este artículo pueden verificarse de forma independiente a través de los exploradores de blockchain enlazados. Animamos a los lectores a realizar su propia verificación.
Metodología: Cada caso requiere al menos tres fuentes independientes más evidencia on-chain verificable antes de publicarse. Estándares completos: /es/methodology
Aviso legal: Esta evaluación se basa en datos disponibles públicamente, incluidos registros on-chain, comunicados oficiales e incidentes documentados. Es un análisis periodístico y educativo, no asesoramiento legal, una acusación de conducta delictiva ni una resolución judicial. Las empresas, proyectos, dominios, carteras y personas nombradas se describen según las fuentes citadas; una empresa puede aparecer porque fue suplantada por estafadores, no porque hiciera algo indebido. Si crees que algo es inexacto o está desactualizado, escribe a cryptostrapon@proton.me y lo corregiremos registrando el cambio. Política editorial