Jeff Bruchado
Voltar para o Blog

Hack da Binance em 2026: Como US$ 6,3 Bilhões Saíram em 20 Minutos Sem Vazar Chave

Olá HaWkers, no dia 29 de outubro de 2026 a Binance perdeu cerca de US$ 6,3 bilhões, no que já é tratado como o maior roubo de criptomoedas da história. A marca anterior era de US$ 1,5 bilhão, levados da Bybit em fevereiro de 2025. A TRM Labs calcula que quase tudo saiu em cerca de 20 minutos, por dez blockchains diferentes. E o detalhe mais incômodo para quem programa: a Binance diz que não encontrou nenhuma evidência de chave privada vazada.

Se a chave não vazou, como o dinheiro saiu? Essa é a pergunta que interessa mesmo para quem nunca tocou em cripto, porque a resposta provável vale para qualquer sistema que mova dinheiro, aprove reembolso ou faça deploy em produção. Neste artigo você vai ver o que está confirmado, o que ainda é hipótese, como funciona o EIP-7702 e três controles em código que dá para adaptar no seu backend.

O Que Está Confirmado e o Que Ainda É Hipótese

Antes de qualquer lição, uma ressalva: a investigação continua aberta e a Binance prometeu publicar os detalhes técnicos só depois de concluí-la. Boa parte do que circula é reconstrução de empresas de análise on-chain, não relatório oficial. Separar as duas coisas evita tirar conclusão errada.

Afirmação Quem diz Situação
Cerca de US$ 6,3 bilhões roubados Binance Estimativa; pode mudar
US$ 6,36 bilhões em dez blockchains TRM Labs Estimativa independente
Cerca de US$ 5,9 bilhões no momento do roubo Chainalysis Estimativa revisada
Laptop de engenheiro de DevOps comprometido Binance Hipótese inicial; depois vieram "pontos adicionais de invasão"
Nenhuma evidência de chave privada vazada Binance Declaração da empresa, contestada por Mark Karpeles, ex-Mt. Gox
Autoria do grupo norte-coreano TraderTraitor FBI, TRM Labs, Chainalysis Atribuição do FBI em 31 de outubro
O sistema de assinatura foi induzido a assinar TRM Labs Avaliação de analistas

A diferença entre os valores vem do método: cotação usada, momento do cálculo e o que entra na conta. O título que puxou a discussão no Hacker News falava em US$ 5,6 bilhões, e o painel da Arkham chegou a mostrar mais de US$ 5,7 bilhões nas carteiras do atacante.

Também vale registrar o que a Binance afirma sobre clientes: o ataque teria atingido hot wallets da própria empresa, ou seja, carteiras conectadas usadas para operar saques, e o prejuízo sai do caixa dela. A empresa reservou cerca de US$ 6,34 bilhões, incluindo o fundo SAFU de US$ 1 bilhão, e disse em 31 de outubro já ter reposto 90% dos ativos.

A Linha do Tempo do Ataque

A reconstrução da TRM Labs mostra uma operação ensaiada, não um golpe de oportunidade. A carteira do operador recebeu três pequenas retiradas da Tornado Cash a partir de 28 de outubro, pelo menos 36 horas antes do roubo. Na madrugada do dia 29, o código de ataque foi publicado e testado em duas carteiras, com um ensaio final numa terceira. Cerca de quatro horas depois, o mesmo código foi usado contra a Binance.

Horário (UTC) O que aconteceu
20:05 Começa o saque no XRP Ledger; cinco carteiras esvaziadas até o saldo mínimo
20:20 Carteira quente de Bitcoin envia 18.270 BTC ao atacante
20:24 Transação principal no Ethereum, segundo a linha do tempo pública do caso
Cerca de 21:01 Tether começa a congelar carteiras; a Circle vem três minutos depois
00:10 (dia 30) Binance remove as permissões do atacante na hot wallet

Na rede Tron, 612,7 milhões de USDT saíram em dois minutos. No Ethereum, uma única varredura levou 167.464 ETH e 1,615 bilhão de USDT.

Repare no intervalo entre a primeira transação e a remoção do acesso: cerca de quatro horas. Foi nesse período que o atacante seguiu limpando a carteira conforme entrava dinheiro novo. Em incidente, o tempo até revogar costuma custar mais do que o tempo até detectar.

Os congelamentos salvaram parte do valor. Tether e Circle congelaram mais de US$ 2,3 bilhões em stablecoins, e as estimativas de total congelado ficam entre US$ 2,7 bilhões e US$ 3 bilhões. O Bitcoin não tem esse botão: não existe emissor capaz de congelar os US$ 1,5 bilhão em BTC.

