Humanity Protocol: por que um multisig 3-de-6 não impediu 36 M$

Em 8 de junho de 2026, um invasor drenou cerca de 36,4 milhões de dólares do Humanity Protocol ao ultrapassar o limite de assinaturas de duas carteiras multisig perfeitamente legítimas. Não houve bug no contrato. O multisig (carteira que exige várias assinaturas para movimentar fundos) era real: um Gnosis Safe configurado para 3-de-6 assinaturas no Ethereum e 3-de-5 na BNB Chain (BSC). O problema é que várias dessas chaves de signatário — sete no total, segundo o relatório forense da equipe, incluindo os backups — residiam no mesmo notebook, o de Chong Yee Wai, diretor da Humanity Foundation, infectado dias antes por um e-mail de spear-phishing (ataque de phishing direcionado) que imitava a exchange coreana Bithumb. Quando o malware obteve controle do dispositivo, obteve o quórum inteiro. Este artigo reconstrói os três vetores do ataque, por que um 3-de-6 não protegeu nada e quais lições de gestão de chaves ficam para qualquer protocolo que custodie fundos institucionais.

O que é Humanity Protocol e por que este hack importa?

O Humanity Protocol é um projeto de identidade digital baseado em verificação biométrica — escaneamento da palma da mão — que tem sido comercializado como uma alternativa ao Worldcoin, com foco na Ásia. Seu token, H, estava cotado em torno de 0,70 dólares antes do incidente. O fundador, Terence Kwok, confirmou o exploit e, no mesmo movimento, admitiu um dado desconfortável sobre o projeto: dos aproximadamente 9 milhões de identidades registradas, menos de 1 milhão correspondem a verificações biométricas reais; o restante são, em suas palavras, majoritariamente bots.

O interesse do caso não está na biometria, mas na mecânica do roubo. O Humanity é o terceiro grande hack de 2026 que não quebra uma única linha de código de um contrato inteligente e, em vez disso, ataca a pessoa que detém as chaves. Ele se encaixa em um padrão que já documentamos: os ataques visam a infraestrutura e o perímetro humano, não o contrato. Aqui, o perímetro era um notebook.

Como o roubo foi executado em três vetores simultâneos?

O invasor não se contentou em drenar uma hot wallet. Uma vez que teve o controle do dispositivo do diretor, atacou três superfícies ao mesmo tempo no mesmo dia, explorando cada permissão que aquelas chaves concediam.

A bridge (ponte que move tokens entre duas blockchains, bloqueando-os em uma e representando-os na outra) foi o golpe mais limpo: com três das seis assinaturas necessárias, o invasor atualizou o contrato da ponte para uma versão controlada por ele e extraiu mais de 141 milhões de tokens H. Na BSC, explorou o ProxyAdmin — o contrato administrador que decide qual código um contrato atualizável executa — para ativar a capacidade de cunhar novos tokens do nada. É aqui que está a cifra que deve ser lida com cuidado: foram autorizados 300 milhões de H para mint, dos quais cerca de 200 milhões foram executados na fase inicial. A oferta repentina, despejada na Uniswap e em outras DEX (exchanges descentralizadas), derrubou o preço.

Os três vetores compartilham a mesma origem e, por isso, puderam ser disparados simultaneamente: as chaves que autorizavam cada um — assinar na bridge, administrar o proxy, movimentar a hot wallet — estavam ao alcance do mesmo dispositivo comprometido. Um invasor com um único ponto de controle não precisou escolher; executou as três rotas em paralelo no mesmo dia. Essa simultaneidade é a assinatura de um comprometimento de dispositivo, não de um exploit pontual: quando a origem das assinaturas cai, caem todas as superfícies que essas assinaturas governam.

Por que um multisig 3-de-6 não foi suficiente?

Esta é a pergunta que importa, e a resposta é contraintuitiva. Um multisig 3-de-6 soa robusto: nenhum signatário pode mover fundos sozinho, e falhas em várias chaves são toleradas. No papel, há seis pessoas ou dispositivos distribuindo o poder.

