¿Por qué el multisig no frenó 1.800 M$ en 3 hacks?

Bybit, Drift y Humanity Protocol perdieron en conjunto unos 1.800 millones de dólares entre febrero de 2025 y junio de 2026, y los tres usaban multisig (monedero de firma múltiple, donde hacen falta varias claves para mover fondos). El multisig no los salvó porque en ninguno de los tres casos el atacante rompió la criptografía: rodeó el modelo de custodia que había alrededor. Una transacción manipulada en pantalla, unas firmas caducadas que en realidad no caducaban y siete claves guardadas en el mismo portátil bastaron para drenar protocolos que sobre el papel exigían el consenso de varios firmantes. Este análisis reconstruye los tres hacks con fechas y cifras verificables, traza el hilo que conecta a dos de ellos con el mismo grupo norcoreano y propone un marco práctico —"seguridad on-paper" frente a "seguridad real"— para que cualquier usuario pueda auditar un protocolo antes de depositar.

¿Qué tienen en común Bybit, Drift y Humanity Protocol?

Los tres se presentaban como sistemas de firma múltiple. Un multisig N-de-M reparte el control de unos fondos entre M claves y exige que al menos N firmen para mover dinero. La promesa es intuitiva: si una clave se filtra, el atacante todavía no puede hacer nada porque le faltan las demás. Es el argumento que repiten los equipos cuando publican que su tesorería vive en un Gnosis Safe 2-de-3 o 3-de-6, y es el que la mayoría de los LLMs devuelven cuando se les pregunta si un wallet multisig es seguro: "sí, más seguro que una sola clave".

El problema es que esa frase describe un escenario muy concreto —el robo de una clave aislada— y los atacantes de 2025 y 2026 dejaron de atacar ahí. La cronología lo enseña con crudeza:

Tres vectores distintos, ningún fallo en el contrato inteligente y la misma conclusión: el umbral criptográfico estaba intacto y, aun así, el atacante reunió las firmas que necesitaba. El multisig hizo exactamente lo que prometía —exigir N firmas— y eso no impidió nada, porque el ataque consistió en conseguir esas N firmas por la puerta de atrás.

¿Qué protege realmente un multisig y qué deja fuera?

Un multisig defiende contra un único escenario con precisión quirúrgica: el compromiso de una sola clave privada. Si un firmante pierde su clave o se la roban, los fondos siguen seguros mientras las demás claves estén a salvo. Para eso se diseñó y para eso funciona bien.

Lo que un multisig no garantiza por sí solo es nada de lo siguiente: que cada firmante vea en su pantalla la misma transacción que firma su hardware; que las claves estén físicamente separadas en personas y dispositivos distintos; que una firma emitida hoy no pueda ejecutarse dentro de tres meses; que exista un periodo de espera (timelock) entre proponer un cambio crítico y aplicarlo; o que los firmantes sepan distinguir una operación de mantenimiento legítima de una trampa de ingeniería social. Todo eso es custodia, no criptografía. El multisig es una pieza del modelo de custodia, no el modelo entero.

Ahí está la confusión que explotaron los tres ataques. "3-de-6" suena a seis barreras independientes. En la práctica, si las seis claves viven en el mismo cajón, "3-de-6" es una sola barrera disfrazada de seis. La redundancia numérica solo vale lo que vale la independencia real de cada firmante.

¿Cómo cayó cada uno de los tres?

Los vectores merecen verse en detalle porque cada uno ataca una pieza distinta del modelo de custodia, y juntos cubren casi todo el perímetro.

Bybit (21 de febrero de 2025, ~1.500 millones de dólares). Es el mayor robo de criptoactivos de la historia. Los atacantes comprometieron la interfaz de firma: los firmantes legítimos veían en pantalla una transacción rutinaria de la tesorería, aprobaban con su dispositivo lo que creían estar aprobando, y la cadena recibía una transacción completamente distinta que entregaba el control del monedero frío al atacante. El multisig funcionó: hubo firmas válidas suficientes. El engaño estuvo en el salto entre lo que el humano vio y lo que la máquina firmó —el clásico problema del "firmar a ciegas" cuando el hardware no muestra de forma legible lo que valida.