O Que É o EIP-7702 e Por Que Ele Apareceu Aqui

O EIP-7702 entrou no Ethereum com a atualização Pectra, em maio de 2025. Ele permite que uma conta comum, controlada por chave privada, delegue seu comportamento para o código de um smart contract. A ideia é boa: dá recursos de carteira inteligente, como lotes de transações e pagamento de taxa por terceiros, sem trocar de endereço.

Na prática, a conta assina uma autorização com três campos: chain_id, endereço do contrato e nonce. Essa autorização vai numa transação do tipo 0x04, e a rede grava no endereço da conta o prefixo 0xef0100 seguido do endereço do contrato. Daí em diante, qualquer chamada para aquela conta executa o código do contrato. E isso persiste: a delegação fica ativa até outra autorização trocá-la ou limpá-la.

Segundo a TRM Labs, foi aqui que o atacante agiu no Ethereum. Uma transação carregou 50 autorizações pré-assinadas, todas apontando a hot wallet para um contrato de varredura que só ele podia chamar. Por que 50? Porque o nonce da autorização precisa ser igual ao nonce atual da conta, e uma carteira de exchange movimentada avança esse número o tempo todo. Com 50 valores consecutivos assinados, ao menos um estaria válido na hora da execução.

Depois da delegação, o atacante não precisava mais de assinatura nova da Binance. A carteira virou uma máquina de varredura, usada mais seis vezes em cerca de 3,5 horas.

O EIP-7702 não tem um bug conhecido envolvido neste caso. Richard Teng, co-CEO da Binance, disse que a delegação contornou controles normais de aprovação, mas a falha mais provável está em quem podia pedir assinaturas, não no padrão. A especificação já avisa que um delegado malicioso pode assumir "quase controle total" da conta e que carteiras não deveriam deixar aplicações pedirem esse tipo de assinatura.

Dá para checar se um endereço está delegado com uma chamada comum de RPC:

// Verifica se um endereço Ethereum tem delegação EIP-7702 ativa
// Requer Node.js 18+ (fetch nativo)
const RPC_URL = 'https://ethereum-rpc.publicnode.com';
const DELEGATION_PREFIX = '0xef0100';

async function getDelegation(address) {
  const response = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 1,
      method: 'eth_getCode',
      params: [address, 'latest'],
    }),
  });

  const { result, error } = await response.json();
  if (error) throw new Error(error.message);

  const code = result.toLowerCase();

  // Conta delegada tem exatamente 23 bytes: prefixo (3) + endereço (20)
  const isDelegated = code.startsWith(DELEGATION_PREFIX) && code.length === 48;

  return isDelegated ? `0x${code.slice(DELEGATION_PREFIX.length)}` : null;
}

// Rode isso em loop nas suas carteiras operacionais:
// um retorno inesperado aqui deve abrir incidente na hora
const delegate = await getDelegation(
  '0x0000000000000000000000000000000000000000'
);
console.log(delegate ?? 'Sem delegação ativa');

A Lição Real: Assinar Não É Autorizar

Se a Binance estiver certa sobre as chaves, o atacante não roubou o cofre: convenceu o cofre a abrir. A TRM Labs nota que as outras nove redes, com tipos de chave e esquemas de assinatura diferentes, soltaram fundos por transferências comuns e assinadas. A conclusão dela é que o atacante provavelmente ganhou a capacidade de fazer o sistema de assinatura assinar o que quisesse. A Bybit caiu por um caminho parecido, e o padrão vem de longe: comprometa quem tem acesso privilegiado e chegue ao sistema que move dinheiro.

Troque "hot wallet" por "serviço de pagamentos", "API de reembolso" ou "pipeline de deploy". O problema é igual: um serviço interno que confia em qualquer requisição bem formada vinda de dentro da rede. Confiança automática também é o que torna perigoso o install de todo dia, como mostrou o caso GemStuffer no RubyGems: o que chega por um canal conhecido entra sem conferência.

O analista Kok Tin Gan, da NyxLab, descreveu o caso como aparentando uma assinatura que gerou um token de acesso total e sem expiração, avisando que trabalhava com evidência pública incompleta. Verdadeira ou não neste caso, é a imagem certa do que não ter em produção.

Três Controles Para Aplicar no Seu Backend

A lista abaixo parte do que a TRM Labs e especialistas ouvidos pela imprensa recomendaram depois do ataque. O código é um ponto de partida, não um sistema pronto.

Controle 1: Uma Política de Assinatura Fora do Serviço Que Pede

O primeiro controle é um motor de política que recebe o pedido e decide, rodando separado do serviço que pediu. Se ele viver no mesmo processo, quem invadir o processo desliga a política junto.