O esquema só cumpre sua promessa se essas seis chaves estiverem realmente separadas: pessoas diferentes, dispositivos diferentes, idealmente localizações físicas diferentes e, para as mais sensíveis, hardware air-gapped (isolado da rede). A segurança de um limite criptográfico depende de que o comprometimento de uma chave não aproxime o invasor das demais. Se três chaves — ou mais, contando backups — convivem no mesmo notebook, o invasor que assume o controle desse notebook não precisa quebrar o esquema: ele o satisfaz. Reúne o quórum em um único movimento. No Humanity, segundo o relatório forense da equipe, até sete chaves de signatário — somando as dos dois multisig e seus backups — estavam ao alcance de um único dispositivo: no papel, um 3-de-6 e um 3-de-5; na prática, um 1-de-1, pois bastava comprometer aquela máquina para ter todas.

Dito de outro modo: distribuição física não é o mesmo que limite criptográfico. A redundância numérica do 3-de-6 era fictícia porque a redundância física não existia. O multisig estava bem configurado no contrato e mal implantado no mundo real. É exatamente a falha que separa a teoria da gestão de chaves de sua prática, e a razão pela qual um leitor iniciante deve entender primeiro o que é e o que não garante um multisig antes de confiar fundos a ele.

Como o invasor entrou e qual rastro aponta para a Coreia do Norte?

O ponto de entrada não foi criptográfico, foi social. Em 5 de junho, três dias antes da drenagem, chegou um e-mail de spear-phishing imitando a Bithumb, uma das grandes exchanges coreanas. Chong Yee Wai, diretor da Humanity Foundation, abriu a isca e o dispositivo foi infectado com um malware assinado com um certificado da Hancom — um provedor de software sul-coreano —, uma técnica de assinatura roubada que confere aparência de legitimidade ao executável.

Esse conjunto de indicadores — spear-phishing personificando uma exchange, malware com certificado coreano comprometido, alvo no ecossistema asiático — coincide com o modus operandi de atores patrocinados pela Coreia do Norte (DPRK). A empresa de segurança Quantstamp, após analisar o incidente, encontrou padrões característicos de intrusões da DPRK, mas não emitiu uma atribuição definitiva nem nomeou um subgrupo específico. É uma nuance importante: há um rastro, mas não há confirmação nominal. O padrão DPRK já está amplamente documentado em outros hacks de 2026, e o cobrimos em detalhes na análise do rastro de 577 milhões através de Drift e Kelp; aqui basta situar o Humanity dentro dessa série sem reproduzir o dossiê.

Foi um rug pull (fraude interna) ou um hack externo?

Durante as primeiras horas após o roubo ao Humanity, circulou a suspeita de que o incidente pudesse ter sido forjado internamente. O investigador on-chain ZachXBT classificou-o em 9 de junho como "possibly staged" — possivelmente encenado —, uma hipótese razoável quando o dinheiro sai de carteiras da própria equipe. Pouco depois, ele revisou essa leitura.

Sua conclusão final foi mais sutil do que um simples "foi um hack" ou "foi um rug pull": a atividade do market maker (o formador de mercado que provê liquidez ao token) e o comprometimento da chave são eventos independentes. Ou seja, o que parecia coordenação interna era o ruído de duas coisas acontecendo ao mesmo tempo sem estarem conectadas. ZachXBT não afirmou ter confirmado uma exfiltração externa com prova definitiva; ele descartou o relato de montagem interna como explicação necessária. O arco completo — suspeita, revisão, separação dos dois fatos — faz parte do valor do caso: mostra como é difícil distinguir um roubo de uma fraude quando os fundos saem de carteiras próprias.

O que diz a cronologia do ataque?

A sequência datada deixa claro que o roubo não foi um instante, mas uma operação com dias de preparação e um desdobramento que continua aberto.

Quais lições de gestão de chaves o caso deixa?

Além dos nomes e números, o Humanity é um manual do que não fazer ao custodiar chaves institucionais. As três lições operacionais:

• Separação física real, não nominal. As assinaturas de um multisig devem residir em dispositivos diferentes, nas mãos de pessoas diferentes. Co-localizar várias chaves — ou seus backups — em uma única máquina transforma um 3-de-6 em um 1-de-1 disfarçado. O número do limite não significa nada se a distribuição física não o sustentar.
• Air-gap para as chaves que movimentam o tesouro. As assinaturas com poder sobre bridges, mint e ProxyAdmin nunca deveriam tocar um notebook conectado ao e-mail. O dispositivo que abre um PDF da Bithumb não pode ser o mesmo que guarda a chave da ponte.
• Separação de ambientes e timelock em contratos críticos. O ProxyAdmin que permite atualizar um contrato ou cunhar tokens deveria estar atrás de um timelock (atraso obrigatório entre ordem e execução) que dê tempo para detectar e reverter uma ordem maliciosa. Sem essa pausa, reunir o quórum equivale a executar instantaneamente, como ocorreu aqui.

