Binance, US$ 6,3 bilhões e o Tio Ben: lições para CTOs

Atualizado em 5 de novembro de 2026, com base nas conclusões iniciais divulgadas pela Binance em 3 de novembro e em relatórios de TRM Labs, Chainalysis e FBI. A investigação ainda não terminou, e o post-mortem completo não foi publicado.

O que o maior roubo da história tem a ver com algo que venho martelando desde que inventaram o motor de dobra da NCC-1701? E quanto o Tio Ben estava certo ao dizer ao Peter (aquele lá): “Com grandes poderes vêm grandes responsabilidades”?

Eu sempre disse: excesso de privilégio é uma praga.

Em 29 de outubro de 2026, cerca de US$ 6,3 bilhões saíram das carteiras da Binance em dez blockchains, a maior parte em uns 20 minutos. Não houve um único tiro, nem computador quântico, nem funcionário extorquido. É cerca de quatro vezes o roubo da Bybit (US$ 1,5 bilhão, fevereiro de 2025), que até então era o recorde.

Mas espera… a Binance não tinha processo? Não tinha firewall projetado pelos vulcanos? Não tinha segurança padrão Sith?

Tinha. E é exatamente por isso que esse caso interessa a todo CTO.

A cronologia (o que se sabe até agora)

Junho de 2026. A Binance detecta uma instalação adulterada do Homebrew no computador de um engenheiro e a substitui. Ainda não está provado que esse episódio faz parte do mesmo ataque.

Setembro de 2026: a porta de entrada. Um engenheiro executa, no computador de trabalho, um “teste técnico” malicioso. É um golpe clássico do grupo norte-coreano TraderTraitor, que usa falsos recrutadores e falsas vagas. O código substitui um componente de uma ferramenta de desenvolvimento, passa a se comunicar com um servidor externo e não é detectado pela proteção de endpoint.

20 de outubro: movimento lateral. A partir dessa máquina, e usando uma ferramenta interna de IA, o atacante assume o controle dos computadores de outros dois engenheiros da área de carteiras.

29 de outubro: o golpe.

Num desses computadores, o atacante encontra um token de deploy.
Usando esse token a partir do computador de outro engenheiro, ele publica um container e roda um script malicioso.
O container alcança o serviço de assinatura das carteiras, que passa a assinar transações fora do fluxo normal de saques.
Às 20h05 UTC começa a drenagem. Na Ethereum, uma única transação, com 50 autorizações EIP-7702 pré-assinadas, esvazia a hot wallet “Binance 14”, incluindo cerca de 1,6 bilhão de USDT.

Resposta:

29/10, 21h24 UTC: a Binance reconhece um “potencial problema de segurança”.
30/10, 00h10 UTC: a delegação EIP-7702 é revogada. Às 00h13, depósitos e saques são suspensos.
Tether, Circle, Ripple, World Liberty Financial e o Arbitrum Security Council congelam entre US$ 2,7 e 3 bilhões. O que estava em BTC, ETH e SOL não tinha como ser congelado.
31/10: o FBI atribui o ataque ao TraderTraitor (Coreia do Norte).
1º/11: saques voltam depois de cerca de 54 horas. A Binance cobre as perdas com o fundo SAFU e recursos próprios.

Um detalhe que muda tudo: nenhuma chave privada vazou.

O ponto central: não precisaram roubar a chave

O atacante não precisou da chave do cofre. Bastou mandar em quem segura a chave.

O serviço de assinatura funcionou como projetado: recebeu um pedido e assinou. O problema é que, na prática, qualquer coisa que conseguisse publicar um container naquele ambiente conseguia pedir uma assinatura. E publicar um container dependia de um token que estava esquecido num laptop.

Minha primeira leitura foi: “como um DevOps tem permissão para movimentar (assinar) transferências reais?”. A própria Binance disse que o atacante “não usou simplesmente as permissões de um engenheiro”. Faz sentido. Não existe um vilão com superpoderes. O que existe é uma corrente de privilégios permanentes, cada um razoável isoladamente, que somados davam a um laptop de desenvolvimento o poder de iniciar a terceira guerra mundial das criptos:

laptop de dev → ferramenta interna de IA → outros laptops → token de deploy → container em produção → serviço de assinatura → US$ 6,3 bilhões.

O Tio Ben estava certo, só faltou um complemento: grandes poderes também se acumulam sem ninguém perceber. E poder acumulado sem dono é o que o atacante procura.

Trazendo para a realidade: por que quem conhece todas as regras e camadas do negócio teria, no próprio notebook, um caminho até produção? Dev, DevOps, ninguém deveria ter acesso ao banco de dados ou aos artefatos de produção de forma a poder fazer um estrago. Nem a pessoa, nem o laptop dela, nem a IA que ela usa.

As lições para CTOs (de qualquer tamanho)

Você não tem uma hot wallet com bilhões. Mas tem um banco de produção, um pipeline de deploy, um ERP e um gateway de pagamento. A lógica é a mesma.

1. A estação de trabalho do desenvolvedor é território hostil.

Teste técnico, repositório desconhecido ou “projeto de exemplo” roda em VM descartável, sem sessão de SSO, sem chave SSH, sem credencial de nada. Se o seu time faz entrevista técnica, avise que o golpe existe. O TraderTraitor também usou isso na Safe{Wallet} (que levou ao caso Bybit) e na DMM Bitcoin.

2. Nada de privilégio permanente.

Acesso a produção deve ser just-in-time: pedido, aprovado, com prazo e registrado. Se alguém tem acesso “porque um dia precisou”, esse acesso é do atacante também.

3. Tokens que vivem pouco e servem para pouco.

Um token de deploy guardado num laptop vale tanto quanto a coisa mais valiosa que ele alcança. Use credenciais de curta duração, com escopo mínimo e presas ao dispositivo e à carga de trabalho.

4. Seu pipeline é produção.

Quem pode publicar um container no ambiente que conversa com o sistema crítico tem, na prática, acesso ao sistema crítico. Faça esse mapa: quais caminhos levam ao que pode me quebrar?

5. A política vale no executor, não em quem pede.

O serviço que assina, transfere ou apaga precisa ter regras próprias: limites por valor e por janela de tempo, lista de destinos permitidos, recusa de operações atípicas e aprovação de mais de uma pessoa em outro dispositivo. Drenar US$ 6,3 bilhões em 20 minutos indica limites de velocidade ausentes ou contornados.

No mundo de banco de dados, onde vivo há décadas, isso é velho conhecido. O DELETE sem WHERE em produção não deveria depender da boa vontade de quem digita. Deveria depender de um processo que não deixa ninguém executar sozinho.

6. Ferramentas internas de IA são identidades privilegiadas.

Esse é o capítulo novo da história. Um assistente que alcança várias máquinas e sistemas é um superusuário. Limite o alcance, autorize cada alvo e registre quem iniciou cada ação.

7. Dimensione o raio de explosão.

Quanto o seu sistema “quente” pode perder no pior dia sem quebrar a empresa? A Binance sobreviveu porque tinha caixa e um fundo de emergência. A maioria das empresas não tem.

8. Prepare a contenção antes do incidente.

A Binance revogou a delegação e suspendeu saques em cerca de quatro horas, e os emissores de stablecoins congelaram quase metade do valor. Isso só funciona com botão de emergência testado e contatos combinados de antemão.

O que podemos aprender

Um roubo de bilhões, sem tiro, sem computador quântico, sem extorsão. Bastaram um teste técnico falso, paciência de algumas semanas e uma corrente de privilégios que ninguém via inteira.

Processos de segurança mega rigorosos não bastam se o caminho até o poder não estiver mapeado. A pergunta para segunda-feira de manhã não é “temos firewall vulcano?”. É esta:

Se o notebook de qualquer pessoa do meu time for comprometido hoje, até onde o atacante chega?

Se a resposta for “até produção”, você já sabe por onde começar.

Fontes: BleepingComputer, TRM Labs, Chainalysis, FBI, Cloud Security Alliance e StepSecurity (links abaixo). Os detalhes técnicos vêm das conclusões preliminares da Binance e podem mudar com o post-mortem oficial.

Binance, US$ 6,3 bilhões e o Tio Ben: o que o maior roubo da história ensina a todo CTO