Hack da Liquid: anatomia do exploit de US$ 320 milhões e por que a comunidade fala em Lazarus

O ataque de 6 de setembro à Liquid Network não envolveu chave roubada, servidor invadido nem engenharia social. Foi um bug de consenso: o software que define o que é um L-BTC válido aceitou uma transação que inflou a oferta em quase 4.000 unidades. A partir daí, o resto foi burocracia. Este artigo reconstrói o exploit em detalhe, mostra o que o atacante fez nos três dias anteriores, analisa as mensagens trocadas na blockchain e discute a pergunta que a comunidade não para de fazer: white hat de verdade avisa antes. Quem ataca e só depois pede recompensa?

Se você quer só o resumo do caso, leia primeiro o que aconteceu na Liquid, em linguagem simples. Aqui a conversa é técnica.

1. Como a Liquid esconde valores: Confidential Transactions

Diferente do Bitcoin, a Liquid não mostra o valor das transações na blockchain. Ela usa Confidential Transactions (CT), proposta por Gregory Maxwell em 2015. Cada saída carrega um Pedersen commitment, um número que “sela” o valor sem revelá-lo, e uma rangeproof: uma prova de que o valor selado está dentro de um intervalo válido (não é negativo, não estoura o máximo). Sem a rangeproof, alguém poderia criar uma saída de valor negativo e, na soma, “criar” moedas.

A Liquid também esconde qual ativo está sendo movido (L-BTC, USDT, DePix ou qualquer outro token emitido). Isso significa que a validação precisa checar duas coisas ao mesmo tempo: o valor está no intervalo e o ativo é o que se diz ser. As rangeproofs na Liquid são, por padrão, de 4.174 bytes. Guarde esse número.

2. O bug: um cache que esqueceu o contexto

Verificar rangeproofs é caro em CPU. Para não repetir o trabalho a cada bloco, o Elements mantém um cache de provas já verificadas, como o Bitcoin Core faz com assinaturas. A questão é: qual é a chave desse cache?

Até a correção, a chave usava apenas a prova e o commitment de valor. Faltavam dois elementos: o ativo e o script de saída (o “endereço”). Na prática, isso dizia ao nó: “se você já viu esta prova com este commitment, aceite-a de novo, não importa para qual ativo ou para quem”. A correção, escrita em 3 de agosto e mesclada nos branches master e elements-23.x entre 1º e 3 de setembro, adicionou o ativo e o script à chave. Simples, curta e, infelizmente, pública sem uma versão lançada.

3. A preparação: três dias de ensaio

A reconstrução on-chain da Bitquery mostra um atacante metódico. Nada foi improvisado.

Dois detalhes técnicos chamam atenção. Primeiro, a rangeproof de 4.234 bytes na transação final: são 60 bytes a mais que o normal, o que sugere uma prova construída à mão para colidir com a chave do cache. Segundo, as transações do atacante no Bitcoin usam anti-fee-sniping (locktime um pouco abaixo da altura atual), um comportamento padrão da carteira do Bitcoin Core. Não é uma carteira exótica: é alguém que roda software de referência e sabe o que está fazendo.

4. Por que a federação assinou

A Liquid é governada por uma federação de 15 functionaries em multisig 11 de 15, com módulos de hardware (HSM) que só assinam peg-outs válidos segundo as regras da sidechain. Aqui está o ponto: “válido segundo as regras” é decidido pelo Elements. Se o Elements aceita a transação de cunhagem, o L-BTC resultante é, para o HSM, tão legítimo quanto qualquer outro. Os 11 assinantes não verificam o lastro; verificam o protocolo. E o protocolo estava errado.

Isso explica também por que a SideSwap não é a vilã da história. Ela é um serviço autorizado (whitelisted) de peg-out. Recebeu L-BTC, o nó dela disse que era válido, ela pediu o saque, cobrou 0,1% e repassou. A SideSwap confirmou que sua chave não foi comprometida. O problema era anterior a ela.

5. A negociação por OP_RETURN

O que veio depois é inédito nessa escala: uma negociação de US$ 320 milhões conduzida inteiramente dentro de transações do Bitcoin, usando o campo OP_RETURN para texto e PGP para as partes sigilosas. Todas as mensagens são públicas e verificáveis. A assinatura da Blockstream bate com a chave de segurança publicada no site da empresa (fingerprint terminando em 6844 A2D6).

Repare na palavra “most” (a maior parte) na mensagem das 02h20. Desde o primeiro contato, o atacante já sinalizava que não devolveria tudo. Nenhum acordo de recompensa foi tornado público. Circulou a informação de que o grupo teria pedido 20%; ficou com 15%. A Blockstream não confirmou nem negou.

Repare também no “latest commit”. O atacante sabia que a correção estava no repositório e que não havia release. Ele estava, de fato, monitorando o GitHub do Elements. Isso leva à hipótese mais provável sobre como o bug foi encontrado: lendo o diff da correção, não auditando o código do zero. Um commit que “adiciona parâmetros faltantes à chave de cache de rangeproof” é um mapa do tesouro para quem entende de CT. Entre o merge (1º/09) e o ataque (6/09) passaram cinco dias, e a preparação começou em 4/09.