Este último ponto se conecta a um precedente direto de 2026: o hack do Drift Protocol em abril, onde um multisig também comprometido permitiu que atores com rastro DPRK executassem ações sem freio. O padrão se repete: não se quebra a criptografia, quebra-se o processo humano ao redor dela. Para o leitor individual, a versão doméstica desse mesmo erro é exatamente a que descrevemos em como as pessoas perdem suas criptomoedas: a deriva operacional, não a falha do protocolo.

A diferença entre os protocolos que sobrevivem a um comprometimento de chaves e os que não sobrevivem costuma se reduzir a se o contrato administrador possuía um timelock. Com um atraso obrigatório entre a ordem de atualização e sua execução, a equipe do Humanity teria tido uma janela — horas, não segundos — para detectar a atualização maliciosa da bridge e revogá-la antes que qualquer valor fosse drenado. Sem timelock, reunir três assinaturas e esvaziar a ponte são o mesmo ato. O ProxyAdmin da BSC que continua comprometido até hoje é a outra face do mesmo problema: um administrador sem freio temporal é uma chave-mestra permanente e, enquanto o invasor a conservar, o risco de nova cunhagem não desaparece. O custo de adicionar esse timelock é de minutos de fricção operacional; o custo de não tê-lo, neste caso, foi de dezenas de milhões.

Qual é o estado do projeto e da recuperação?

Em 17 de junho, a situação permanecia aberta em um ponto crítico: o ProxyAdmin da BSC continuava sob controle do invasor, o que mantém viva a capacidade de cunhar mais tokens. Dos 300 milhões de H autorizados para mint, cerca de 200 milhões haviam sido executados; a margem restante é o risco que continua pairando sobre a rede BSC.

Do lado da resposta, em 16 de junho, a equipe anunciou seu plano de recuperação: um airdrop 1:1 (distribuição gratuita de tokens aos afetados) de um novo token H, desta vez como ERC-20 no Ethereum, tomando como referência um snapshot (captura do estado da rede) anterior ao ataque. Não se trata de um "H2" nem de uma proporção estranha — é uma substituição um para um do token afetado. A eficácia desse plano depende de fechar antes o ProxyAdmin comprometido; caso contrário, o novo token herda o mesmo risco de oferta descontrolada. Em 17 de junho, a própria equipe classificava o H da BSC como "permanentemente comprometido" e não havia recuperado o controle do ProxyAdmin.

O que muda na gestão de chaves após o caso Humanity?

O Humanity Protocol não foi hackeado por ter um contrato ruim ou um multisig ruim. Foi hackeado por implantar um bom multisig de forma que sua garantia era inexistente. A lição não é "use multisig" — eles já usavam —, mas que o esquema só vale o que vale a separação física e operacional de suas chaves. Três assinaturas de seis não protegem nada se três assinaturas vivem no mesmo disco rígido.

Para 2026, este já é o padrão dominante dos grandes roubos: engenharia social contra uma pessoa com acesso, não exploits contra o código. Três dos maiores incidentes do ano — Drift e Kelp em abril, Humanity em junho — compartilham o mesmo esqueleto: rastro de atores DPRK, entrada por comprometimento humano ou social, e um mecanismo de controle (multisig ou administrador de proxy) que é satisfeito em vez de quebrado. O perímetro defensável mudou do contrato para o notebook. Quem custodia fundos — instituição ou indivíduo — defende hoje um dispositivo e um processo, não apenas uma linha de Solidity.

A pergunta prática para qualquer equipe que leia isto não é "temos multisig?", mas sim três perguntas mais incômodas: onde vivem fisicamente nossas chaves, incluindo os backups? Quantas delas poderiam ser reunidas por quem comprometer um único dispositivo? E quanto tempo um timelock nos daria para reverter uma ordem maliciosa? O Humanity falhou nas três. Respondê-las bem não é glamoroso nem aparece no roadmap, mas é a diferença entre um susto e uma manchete de 36 milhões.

Fontes e links: Rekt.news — Humanity Protocol post-mortem (16-jun-2026) · Halborn — análise técnica do hack · crypto.news — análise de ZachXBT · CryptoBriefing — padrões DPRK (Quantstamp) · CryptoTimes — plano de recuperação e airdrop · CoinDesk — o multisig que vivia em um único notebook