Voltar

2026/11/03

Como uma única assinatura continuou a esvaziar a hot wallet da Binance: a delegação EIP-7702 por trás do ataque

50 autorizações EIP-7702 pré-assinadas, uma correspondência e uma delegação que sobreviveu à carteira vazia. Como funcionou e o que monitorar.

No nosso primeiro artigo sobre o ataque à Binance, vimos como o ataque terá começado: um laptop de DevOps comprometido e atacantes que chegaram aos sistemas que aprovam ações sensíveis. A análise on-chain da empresa de segurança Blockaid mostrou entretanto como funcionou a fase final na Ethereum. O ataque usou a EIP-7702, uma funcionalidade adicionada à Ethereum em maio de 2025, e revela um risco que muitos operadores de hot wallets ainda não consideraram.

Em resumo: uma única autorização assinada transformou a maior hot wallet Ethereum da Binance numa conta que o atacante podia controlar. Esse controlo não terminou quando a carteira ficou vazia, e também não teria terminado com uma rotação de chaves.

Pontos principais

  • O atacante colocou 50 autorizações EIP-7702 pré-assinadas, cobrindo 50 nonces consecutivos, numa única transação; exatamente uma correspondeu e entregou a execução da carteira ao contrato do atacante.
  • Uma delegação EIP-7702 mantém-se até a conta a substituir ou limpar. Depósitos que chegaram depois do primeiro esvaziamento, mais de 200 milhões de dólares num dos momentos, foram levados sem qualquer nova assinatura.
  • Rodar a chave privada não remove uma delegação, porque esta pertence ao endereço. Só uma revogação explícita a elimina.
  • Continua por esclarecer como o atacante obteve 50 assinaturas válidas. A Binance afirma não ter encontrado indícios de fuga de chave privada.
  • Os operadores de hot wallets devem monitorar o estado de delegação, recusar assinar autorizações que não pretendiam e incluir a revogação explícita nos seus runbooks de resposta a incidentes.

Uma breve introdução à EIP-7702

A EIP-7702 permite que uma conta Ethereum comum (uma externally owned account, ou EOA) delegue a sua execução num smart contract. O titular da conta assina uma autorização que indica o endereço de um contrato, a chain e o nonce atual da conta. Depois de processada uma transação com essa autorização, as chamadas à conta executam o código do contrato, como se a conta fosse uma smart contract wallet. A funcionalidade existe por razões legítimas, como agrupar transações e pagar taxas em nome de um utilizador.

Três detalhes da especificação são importantes neste incidente:

  • As autorizações circulam num novo tipo de transação, o tipo 4 (0x04), que pode transportar uma lista delas. Qualquer pessoa pode submeter a transação; a autorização só precisa de uma assinatura válida da conta.
  • Cada autorização só é válida se o seu nonce for igual ao nonce atual da conta. Se não corresponder, essa autorização é ignorada e a transação continua com a seguinte.
  • A delegação é persistente. Mantém-se até a conta assinar uma nova autorização que aponte para outro lado, ou uma que aponte para o endereço zero, o que a elimina.

Como a carteira Binance 14 foi tomada

Uma hot wallet de uma exchange movimentada envia transações constantemente, por isso o seu nonce está sempre a mudar. Um atacante que prepare antecipadamente uma autorização assinada não pode saber qual será o nonce atual quando a transação for processada. Segundo a análise da Blockaid, o atacante resolveu isto assinando um intervalo em vez de um único valor.

Hora (UTC, 29 de outubro)O que aconteceu
15:59O atacante implementa um contrato “sweeper”. Não está verificado e só o endereço operador do atacante o pode chamar.
20:20:59Uma única transação do tipo 4 transporta 50 autorizações EIP-7702, todas assinadas com a chave da hot wallet Binance 14, para 50 nonces consecutivos. Exatamente uma corresponde ao nonce atual da carteira, que passa a estar delegada no sweeper.
20:24:23Uma única chamada ao sweeper retira da carteira cerca de 167 464 ETH, 1,615 mil milhões de USDT e dezenas de outros tokens, deixando 1 ETH para taxas.
20:41Ainda delegada, a carteira é usada para retirar cerca de 823 milhões de USDC de uma smart account separada controlada pela Binance 14.
21:04 a 23:56A carteira é esvaziada mais quatro vezes à medida que chegam novos fundos. Só às 21:44, mais de 200 milhões de dólares em novos depósitos são levados sem nenhuma nova assinatura.
00:10 (30 de outubro)A delegação é revogada, segundo a cronologia da Hypernative.

O passo com USDC mostra um segundo efeito. Uma conta delegada mantém todas as funções que tem noutros contratos: proprietário, executor, spender autorizado. Quem controla a sua execução pode usar todas elas.

Porque é que uma carteira vazia continuava perigosa

