Humanity Protocol: por qué un multisig 3-de-6 no frenó 36 M$

El 8 de junio de 2026, un atacante vació unos 36,4 millones de dólares de Humanity Protocol cruzando el umbral de firma de dos monederos multisig perfectamente legítimos. No hubo bug en el contrato. El multisig (monedero que exige varias firmas para mover fondos) era real: un Gnosis Safe configurado a 3-de-6 firmas en Ethereum y 3-de-5 en BNB Chain (BSC). El problema es que varias de esas claves de firmante —siete en total según el informe forense del equipo, incluidos los respaldos— vivían en el mismo portátil, el de Chong Yee Wai, director de la Humanity Foundation, infectado días antes por un correo de spear-phishing (ataque de phishing dirigido a una persona concreta) que imitaba al exchange coreano Bithumb. Cuando el malware obtuvo control de ese dispositivo, obtuvo el quórum entero. Este artículo reconstruye los tres vectores del ataque, por qué un 3-de-6 no protegió nada, y qué lecciones de gestión de claves deja para cualquier protocolo que custodie fondos institucionales.

¿Qué es Humanity Protocol y por qué importa este hack?

Humanity Protocol es un proyecto de identidad digital basado en verificación biométrica —escaneo de la palma de la mano— que se ha vendido como alternativa a Worldcoin, con foco en Asia. Su token, H, cotizaba alrededor de 0,70 dólares antes del incidente. El fundador, Terence Kwok, confirmó el exploit y, en el mismo movimiento, admitió un dato incómodo del proyecto: de los aproximadamente 9 millones de identidades registradas, menos de 1 millón corresponden a verificaciones biométricas reales; el resto son, en sus palabras, mayormente bots.

El interés del caso no está en la biometría, sino en la mecánica del robo. Humanity es el tercer gran hack de 2026 que no rompe una sola línea de código de un contrato inteligente y, en cambio, ataca a la persona que tiene las llaves. Encaja en un patrón que ya documentamos: los ataques apuntan a la infraestructura y al perímetro humano, no al contrato. Aquí el perímetro era un portátil.

¿Cómo se ejecutó el robo en tres vectores simultáneos?

El atacante no se conformó con drenar un monedero caliente. Una vez tuvo el control del dispositivo del director, atacó tres superficies a la vez el mismo día, exprimiendo cada permiso que esas claves concedían.

El bridge (puente que mueve tokens entre dos blockchains bloqueándolos en una y representándolos en la otra) fue el golpe más limpio: con tres de las seis firmas necesarias, el atacante actualizó el contrato del puente a una versión que él controlaba y extrajo más de 141 millones de tokens H. En BSC explotó el ProxyAdmin —el contrato administrador que decide qué código ejecuta un contrato actualizable— para encender la capacidad de acuñar tokens nuevos de la nada. Ahí está la cifra que conviene leer con cuidado: se autorizaron 300 millones de H para mint, de los que se ejecutaron unos 200 millones en la fase inicial. La oferta repentina, volcada en Uniswap y otros DEX (exchanges descentralizados), hundió el precio.

Los tres vectores comparten un mismo origen y por eso pudieron dispararse a la vez: las claves que autorizaban cada uno —firmar en el bridge, administrar el proxy, mover el monedero caliente— estaban al alcance del mismo dispositivo comprometido. Un atacante con un solo punto de control no tuvo que elegir; ejecutó las tres rutas en paralelo el mismo día. Esa simultaneidad es la firma de un compromiso de dispositivo, no de un exploit puntual: cuando cae el origen de las firmas, caen todas las superficies que esas firmas gobiernan.

¿Por qué un multisig 3-de-6 no fue suficiente?

Esta es la pregunta que importa, y la respuesta es contraintuitiva. Un multisig 3-de-6 suena robusto: ningún firmante puede mover fondos solo, y se toleran fallos de varias claves. Sobre el papel, hay seis personas o dispositivos repartiendo el poder.

El esquema solo cumple su promesa si esas seis claves están realmente separadas: distintas personas, distintos dispositivos, idealmente distintas ubicaciones físicas y, para las más sensibles, hardware air-gapped (aislado de la red). La seguridad de un umbral criptográfico depende de que comprometer una clave no acerque al atacante a las demás. Si tres claves —o más, contando respaldos— conviven en el mismo portátil, el atacante que toma ese portátil no necesita romper el esquema: lo satisface. Reúne el umbral en un solo movimiento. En Humanity, según el informe forense del equipo, hasta siete claves de firmante —sumando las de los dos multisig y sus respaldos— estaban al alcance de un único dispositivo: sobre el papel un 3-de-6 y un 3-de-5; en la práctica, un 1-de-1, porque bastaba caer en esa máquina para tenerlas todas.