// Política de assinatura: nega por padrão e explica cada recusa
type SignRequest = {
  kind: 'transfer' | 'contract_call' | 'set_code';
  chain: string;
  to: string;
  valueUsd: number;
  requestedBy: string;
  approvals: string[];
};

type Decision = { allowed: boolean; reason: string };

const LIMIT_WITHOUT_APPROVAL_USD = 10_000;
const REQUIRED_APPROVERS = 2;

function evaluate(request: SignRequest, allowlist: Set<string>): Decision {
  // Delegação nunca é rotina em carteira operacional
  if (request.kind === 'set_code') {
    return { allowed: false, reason: 'delegação EIP-7702 bloqueada' };
  }

  if (!allowlist.has(`${request.chain}:${request.to.toLowerCase()}`)) {
    return { allowed: false, reason: 'destino fora da lista permitida' };
  }

  if (request.valueUsd <= LIMIT_WITHOUT_APPROVAL_USD) {
    return { allowed: true, reason: 'dentro do limite automático' };
  }

  // Quem pediu não pode aprovar o próprio pedido
  const independent = new Set(
    request.approvals.filter(person => person !== request.requestedBy)
  );

  return independent.size >= REQUIRED_APPROVERS
    ? { allowed: true, reason: 'aprovações independentes suficientes' }
    : { allowed: false, reason: 'faltam aprovações independentes' };
}

Os valores acima são exemplos; ajuste ao seu volume. A TRM Labs recomenda rejeitar autorizações inesperadas de EIP-7702 e tratar pedidos anômalos, como 50 autorizações numa faixa de nonce, como indicador de comprometimento. Por isso uma recusa em set_code deveria disparar alerta crítico, não só uma linha de log. Jason Soroko, da Sectigo, lembra outro ponto: várias aprovações protegem pouco se um único invasor controla todas. Cada aprovador precisa estar numa identidade e num dispositivo separados.

Controle 2: Credencial Curta e Presa a Um Pedido

Credencial de longa duração é o que transforma um laptop invadido em bilhões perdidos. Um token de aprovação deveria valer por poucos minutos, servir uma única vez e valer só para aquele pedido exato. Este exemplo usa a biblioteca jose:

// Token de aprovação curto, de uso único e amarrado ao conteúdo do pedido
import { createHash, randomUUID } from 'node:crypto';
import { SignJWT, jwtVerify } from 'jose';

const secret = new TextEncoder().encode(process.env.APPROVAL_SECRET);
const usedTokens = new Set<string>(); // Em produção, use Redis com TTL

const hashRequest = (request: object) =>
  createHash('sha256').update(JSON.stringify(request)).digest('hex');

export async function issueApproval(request: object, approver: string) {
  return new SignJWT({ requestHash: hashRequest(request) })
    .setProtectedHeader({ alg: 'HS256' })
    .setSubject(approver)
    .setJti(randomUUID())
    .setIssuedAt()
    .setExpirationTime('2m') // Nada de token sem expiração
    .sign(secret);
}

export async function consumeApproval(token: string, request: object) {
  const { payload } = await jwtVerify(token, secret, {
    algorithms: ['HS256'],
  });

  // Token roubado não serve para outro destino ou outro valor
  if (payload.requestHash !== hashRequest(request)) {
    throw new Error('Aprovação não corresponde a este pedido');
  }

  if (!payload.jti || usedTokens.has(payload.jti)) {
    throw new Error('Aprovação já utilizada');
  }

  usedTokens.add(payload.jti);
  return payload.sub;
}

Duas observações para levar isso a sério. Primeiro, serialize o pedido de forma canônica: JSON.stringify depende da ordem das chaves, então ordene antes de gerar o hash. Segundo, um segredo HS256 compartilhado permite a quem o tiver emitir tokens; em sistema de alto valor, prefira assinatura assimétrica com a chave privada num HSM ou KMS.

Controle 3: Disjuntor Por Volume

Política olha um pedido por vez. O roubo aconteceu na soma de muitos. Um disjuntor mede o total que saiu numa janela de tempo e para tudo quando passa do normal. Se o atacante precisa de 20 minutos, parar no minuto dois muda o tamanho do prejuízo.

// Disjuntor: pausa as saídas quando o volume da janela foge do normal
class WithdrawalBreaker {
  private events: { at: number; usd: number }[] = [];
  private tripped = false;

  constructor(
    private readonly windowMs: number,
    private readonly maxUsd: number,
    private readonly onTrip: (totalUsd: number) => void
  ) {}

