Voltar

2026/11/02

O maior roubo de criptomoedas não começou na blockchain, mas em um único notebook: lições da Binance

O roubo na Binance começou num notebook de DevOps comprometido, não por falha criptográfica. O que se confirmou, o que não, e cinco verificações para seus sistemas.

Em 29 de outubro de 2026, atacantes esvaziaram hot wallets da Binance em pelo menos dez blockchains em poucas horas. A Binance estima o impacto em cerca de US$ 6,3 bilhões, o que faz deste quase certamente o maior roubo da história das criptomoedas. Não foi a criptografia que falhou. Segundo as conclusões preliminares da Binance, o ataque começou em um único notebook comprometido de um engenheiro de DevOps.

Isso torna o incidente relevante muito além das exchanges de criptomoedas. Toda organização tem pessoas, dispositivos e sistemas capazes de aprovar ações sensíveis: implantações em produção, pagamentos, assinaturas, acesso privilegiado à nuvem. Este artigo separa o que está confirmado do que ainda é preliminar, explica por que um endpoint privilegiado comprometido pode ser pior do que uma chave roubada e lista cinco verificações que você pode fazer no seu próprio ambiente.

Principais conclusões

  • A investigação preliminar da Binance aponta o notebook comprometido de um engenheiro de DevOps como ponto de entrada, e a Binance afirma não ter encontrado indícios de vazamento de chaves privadas de carteiras. Ambas as conclusões são preliminares.
  • Um atacante que controla os sistemas que solicitam e aprovam assinaturas não precisa roubar as chaves.
  • O FBI e várias empresas de análise de blockchain atribuem o roubo ao grupo norte-coreano TraderTraitor; a própria Binance não apontou nenhum atacante.
  • As defesas mais importantes protegem as pessoas, os endpoints e os fluxos de aprovação em torno das chaves, e não apenas as chaves em si.
  • O mesmo padrão se aplica a consoles de nuvem, SSH, pipelines de CI/CD e agentes de IA capazes de agir em produção.

O que aconteceu e o que ainda é preliminar

A empresa de análise de blockchain TRM Labs informa que os fundos começaram a sair das carteiras da Binance por volta das 20h05 UTC de 29 de outubro, e que a maior parte do valor foi movimentada em cerca de 20 minutos. Em sua declaração preliminar, noticiada pelo BleepingComputer, a Binance disse que o incidente pode envolver o notebook comprometido de um engenheiro de DevOps, por meio do qual o atacante chegou a um contêiner de serviço e enviou transações de saque não autorizadas. A Binance suspendeu os saques, revogou a autorização afetada e começou a trabalhar com as autoridades policiais.

Desde então, a Binance afirmou que sua investigação “descobriu pontos adicionais de violação”. O co-CEO Richard Teng disse que o ataque não foi resultado das permissões de um único engenheiro e, conforme citado pela Elliptic, que ele “não passou pelos nossos controles normais de aprovação”. A Binance prometeu um post-mortem detalhado, que ainda não havia sido publicado no momento em que este artigo foi escrito (2 de novembro).

PontoSituação no momento da redação
Valor afetadoCerca de US$ 6,3 bilhões, segundo estimativa da Binance; empresas de análise relatam de US$ 6,36 a 6,43 bilhões, conforme o método e a cotação utilizados.
Ponto de entradaPreliminar: o notebook comprometido de um engenheiro de DevOps. Desde então, a Binance relatou pontos adicionais de violação.
Vazamento de chave privadaA Binance afirma não ter encontrado indícios de vazamento de chaves privadas de carteiras. A investigação continua.
AutoriaO FBI atribuiu o roubo ao TraderTraitor, da Coreia do Norte, em 31 de outubro, em linha com TRM Labs, Chainalysis e Elliptic. A Binance não apontou nenhum atacante.
Fundos congeladosValor não definitivo. A Binance cita cerca de US$ 3 bilhões imobilizados; a Elliptic havia verificado cerca de US$ 2,85 bilhões congelados ou apreendidos on-chain até 1º de novembro, principalmente stablecoins.
Impacto para os clientesA Binance diz que arcará com o prejuízo e que os fundos dos usuários estão seguros. Os saques começaram a ser reabertos em fases em 1º de novembro.

Congelado não é o mesmo que recuperado. Emissores de stablecoins como Tether e Circle podem congelar os tokens que emitem, mas bitcoin, XRP e outros ativos nativos não podem ser congelados dessa forma, e boa parte do valor roubado ainda está sendo lavada.

Por que um endpoint privilegiado comprometido pode ser pior do que uma chave roubada

Uma chave privada roubada é um problema sério, mas é um problema único e bem conhecido: rotacione a chave e a cópia roubada perde a maior parte do seu valor. Um atacante que controla o dispositivo de um engenheiro com privilégios está em outra posição. Ele pode usar os sistemas que solicitam assinaturas legitimamente, chamar serviços internos com credenciais válidas e enviar transações que parecem operações normais.

As evidências on-chain se encaixam nesse quadro. A TRM Labs avaliou que o padrão observado em muitas blockchains “aponta para um comprometimento da infraestrutura de assinatura das hot wallets da Binance”, ou seja, o atacante conseguia fazer com que os próprios sistemas da Binance assinassem transações escolhidas por ele. Na Ethereum, a empresa de segurança Blockaid constatou que uma hot wallet assinou um lote de autorizações EIP-7702 que entregou o controle da carteira ao contrato do atacante. Como essas assinaturas foram obtidas ainda não está confirmado, e abordaremos esse mecanismo em um artigo de acompanhamento separado.