Dicho de otro modo: distribución física no es lo mismo que umbral criptográfico. La redundancia numérica del 3-de-6 era ficticia porque la redundancia física no existía. El multisig estaba bien configurado en el contrato y mal desplegado en el mundo real. Es exactamente el fallo que separa la teoría de la gestión de claves de su práctica, y la razón por la que un lector que parte de cero debería entender primero qué es y qué no garantiza un multisig antes de confiarle fondos.

¿Cómo entró el atacante y qué huella apunta a Corea del Norte?

El punto de entrada no fue criptográfico, fue social. El 5 de junio, tres días antes del drenaje, llegó un correo de spear-phishing que imitaba a Bithumb, uno de los grandes exchanges coreanos. Chong Yee Wai, director de la Humanity Foundation, abrió el cebo y el dispositivo quedó infectado con un malware firmado con un certificado de Hancom —un proveedor de software surcoreano—, una técnica de firma robada que da apariencia de legitimidad al ejecutable.

Ese conjunto de indicadores —spear-phishing suplantando a un exchange, malware con certificado coreano comprometido, objetivo en el ecosistema asiático— encaja con el modus operandi de actores patrocinados por Corea del Norte (DPRK). La firma de seguridad Quantstamp, tras analizar el incidente, halló patrones característicos de intrusiones DPRK, pero no emitió una atribución definitiva ni nombró a un subgrupo concreto. Es un matiz importante: hay huella, no hay confirmación nominal. El patrón DPRK ya está ampliamente documentado en otros hacks de 2026, y lo cubrimos en detalle en el análisis del rastro de 577 millones a través de Drift y Kelp; aquí basta con situar a Humanity dentro de esa serie sin reproducir el dossier.

¿Fue un rug pull (fraude interno) o un hack externo?

Durante las primeras horas tras el robo a Humanity circuló la sospecha de que el incidente estuviera amañado desde dentro. El investigador on-chain ZachXBT lo calificó el 9 de junio de "possibly staged" —posiblemente teatralizado—, una hipótesis razonable cuando el dinero sale de monederos del propio equipo. Poco después revisó esa lectura.

Su conclusión final fue más matizada que un simple "fue un hack" o "fue un rug pull": la actividad del market maker (el creador de mercado que aporta liquidez al token) y el compromiso de la clave son eventos independientes. Es decir, lo que parecía coordinación interna era ruido de dos cosas que ocurrían a la vez sin estar conectadas. ZachXBT no afirmó haber confirmado una exfiltración externa con prueba cerrada; descartó el relato del montaje interno como explicación necesaria. El arco completo —sospecha, revisión, separación de los dos hechos— es parte del valor del caso: muestra lo difícil que es distinguir un robo de un fraude cuando los fondos salen de carteras propias.

¿Qué dice la cronología del ataque?

La secuencia datada deja claro que el robo no fue un instante, sino una operación con días de preparación y una cola que sigue abierta.

¿Qué lecciones de gestión de claves deja el caso?

Más allá de los nombres y las cifras, Humanity es un manual de lo que no hay que hacer al custodiar claves institucionales. Las tres lecciones operativas:

• Separación física real, no nominal. Las firmas de un multisig deben vivir en dispositivos distintos, en manos de personas distintas. Colocalizar varias claves —o sus respaldos— en una sola máquina convierte un 3-de-6 en un 1-de-1 disfrazado. El número del umbral no significa nada si la distribución física no lo respalda.
• Air-gap para las claves que mueven el tesoro. Las firmas con poder sobre bridges, mint y ProxyAdmin no deberían tocar nunca un portátil conectado a correo electrónico. El dispositivo que abre un PDF de Bithumb no puede ser el mismo que guarda la llave del puente.
• Separación de entornos y timelock en los contratos críticos. El ProxyAdmin que permite actualizar un contrato o acuñar tokens debería estar tras un timelock (retraso obligatorio entre orden y ejecución) que dé tiempo a detectar y revertir una orden maliciosa. Sin esa pausa, reunir el umbral equivale a ejecutar al instante, como ocurrió aquí.

