Binance: US$ 6,3 bilhões roubados de suas hot wallets, um notebook DevOps como primeira pista e o FBI aponta para a Coreia do Norte

A Binance confirma que suas hot wallets foram comprometidas em 29 de outubro, com perdas de cerca de US$ 6,3 bilhões. A empresa apontou primeiro o notebook de um engenheiro de DevOps e depois encontrou outros pontos de invasão. Segundo o BleepingComputer, o FBI atribui o roubo ao grupo norte-coreano TraderTraitor.

O que aconteceu

A Binance afirma que suas hot wallets foram comprometidas por volta das 20h05 UTC de 29 de outubro de 2026, o que permitiu saques não autorizados de cerca de US$ 6,3 bilhões. A TRM Labs, que fala em US$ 6,36 bilhões, relata que os fundos saíram por dez blockchains, a maior parte em cerca de 20 minutos, e classifica o caso como o maior roubo de criptoativos já registrado. Segundo o BleepingComputer, o FBI publicou em 31 de outubro um alerta que atribui o roubo ao TraderTraitor, grupo apoiado pelo Estado norte-coreano; com o Secret Service e o IRS Criminal Investigation, pediu às plataformas que bloqueiem 628 endereços ligados à lavagem de dinheiro.

Como os atacantes entraram

O primeiro comunicado da Binance apontava o notebook comprometido de um engenheiro de DevOps, usado para acessar um contêiner de serviço e enviar transações de saque. O seguinte acrescenta que apurações posteriores revelaram outros pontos de invasão. A empresa diz não ter provas de vazamento das chaves privadas e promete um relatório detalhado. Segundo o BleepingComputer, um dos co-CEOs afirmou que o atacante não se limitou a usar as permissões de um único engenheiro e que nenhuma pessoa foi responsabilizada. Para a TRM Labs, a explicação mais provável é o controle da infraestrutura de assinatura das hot wallets; a Binance não publicou uma causa raiz.

A Binance informa cerca de US$ 3 bilhões congelados nas blockchains e garante que vai arcar com a perda. Em 1º de novembro, indicou que cerca de 95% do valor estava coberto, que os depósitos não foram afetados e que uma primeira fase de saques estava prevista para esse dia, das 6h às 9h UTC.

O que fazer agora

  1. Reserve estações para administração: nada de e-mail ou navegação geral em uma máquina com acesso à produção.
  2. Retire segredos de longa duração dos notebooks: verifique ~/.ssh, ~/.kube/config e os arquivos de credenciais de nuvem, e adote acessos de curta duração via SSO com MFA por chave física.
  3. Meça o que um notebook pode fazer: execute kubectl auth can-i --list com as credenciais de um administrador, remova o desnecessário e bloqueie o acesso direto das redes de escritório aos contêineres de produção.
  4. Exija uma segunda aprovação para ações irreversíveis: exportações em massa, exclusão de backups, pagamentos.
  5. Configure alertas de volume com parada automática: em 20 minutos não há tempo para uma decisão humana.

Nossa opinião

Poucas empresas guardam bilhões, mas quase todas têm um notebook de administrador capaz de chegar à produção. Seja qual for a conclusão do relatório final, o objetivo é o mesmo: uma única máquina comprometida nunca deve bastar para disparar uma ação irreversível. A revogação rápida de acessos também precisa ser ensaiada antes de ser necessária.

Fontes

Como escolhemos, verificamos e escrevemos nossas análises →

Verifique antes de clicar e confira o que seus servidores expõem — grátis, sem intrusão:

Verificar um e-mail Verificar um servidor

Preocupado com a exposição dos seus servidores? Nossa equipe audita, corrige e monitora infraestruturas Linux e cloud 24/7.

Fale com um especialista Nossos serviços de gestão de servidores →