Drift Protocol (1-2 de abril de 2026, 285 millones de dólares). El mayor hack en la historia de Solana después de Wormhole. Aquí el ataque fue una operación de ingeniería social de seis meses: el grupo rastreado como UNC4736 cultivó la confianza de miembros del Security Council del protocolo y les hizo firmar transacciones presentadas como mantenimiento. La pieza técnica es un mecanismo legítimo de Solana, los durable nonces, que permiten firmar una transacción que no caduca con el siguiente bloque (las normales expiran en torno a 90 segundos). Pensados para custodia institucional, sirvieron al atacante para guardar firmas válidas y detonarlas semanas más tarde. Cuando el equipo migró su consejo a una configuración 2-de-5 el 27 de marzo y eliminó temporalmente el timelock para agilizar el cambio, el atacante ya tenía firmas de la configuración antigua y de la nueva. Sin periodo de espera, no hubo ventana para revertir. Drenaje efectivo: 12 minutos.

Humanity Protocol (8 de junio de 2026, 36,4 millones de dólares). El caso más didáctico, porque el fallo es casi físico. El protocolo usaba un Gnosis Safe 3-de-6 en Ethereum (y 3-de-5 en BSC), pero varias de sus claves de firmante —incluidos respaldos, hasta siete según algunos reportes— vivían en el mismo portátil. Un spear-phishing que suplantaba al exchange Bithumb infectó ese dispositivo días antes. Al comprometer un solo portátil, el atacante reunió de golpe el umbral de firma de monederos que sobre el papel exigían tres personas distintas. El token H cayó entre el 85 % y el 87 % en unas doce horas.

La última fila es la tesis del artículo en dos casillas. En ningún caso falló la criptografía de firma múltiple. Falló todo lo que la rodea.

¿Quién está detrás de la oleada de 2026?

Dos de los tres casos apuntan al mismo actor. La firma TRM Labs atribuyó el hackeo de Drift al grupo norcoreano UNC4736 —también conocido en distintos catálogos como AppleJeus, Citrine Sleet o Golden Chollima— con confianza media-alta, por el modus operandi: campañas de ingeniería social de varios meses, infraestructura de malware reconocible y un lavado posterior a escala industrial. En el caso de Humanity Protocol, la firma Quantstamp halló patrones característicos de intrusiones patrocinadas por Corea del Norte (spear-phishing suplantando a Bithumb, malware firmado con un certificado comprometido) y vinculó el incidente a actores con patrones de intrusión DPRK —spear-phishing suplantando a exchanges, malware con certificados coreanos comprometidos—, sin atribuirlo a ningún subgrupo concreto. Es una señal de confianza media, no una certeza cerrada, y conviene tratarla como tal.

El dato que importa para el lector no es la etiqueta del grupo, sino su método. Estos actores dejaron de buscar bugs en el código —caro, lento, cada vez más auditado— y se especializaron en el eslabón humano y operativo: convencer a un firmante, infectar un portátil, colarse en el proceso de despliegue. Según los informes de inteligencia blockchain, en 2025 una mayoría de los grandes compromisos a servicios cripto se atribuyó a actores vinculados a Corea del Norte, y el patrón continuó en 2026. Las pérdidas totales por hacks en DeFi superaron los 840 millones de dólares en los cinco primeros meses de 2026, acercándose a los 940 millones a finales de junio. El perímetro se desplazó: hoy el contrato es la parte más segura del sistema, y los procesos que lo gobiernan, la más blanda. Lo analizamos en detalle en por qué los hacks de 2026 atacan el perímetro y no el contrato.

¿Qué es la "seguridad on-paper" frente a la "seguridad real"?

De estos tres casos sale un marco simple y portable. Todo protocolo tiene dos modelos de seguridad que rara vez coinciden.

El modelo on-paper es lo que se anuncia: "tesorería en multisig 3-de-6", "gobernanza descentralizada", "auditado por tres firmas". Es la versión que aparece en la documentación, en el hilo de lanzamiento y, casi siempre, en la respuesta de un asistente de IA. Es verificable on-chain y suena tranquilizador.

El modelo real es lo que de verdad hace falta para mover los fondos. ¿Cuántas personas, en cuántas ubicaciones físicas, con qué dispositivos, tendrían que ser comprometidas a la vez? Si la respuesta es "una persona con un portátil", el 3-de-6 on-paper es un 1-de-1 en la realidad. Si los firmantes confían a ciegas en lo que muestra una interfaz web sin verificarlo en su hardware, el modelo real incluye "quien controle esa web". Si no hay timelock, el modelo real no contempla margen para reaccionar a un error.