Isso não é novidade. No roubo à Bybit, em fevereiro de 2025, que o FBI também atribuiu ao TraderTraitor, os atacantes comprometeram a máquina de um desenvolvedor de um provedor de carteiras e manipularam a transação que os signatários da Bybit aprovaram. Nos dois casos, as chaves fizeram exatamente o que lhes foi pedido. A questão era quem estava pedindo.

Cinco verificações defensivas

1. Separe os dispositivos privilegiados do trabalho do dia a dia

O dispositivo usado para aprovar mudanças em produção, assinar transações ou administrar a infraestrutura não deve ser o mesmo usado para e-mail, chat, navegação e instalação de ferramentas de desenvolvimento. Use estações de trabalho administrativas dedicadas e reforçadas ou desktops virtuais isolados, sem contas pessoais e com uma lista curta de softwares aprovados. O TraderTraitor tem usado repetidamente ofertas de emprego falsas e testes de programação maliciosos para entrar nas máquinas de desenvolvedores; um dispositivo separado mantém esse tipo de comprometimento longe do fluxo de aprovação.

2. Exija mais de uma pessoa e acrescente tempo

Nenhuma pessoa, dispositivo ou conta de serviço deve ser capaz de, sozinha, movimentar grandes valores ou alterar a produção. Exija aprovação de pessoas em dispositivos separados, defina limites de valor por transação e por janela de tempo e acrescente um atraso (um timelock) para operações grandes ou incomuns. Mesmo um atraso de poucos minutos dá ao monitoramento e às pessoas a chance de reagir.

Dica: Verifique se os aprovadores veem o que realmente estão aprovando. No caso da Bybit, os signatários aprovaram uma transação cujo conteúdo real havia sido manipulado. A tela de aprovação deve mostrar a ação exata, o destino e o valor, gerados de forma independente do sistema solicitante.

3. Reforce os endpoints e monitore-os

Execute EDR em todos os dispositivos privilegiados e garanta que alguém analise os alertas 24 horas por dia. Mantenha os sistemas atualizados, bloqueie softwares não assinados ou não aprovados, use MFA resistente a phishing, como chaves de segurança físicas, e limite por quanto tempo as sessões administrativas e os tokens permanecem válidos. Trate as ferramentas de desenvolvimento, incluindo pacotes, extensões de IDE e assistentes de programação com IA, como parte da superfície de ataque.

4. Detecte anomalias e seja capaz de congelar rapidamente

Os fundos da Binance foram movimentados em minutos. Defina o que é normal para suas operações mais sensíveis, como volumes, destinos, horários do dia e taxas de assinatura, e gere alertas sobre desvios em tempo real. Prepare uma parada de emergência capaz de pausar saques, implantações ou assinaturas em segundos, decida com antecedência quem pode acioná-la e pratique seu uso.

5. Audite quem e o que pode acionar assinaturas e acesso à produção

Liste todas as pessoas, contas de serviço, contêineres, pipelines e chaves de API que podem solicitar uma assinatura, aprovar um pagamento ou alterar a produção. Para cada item, verifique se ainda precisa desse acesso, se o acesso tem o escopo mais restrito possível e se seu uso é registrado em um local que o atacante não consiga apagar. Remova privilégios permanentes sempre que possível e use acesso just-in-time em seu lugar.

Lições para nuvem corporativa, SSH, CI/CD e operações com IA

A maioria das organizações não opera hot wallets de criptomoedas, mas todas têm algo equivalente: credenciais e sistemas que podem agir com autoridade.

  • Nuvem: o notebook de um administrador com uma sessão de console ativa ou credenciais de CLI em cache é tão valioso quanto a conta root. Use credenciais de curta duração, sessões vinculadas ao dispositivo e fluxos de aprovação para ações destrutivas ou de alto impacto.
  • SSH: chaves de longa duração armazenadas nas máquinas dos engenheiros dão ao atacante acesso direto aos servidores. Prefira certificados SSH de curta duração emitidos por sessão e registre centralmente todas as sessões privilegiadas.
  • CI/CD: pipelines frequentemente guardam credenciais de implantação e de assinatura. Proteja as definições de pipeline com exigência de revisão, separe as credenciais de build e de release e exija aprovação para releases em produção.
  • Operações orientadas por IA: agentes de IA capazes de executar comandos, abrir pull requests ou chamar APIs de produção são novas identidades privilegiadas. Dê a eles credenciais próprias com escopo restrito, mantenha uma etapa de aprovação humana para ações sensíveis e registre o que fazem.

Dica: Faça um exercício de mesa (tabletop) com uma única pergunta: “Se o notebook deste engenheiro fosse totalmente comprometido esta noite, o que o atacante poderia fazer antes que alguém percebesse?” A resposta mostra onde seus fluxos de aprovação dependem de um único dispositivo.

O que acompanhar a seguir

O post-mortem da Binance deverá confirmar ou revisar a hipótese do notebook, explicar como as assinaturas foram obtidas e mostrar quais controles foram contornados. Até lá, trate a causa raiz como preliminar. As lições defensivas acima não dependem dos detalhes finais: seja qual for o caminho exato, o atacante alcançou os sistemas capazes de autorizar ações sensíveis.

Como a LOGIQ pode ajudar

A LOGIQ ajuda organizações a revisar o acesso privilegiado em servidores Linux, ambientes de nuvem e pipelines de CI/CD, e a projetar controles de aprovação e monitoramento adequados à forma como suas equipes realmente trabalham. Se você quiser uma segunda opinião sobre quem e o que pode agir com autoridade no seu ambiente, entre em contato.

Fontes