  // Chame antes de assinar; retorna false se a saída deve parar
  allow(usd: number, now = Date.now()): boolean {
    if (this.tripped) return false;

    this.events = this.events.filter(e => now - e.at < this.windowMs);
    const total = this.events.reduce((sum, e) => sum + e.usd, 0) + usd;

    if (total > this.maxUsd) {
      this.tripped = true;
      this.onTrip(total);
      return false;
    }

    this.events.push({ at: now, usd });
    return true;
  }

  // Reset é manual de propósito: quem religa é uma pessoa
  reset() {
    this.tripped = false;
    this.events = [];
  }
}

// Exemplo: até US$ 2 milhões em 10 minutos
const breaker = new WithdrawalBreaker(10 * 60 * 1000, 2_000_000, total => {
  console.error(`Saídas pausadas: US$ ${total} na janela`);
});

Guarde esse estado num armazenamento compartilhado: com várias réplicas, um contador em memória vira vários disjuntores independentes. E rode o componente fora do alcance do serviço que assina, pela mesma razão do controle anterior.

O Que Fazer Se Você Não Trabalha Com Cripto

A maior parte destas medidas vale para qualquer backend. Se precisar priorizar, comece por aqui:

  • Trate máquina de DevOps como infraestrutura privilegiada. O laptop de quem tem acesso à produção merece monitoramento e proteção de servidor crítico.
  • Dê acesso temporário. Acesso de produção é concedido sob aprovação e expira sozinho, inclusive para contas de serviço e agentes de IA.
  • Use MFA resistente a phishing e sessão curta. No caso Bybit, o atacante reaproveitou um token de sessão AWS que já tinha passado pelo MFA.
  • Pratique a revogação. Tenha um caminho testado para cortar credenciais e delegações em minutos, e saiba quem aciona.
  • Conheça seus parceiros de resposta antes do incidente. A Tether congelou 971,1 milhões de USDT 37 minutos após a varredura principal; isso só funciona com canal aberto.
  • Mantenha o patch em dia. Invasão inicial muitas vezes é banal, como mostrou a corrida para proteger servidores contra o PHP2Shell.

Se você guarda criptomoedas em corretora, a recomendação prática é simples: desconfie de qualquer mensagem pedindo para "verificar" conta ou "resgatar" fundos por causa do hack. Golpistas adoram notícia grande. Consulte o status somente no aplicativo ou no site oficial.

O Que Acompanhar nos Próximos Dias

Três coisas ainda podem mudar a leitura deste caso.

Saques. A reabertura está sendo feita por etapas: Bitcoin voltou primeiro, e em 1º de novembro entraram USDT, USDC, ETH e BNB nas redes Ethereum e BNB Smart Chain. Outras redes ainda aguardam liberação.

Prova de reservas. A Binance prometeu um relatório completo, mas as fontes divergem entre 2 e 3 de novembro. Ele deve cobrir dez tokens, incluindo BTC, ETH, USDT, BNB, SOL e USDC. Prova de reservas sem passivos conta só metade da história, então vale olhar a metodologia.

Dinheiro restante. A TRM Labs calcula que o atacante ainda controla mais de 420 mil ETH e 18.270 BTC. O FBI espera mais lavagem, e a Chainalysis observou um padrão automatizado com milhares de transações circulando entre endereços. Essa parte costuma levar meses ou anos.

O mercado reagiu rápido e se acalmou em seguida: o Bitcoin chegou a US$ 76.368 e o Ether a US$ 2.178. Segundo a Al Jazeera, o setor já estava pressionado por juros mais altos nos EUA e por demanda menor em ETFs.

Perspectivas: A Segurança Está Mudando de Lugar

Este caso desloca o centro da conversa. Durante anos, a pergunta foi "onde está guardada a chave?". Cold wallet, HSM e assinatura múltipla responderam bem a ela. A próxima pergunta é mais difícil: "quem pode pedir para a chave assinar, e o que confere esse pedido?".

Quando sair o relatório da Binance, algumas conclusões deste texto podem mudar, em especial sobre a entrada inicial e sobre as chaves. O que dificilmente muda é o princípio: qualquer credencial permanente e qualquer serviço que confie cegamente em chamadas internas é um risco maior do que parece, até o dia em que alguém o encontra.

Abra hoje o sistema mais sensível que você mantém e procure o token sem expiração. Se ele existir, esse é o seu próximo ticket.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Aí?

Este artigo cobriu o hack da Binance e o que ele ensina sobre sistemas que movem dinheiro, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue Lá

👉 Seguir @jeffbruchado no X

💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso

Comentários (0)

Esse artigo ainda não possui comentários 😢. Seja o primeiro! 🚀🦅

Adicionar comentário