Depois de um roubo, as suposições naturais são que uma carteira vazia já não tem nada a perder e que uma nova chave acaba com o acesso do atacante. Com a EIP-7702, ambas estão erradas. A delegação está associada ao endereço, não ao saldo nem a uma cópia específica da chave. Enquanto estiver ativa, tudo o que for enviado para o endereço pode ser retirado pelo contrato delegado, e o atacante não precisa de mais nenhuma assinatura.

Foi o que aconteceu aqui. Continuaram a chegar fundos à Binance 14 depois do primeiro esvaziamento, e foram retirados novamente. Rodar a chave não teria ajudado: como a Blockaid salienta, eliminar a delegação exige uma nova autorização da mesma conta, a apontar para o endereço zero. Até essa revogação ser processada, o endereço deve ser tratado como controlado pelo atacante.

Dica: Num incidente, revogue primeiro e só depois rode as chaves e reabasteça. Pare todos os processos automáticos que enviam fundos para o endereço afetado até confirmar que a delegação desapareceu.

O que continua por esclarecer

As 50 autorizações tinham todas assinaturas válidas da chave da Binance 14. Há duas explicações gerais, e as provas públicas ainda não permitem escolher entre elas:

  • A chave foi comprometida, e o atacante assinou as autorizações diretamente.
  • A infraestrutura de assinatura foi abusada: o atacante conseguiu que os próprios sistemas de assinatura da Binance assinassem conteúdos à sua escolha, sem nunca extrair a chave.

A Binance afirmou não ter encontrado indícios de fuga da chave privada da carteira, e a investigação continua. O CEO da Blockaid disse à Cointelegraph que a atividade parece um comprometimento da infraestrutura de assinatura e não uma fuga de chave, mas trata-se de uma avaliação externa preliminar. Até a Binance publicar o seu post-mortem, consideramos a questão em aberto.

O que fazer se opera hot wallets

1. Monitore o estado de delegação

Uma conta delegada tem código. Na EIP-7702, o seu código é o indicador de delegação 0xef0100 seguido do endereço de 20 bytes do contrato em que delega. Uma EOA comum não tem código nenhum. Pode verificar qualquer endereço com uma chamada JSON-RPC padrão:

curl -s -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYOUR_HOT_WALLET","latest"]}' \
  https://YOUR_RPC_ENDPOINT

Um resultado 0x significa que não há delegação. Um resultado que comece por 0xef0100 significa que o endereço está delegado. Verifique isto para cada hot wallet em cada bloco ou em intervalos curtos, e alerte de imediato sobre qualquer alteração que não tenha planeado.

2. Vigie as transações do tipo 4 que envolvam os seus endereços

A transação que delega a sua carteira não tem de vir da sua carteira. Qualquer pessoa a pode submeter, desde que contenha uma autorização válida assinada pela sua chave. Monitore as transações do tipo 4 cuja lista de autorizações contenha uma assinatura de um dos seus endereços, e não apenas as transações enviadas a partir deles.

3. Mantenha um inventário de delegações

Para cada endereço que opera, registe se deve sequer estar delegado e, se sim, em que contrato auditado. Qualquer delegação fora dessa lista é um incidente. Se não usa a EIP-7702, o estado esperado de todas as hot wallets é simples: nenhum código.

4. Recuse autorizações inesperadas no signatário

Uma autorização EIP-7702 tem o seu próprio formato de assinatura: o hash do byte 0x05 seguido do chain ID, endereço do contrato e nonce codificados. Os serviços de assinatura e as políticas de HSM conseguem reconhecer este formato. Se não usa delegações, bloqueie totalmente estes conteúdos; se usa, permita apenas endereços de contratos conhecidos. Note também que uma autorização com chain ID 0 é válida em todas as chains.

5. Inclua a revogação explícita no runbook de resposta a incidentes

Documente como revogar uma delegação para cada carteira: quem assina a autorização para o endereço zero, a partir de que sistema, e como confirma que teve efeito (o código do endereço volta a ser 0x). Inclua a interrupção das transferências de entrada para o endereço afetado e pratique o procedimento antes de precisar dele.

Dica: A mesma ideia aplica-se fora do mundo cripto. Qualquer concessão que sobreviva à credencial que a criou, como um refresh token OAuth, uma função delegada na cloud ou um token de CI/CD de longa duração, precisa de um passo próprio de revogação explícita na resposta a incidentes.

Como a LOGIQ pode ajudar

A LOGIQ ajuda as organizações a rever quem e o quê pode agir com autoridade nos seus servidores Linux, contas cloud e pipelines, e a criar monitorização e passos de resposta a incidentes que cubram o acesso delegado, e não apenas palavras-passe e chaves. Se quiser uma segunda opinião sobre os seus próprios controlos, leia o nosso primeiro artigo sobre o ataque acima ou contacte-nos através do nosso website.

Fontes