US$ 6,3 bilhões saíram da Binance em cerca de 20 minutos — e nenhuma chave privada foi quebrada

Na quinta-feira (29/10), a Binance confirmou que aproximadamente US$ 6,3 bilhões (cerca de R$ 33 bilhões) em ativos digitais foram afetados no que analistas descrevem como o maior roubo de criptomoedas da história — mais de quatro vezes o recorde anterior, os US$ 1,5 bilhão levados da Bybit em fevereiro de 2025. A própria corretora informou que a investigação inicial aponta para o notebook comprometido de um engenheiro de DevOps, que teria dado ao invasor acesso a um contêiner de serviço e permitido o envio de transações de saque não autorizadas. A Binance afirma não ter encontrado nenhuma evidência de vazamento de chave privada de carteira.

Fonte: Binance — Security Incident Update (2026-10-30) · G1 — Binance sofre ataque de US$ 6,3 bilhões (30/10/2026) · UOL — Ataque de US$ 6,3 bi à Binance reacende debate sobre segurança das criptomoedas (30/10/2026) · Folha/C-Level — Binance Brasil suspende saques após ataque hacker (30/10/2026)

O detalhe que interessa a qualquer operação está no que não foi violado. Segundo o co-CEO Richard Teng, os invasores manipularam um sistema usado para aprovar transações e moveram fundos de uma carteira conectada à internet — uma carteira quente — "de forma que não passasse pelos controles normais de aprovação". A criptografia do bitcoin não foi quebrada, nenhuma chave privada vazou, e a transação era tecnicamente válida para a rede: ela foi assinada pela própria Binance. O que falhou foi a camada que decide quem pode autorizar o dinheiro a sair. Como resumiu o CIO da Hashdex, Samir Kerbage: "a transação foi válida, foi assinada pela Binance, só que o atacante teve acesso aos sistemas da Binance."

Teng acrescentou dois pontos que mudam o cálculo de qualquer resposta a incidente. Primeiro, não foi um clique: o invasor não se limitou às permissões de um único engenheiro, e a investigação não atribui responsabilidade a nenhum indivíduo — o que aponta para comprometimento de credenciais e de privilégio, não para erro isolado. Segundo, o ataque envolveu software projetado para apagar rastros e evidências conforme avançava, o que, nas palavras dele, tornou "mais difícil rastrear e investigar" o caso. A trilha foi destruída durante o incidente — exatamente quando ela é mais necessária.

A Binance suspendeu os saques como medida preventiva, revogou a autorização do endereço afetado e acionou autoridades e parceiros de inteligência em blockchain. Cerca de US$ 3 bilhões foram congelados on-chain, e a corretora reservou US$ 6,34 bilhões em recursos próprios para cobrir as perdas, com US$ 5 bilhões já mantidos nos tokens exatos afetados. A Binance Brasil informou que os fundos de clientes no país permanecem em carteiras frias, sob as regras de segregação do Banco Central. O bitcoin recuou cerca de 4% a 5%. A atribuição a um grupo ligado à Coreia do Norte (TraderTraitor, também chamado de Lazarus) vem das empresas de análise TRM Labs e Chainalysis — não é uma confirmação da Binance, e deve ser tratada como alegação de terceiros até que a investigação oficial se pronuncie. A Check Point, que analisa o caso, resume o padrão: "os invasores não precisam mais das chaves do cofre. Eles visam os sistemas e as pessoas com autoridade para usá-los."

Por que isso importa: este não é um caso de criptografia quebrada, e sim de controle de acesso, privilégio e evidência. A camada que autoriza uma movimentação de alto valor é humana e processual — e foi por ela que o ataque passou. É a mesma classe de risco do incidente de terceiros que dominou outubro no Brasil: o ponto de falha raramente é o código, é quem tem autoridade e qual trilha sobra depois. Quando o próprio atacante apaga os logs enquanto age, a organização perde simultaneamente o dinheiro, o rastro e a capacidade de provar o que aconteceu — para o regulador, para o cliente e para o seguro.

O que uma organização deveria testar e monitorar continuamente:

• Segregação de funções nas autorizações de alto valor — quantas pessoas, com quais credenciais, conseguem aprovar uma movimentação crítica; e se existe algum caminho que a aprove sem os controles previstos.
• Integridade e imutabilidade de logs — se a trilha pode ser apagada pelo próprio invasor durante o incidente, ela não serve como evidência. Logs fora do alcance do atacante, com retenção e verificação.
• Privilégio das máquinas de engenharia — quais notebooks e contas de DevOps alcançam ambientes de produção, e quanto escopo cada uma carrega.
• Detecção sobre transações autorizadas — o controle não pode olhar só a assinatura; movimentos válidos e fora de padrão são o caso aqui.
• Plano de resposta testado — quanto tempo a operação leva para perceber, conter, congelar e provar o que aconteceu.

A rede criptográfica funcionou como projetada. O que falhou foi a camada que decide quem pode mandar o dinheiro sair — e essa camada não tem criptografia que a proteja por si só.