6. White hat, black hat ou Lazarus?

Aqui entra a discussão que domina a comunidade. Vamos separar os argumentos.

O que um white hat faria

O protocolo aceito de divulgação responsável é: encontrar a falha, reportar em sigilo, dar prazo para a correção, e receber recompensa (bug bounty) depois. Se precisa provar que a falha é explorável, faz com valor simbólico. A Immunefi e programas semelhantes pagam milhões por bugs de consenso justamente para que isso aconteça. Ninguém drena 95% da reserva para “demonstrar” um bug.

O que aconteceu aqui

• Três dias de ensaio silencioso, sem qualquer contato com a Blockstream.
• Drenagem de 3.996 BTC antes de qualquer mensagem.
• Contato só depois do dinheiro estar em carteira própria.
• Condição imposta (“corrija primeiro”) que, na prática, garantiu que ninguém mais pudesse repetir o golpe enquanto o atacante segurava o dinheiro.
• Retenção de 598,5 BTC (US$ 47 milhões) sem acordo público.

É isso que sustenta a leitura de extorsão com roupagem de white hat: o “bounty” foi definido unilateralmente por quem tinha o dinheiro na mão. Como escreveu Alena Vránová, da Gart: explorar, levar 4 mil BTC e exigir correção como condição é extorsão, independentemente do nome que se dê.

A tese do Lazarus

Parte da comunidade levantou o nome do Lazarus Group, a unidade de hackers ligada ao governo norte-coreano. O raciocínio é: um white hat avisaria e ganharia a recompensa pelas vias normais; quem ataca primeiro e negocia depois é criminoso profissional, e o criminoso profissional mais ativo em cripto hoje é o Lazarus, responsável por Ronin (US$ 625 milhões, 2022), Harmony (US$ 100 milhões, 2022) e Bybit (US$ 1,5 bilhão, fevereiro de 2025, confirmado pelo FBI). A sofisticação do ataque, o uso de Bitcoin Core e a paciência de três dias de preparação são compatíveis com um grupo estatal.

Os argumentos contra são fortes, porém:

• Lazarus não devolve. Em nenhum caso documentado o grupo retornou fundos. O padrão é lavar imediatamente via mixers, pontes e corretoras descentralizadas. A devolução de 85% em 24 horas é o oposto do modus operandi.
• Lazarus não conversa. O grupo não abre diálogo com a vítima, não assina mensagens e não pede confirmação de endereço “para não errar”. O comportamento aqui foi de quem queria ser visto negociando.
• O vetor é diferente. Os grandes ataques do Lazarus exploram pessoas e infraestrutura: engenharia social, dispositivos de desenvolvedores comprometidos, front-ends adulterados. Explorar um bug de consenso em CT é trabalho de criptógrafo, não de operação de inteligência.
• Nenhuma empresa de análise on-chain (Chainalysis, Elliptic, TRM, ZachXBT) atribuiu o ataque ao Lazarus até a publicação deste texto.

A leitura mais honesta é a de Charles Guillemet, CTO da Ledger: não parecem white hats, e não parecem os criminosos de sempre. O próprio Guillemet suavizou o tom depois que a negociação começou, observando que grupos criminosos não costumam se esforçar para abrir canal direto com a vítima. O perfil mais consistente com as evidências é o de um grey hat com conhecimento profundo de Elements: alguém que viu a correção no GitHub, calculou que a janela até o release era curta, e decidiu que US$ 47 milhões “de recompensa” era um preço justo por não ter sido o Lazarus.

7. O que a Blockstream errou

Dizer que “foi só um bug” seria generoso. Três decisões de processo abriram a janela:

1. Correção de bug de consenso publicada sem release. No Bitcoin Core, correções de inflação são tratadas como segredo até a versão estar pronta e distribuída (foi assim no CVE-2018-17144). No Elements, o diff ficou 5 dias exposto no GitHub com a rede inteira vulnerável.
2. Sem limite de velocidade no peg-out. Um peg-out de 95% da reserva em uma única transação passou sem alarme, sem atraso, sem aprovação humana. Uma trava de valor por bloco teria transformado US$ 320 milhões em um incidente de dezenas de milhares.
3. Sem monitoramento de oferta. A cunhagem de 3.996 L-BTC deveria ter disparado um alerta imediato de discrepância entre L-BTC circulante e BTC na federação. O tempo entre cunhagem e saque foi de 35 minutos.

Nicolas Burtey, CEO da Galoy, foi mais direto: o incidente “matou a Liquid”, com ou sem devolução. Talvez seja exagero. Mas a Liquid vendia exatamente duas coisas, confiança na federação e confiança no código, e as duas falharam ao mesmo tempo.

Perguntas Frequentes

Leia também: Hack da Liquid Network: 4.000 BTC somem em 20 minutos (resumo em linguagem simples)

Leia também: O que é sidechain: de Liquid a Polygon, e a lição do The DAO