Este último punto enlaza con un precedente directo de 2026: el hack de Drift Protocol en abril, donde un multisig también comprometido permitió a actores con huella DPRK ejecutar acciones sin freno. El patrón se repite: no se rompe la criptografía, se rompe el proceso humano alrededor de ella. Para el lector individual, la versión doméstica de este mismo error es exactamente la que describimos en cómo la gente pierde sus criptomonedas: la deriva operativa, no el fallo del protocolo.

La diferencia entre los protocolos que sobreviven a un compromiso de claves y los que no suele reducirse a si el contrato administrador tenía un timelock. Con un retraso obligatorio entre la orden de actualización y su ejecución, el equipo de Humanity habría tenido una ventana —horas, no segundos— para detectar la actualización maliciosa del bridge y revocarla antes de que drenara nada. Sin timelock, reunir tres firmas y vaciar el puente son el mismo acto. El ProxyAdmin de BSC que sigue comprometido a día de hoy es la otra cara del mismo problema: un administrador sin freno temporal es una llave maestra permanente, y mientras el atacante la conserve, el riesgo de nueva acuñación no desaparece. El coste de añadir ese timelock es de minutos de fricción operativa; el coste de no tenerlo, en este caso, fue de decenas de millones.

¿Cuál es el estado del proyecto y la recuperación?

A 17 de junio, la situación seguía abierta en un punto crítico: el ProxyAdmin de BSC continuaba bajo control del atacante, lo que mantiene viva la capacidad de acuñar más tokens. De los 300 millones de H autorizados para mint, se habían ejecutado unos 200 millones; el margen restante es el riesgo que sigue colgando sobre la red de BSC.

Del lado de la respuesta, el 16 de junio el equipo anunció su plan de recuperación: un airdrop 1:1 (distribución gratuita de tokens a los afectados) de un nuevo token H, esta vez como ERC-20 en Ethereum, tomando como referencia un snapshot (instantánea del estado de la red) previo al ataque. No se trata de un "H2" ni de un ratio extraño —es un reemplazo uno a uno del token afectado—. La efectividad de ese plan depende de cerrar antes el ProxyAdmin comprometido; si no, el nuevo token hereda el mismo riesgo de oferta incontrolada. A 17 de junio, el propio equipo calificaba el H de BSC como "permanentemente comprometido" y no había recuperado el control del ProxyAdmin.

¿Qué cambia en la gestión de claves tras el caso Humanity?

Humanity Protocol no fue hackeado por tener un mal contrato ni un mal multisig. Fue hackeado por desplegar un buen multisig de forma que su garantía no existía. La lección no es "usa multisig" —ya lo usaba—, sino que el esquema solo vale lo que valga la separación física y operativa de sus claves. Tres firmas de seis no protegen nada si tres firmas viven en el mismo disco duro.

Para 2026, este es ya el patrón dominante de los grandes robos: ingeniería social contra una persona con acceso, no exploits contra el código. Tres de los mayores incidentes del año —Drift y Kelp en abril, Humanity en junio— comparten el mismo esqueleto: huella de actores DPRK, entrada por compromiso humano o social, y un mecanismo de control (multisig o administrador de proxy) que se satisface en lugar de romperse. El perímetro defendible se ha movido del contrato al portátil. Quien custodie fondos —institución o individuo— defiende hoy un dispositivo y un proceso, no solo una línea de Solidity.

La pregunta práctica para cualquier equipo que lea esto no es "¿tenemos multisig?", sino tres preguntas más incómodas: ¿dónde viven físicamente nuestras claves, incluidos los respaldos? ¿cuántas de ellas podría reunir quien comprometa un solo dispositivo? ¿y cuánto tiempo nos daría un timelock para revertir una orden maliciosa? Humanity falló las tres. Responderlas bien no es glamuroso ni sale en la hoja de ruta (roadmap), pero es la diferencia entre un susto y un titular de 36 millones.

Fuentes y enlaces: Rekt.news — Humanity Protocol post-mortem (16-jun-2026) · Halborn — análisis técnico del hack · crypto.news — análisis de ZachXBT · CryptoBriefing — patrones DPRK (Quantstamp) · CryptoTimes — plan de recuperación y airdrop · CoinDesk — el multisig que vivía en un solo portátil