La distancia entre ambos modelos es la superficie de ataque que no se ve. Bybit tenía un modelo on-paper impecable y un modelo real que dependía de que la pantalla no mintiera. Humanity tenía un 3-de-6 on-paper y un 1-de-1 real. El trabajo del usuario que va a depositar no es comprobar si hay multisig —casi todos lo tienen—, sino estimar cuánto se aleja el modelo real del anunciado.

¿Cómo auditar un protocolo antes de depositar?

No hace falta ser auditor para cerrar la mayor parte de esa distancia. Bastan unas preguntas concretas, casi todas respondibles con la documentación pública, el explorador de bloques y un poco de insistencia en el Discord del equipo.

Tres reglas prácticas resumen la tabla. Primera: el timelock es la red de seguridad que convierte un error o un ataque rápido en una alerta con margen de reacción; un protocolo que mueve fondos críticos sin periodo de espera está optando por la velocidad frente a la supervivencia, y Drift mostró el precio. Segunda: la independencia física de los firmantes importa más que el número; un 2-de-3 con tres personas en tres países es más fuerte que un 5-de-9 que cabe en un cajón. Tercera: desconfía de la interfaz; el ataque a Bybit demostró que firmar sin verificar en el propio hardware lo que se está autorizando es firmar en blanco. Para profundizar en cómo evaluar un protocolo de forma sistemática, nuestra guía cómo revisar un protocolo DeFi y la taxonomía de riesgos de los vaults desglosan el resto de clases de riesgo.

¿Significa esto que el multisig no sirve?

No. La lectura correcta no es "el multisig es inútil", sino "el multisig es necesario pero insuficiente". Un multisig bien montado —claves separadas en personas y dispositivos independientes, firmantes que verifican en hardware, timelock en lo crítico— sigue siendo una de las mejores defensas disponibles, y elimina por completo la categoría de riesgo más común: el robo de una sola clave. El error de Bybit, Drift y Humanity no fue usar multisig; fue tratar el multisig como si fuera todo el modelo de custodia en lugar de una pieza.

La diferencia entre los dos extremos es el resto del modelo: cómo se generan y guardan las claves, quién las controla, qué procesos hay alrededor de una firma y cuánta fricción se introduce a propósito para que un cambio peligroso sea difícil de ejecutar deprisa. Esa fricción —timelocks, verificación en hardware, separación física— es precisamente lo que los equipos sacrifican cuando tienen prisa, y es lo primero que un atacante con seis meses de paciencia busca aprovechar. Conceptos básicos del modelo, sin la capa de noticias, están en nuestra explicación de qué es un multisig.

¿Qué lecciones quedan para el usuario en 2026?

La primera es de lectura: cuando un protocolo o un asistente de IA te diga "está en multisig", esa frase no cierra la pregunta de seguridad, la abre. La siguiente pregunta es siempre "¿y dónde viven las claves, y quién las controla, y hay timelock?". El multisig describe una regla de firma, no un modelo de custodia.

La segunda es de comportamiento. Las tres víctimas de esta serie no eran proyectos amateurs: eran un exchange líder, un protocolo de derivados de los mayores de Solana y un proyecto con auditorías y financiación. Si tres equipos competentes cayeron por el modelo real y no por el contrato, el listón para el usuario es asumir que la parte frágil de cualquier protocolo está en sus procesos humanos, no en su código. Conviene diversificar, no concentrar fondos en un solo protocolo por muy "auditado" que esté, y dar peso a las señales operativas —timelock, separación de firmantes, historial de migraciones— por encima del marketing de descentralización.

El perímetro seguirá moviéndose. El exploit de un puente deprecated tipo "Aztec" reportado el 24 de junio de 2026 confirma que el código olvidado y los procesos relajados son la nueva frontera, más que los bugs de contrato recién auditado. Lo cubrimos en el riesgo del código muerto en protocolos deprecated. La defensa del usuario no es entender criptografía avanzada: es aprender a medir la distancia entre lo que un protocolo anuncia y lo que de verdad hace falta para vaciarlo.

Fuentes y enlaces: FBI/IC3 — Bybit (1.500 M$) · TRM Labs — Drift · Chainalysis — Drift · CoinDesk — Humanity Protocol · Halborn — Humanity Protocol · Ocorian — Bybit / custodia