O ataque hacker à Binance começou em um notebook: o que testar nos seus próprios sistemas

O que aconteceu no ataque hacker à Binance?

O ataque hacker à Binance é o roubo de cerca de US$ 6,3 bilhões em criptomoedas das hot wallets da Binance em 29 de outubro de 2026. Segundo a TRM Labs, é o maior roubo de criptomoedas já registrado, cerca de quatro vezes o US$ 1,5 bilhão que atacantes levaram da Bybit em fevereiro de 2025. Os relatos públicos dão esta sequência:

• Às 20h05 UTC, os fundos começaram a sair das wallets da Binance em dez blockchains. A maior parte do dinheiro saiu nos 20 minutos seguintes.

• No Ethereum, o atacante usou uma delegação EIP-7702, com 50 autorizações assinadas antecipadamente, para transformar uma hot wallet da Binance em um sweeper sob seu controle.

• Os emissores de stablecoins congelaram fundos durante a noite. A TRM contou cerca de US$ 2,7 bilhões congelados às 00h30 UTC de 30 de outubro, e só a Tether congelou cerca de 1,77 bilhão de USDT.

• A Binance suspendeu depósitos e saques e disse que cobriria todas as perdas com o Secure Asset Fund for Users (SAFU) e com recursos próprios.

• Em uma atualização posterior, a Binance disse que a investigação tinha "descoberto pontos de invasão adicionais" além do notebook.

O EIP-7702 é um recurso do Ethereum, adicionado em 2025, que permite que uma conta comum delegue suas ações a código de um contrato inteligente por meio de uma autorização assinada (EIP-7702). O The Hacker News cita as declarações da Binance, e a Chainalysis dá sua própria estimativa de cerca de US$ 2,8 bilhões congelados.

O que é uma hot wallet e por que ela é alvo de atacantes?

Uma hot wallet é uma carteira de criptomoedas cujo sistema de assinatura fica online, para que uma exchange processe saques sem intervenção humana. Uma cold wallet guarda as chaves offline e exige etapas manuais para cada transferência. As exchanges mantêm a maior parte dos fundos em armazenamento frio e um saldo operacional em hot wallets.

O detalhe importante está na declaração da Binance: ela não encontrou evidência de vazamento de nenhuma chave privada de wallet. As 50 autorizações que a TRM descreve foram assinadas antecipadamente, então algo precisou assiná-las. Se os dois fatos se confirmarem, o atacante não roubou as chaves. Ele fez os próprios sistemas da Binance assinarem. Quando um serviço de assinatura assina qualquer requisição bem formada vinda de um serviço interno confiável, controlar esse serviço interno basta para mover fundos.

Isso não é exclusivo do mundo cripto. Um serviço de pagamentos, uma API de core bancário ou uma fila de transferências em um banco tem o mesmo ponto fraco quando confia em toda requisição que vem de dentro da rede.

Como o atacante chegou ao sistema de saques da Binance?

O relato preliminar da Binance descreve este caminho:

1. O atacante comprometeu um notebook usado por um engenheiro DevOps. A Binance não disse como.

2. A partir desse notebook, o atacante obteve acesso a um contêiner de serviço na infraestrutura da Binance.

3. O atacante usou esse contêiner para enviar transações de saque não autorizadas.

4. A infraestrutura de hot wallets da Binance assinou essas transações, e os fundos saíram por dez blockchains.

Trate o notebook como uma hipótese de trabalho, não como causa raiz confirmada. O co-CEO Richard Teng disse ao CoinDesk que o roubo não foi uma única ação "de um clique", que a delegação EIP-7702 contornou os controles de aprovação habituais da Binance e que um mecanismo de autodestruição apagou as ferramentas e os rastros do atacante. A Binance está revisando seus sistemas em nuvem, os dispositivos dos funcionários, a gestão de chaves e a assinatura. Cada etapa do caminho é um ponto de controle: o atacante precisou passar por todas, e bastava ao defensor detê-lo em uma.

A mesma cadeia de acesso já causou perdas em outras organizações?

Sim. Bancos, exchanges e provedores de wallets perderam dinheiro pela mesma sequência: o atacante compromete uma pessoa ou um sistema com acesso privilegiado e depois usa esse acesso para chegar ao sistema que movimenta dinheiro. Estes casos públicos seguem esse padrão:

A América Latina também já viu a primeira parte dessa cadeia: um funcionário da Redbanc, a rede interbancária do Chile, foi enganado e baixou um malware, como contamos no nosso post sobre cibersegurança em serviços financeiros. Em todos os casos, o primeiro alvo foi uma pessoa com acesso privilegiado, não uma aplicação pública. Falamos de roubos anteriores a exchanges no Top 10 de crimes com criptomoedas.

Como a Fluid Attacks ajuda você a testar cada elo?

A proteção de endpoints e a conscientização em segurança defendem o primeiro elo. A maioria dos elos seguintes depende de como o software é escrito e configurado, e a Fluid Attacks os testa antes de um atacante. Estes são os cinco elos que verificamos em aplicações bancárias e de fintech.

1. Segredos em repositórios e pipelines

Um atacante que controla o notebook de um desenvolvedor pode ler todos os repositórios que esse desenvolvedor pode ler. Credenciais, chaves de API e tokens no código-fonte, em arquivos de configuração ou no histórico do Git transformam esse acesso em acesso a outros sistemas. Procure informações sensíveis no código-fonte, incluindo credenciais e segredos que foram apagados, mas continuam no histórico do Git. A correção é remover o segredo, rotacioná-lo e movê-lo para um gerenciador de segredos. A varredura de segredos da Fluid Attacks encontra segredos expostos em código, configuração e infraestrutura como código (IaC), e pode quebrar o build no seu pipeline de CI/CD quando encontra um.

2. Dependências maliciosas e vulneráveis

Os atacantes também distribuem malware por meio de pacotes de software e testes de programação falsos, como mostra o caso da DMM Bitcoin. Em setembro de 2025, um ataque de phishing a um mantenedor do npm inseriu código que redirecionava transações de criptomoedas em pacotes do npm com mais de 2 bilhões de downloads semanais, como explicamos na nossa análise desse ataque ao npm. Verifique cada dependência em busca de vulnerabilidades conhecidas e de malware, e fixe as versões para que um novo release não entre em um build sem revisão. Nossa análise de composição de software (SCA) gera uma lista de materiais de software (SBOM) e classifica as dependências vulneráveis pelo risco real.

3. Funções privilegiadas dentro das suas aplicações

Muitas aplicações têm funções para os times de operações: painéis de administração, endpoints de suporte, rotas de depuração, contas de serviço e tokens que os serviços usam para chamar uns aos outros. Essas funções costumam receber menos revisão do que as funcionalidades para clientes, porque só usuários internos chegam a elas. Depois que um notebook é comprometido, o atacante é um usuário interno. Verifique se cada função privilegiada exige autenticação forte, se cada papel tem só as permissões de que precisa (privilégios excessivos) e se nenhuma rota permite que uma pessoa atue sobre dados de produção sem os controles normais. Na nossa revisão de código seguro, os analistas rastreiam quem pode chamar cada uma dessas funções e com qual identidade.

4. Autorização e lógica de negócio nos fluxos que movimentam dinheiro

O sistema de saques é onde o ataque vira perda. A declaração de Teng de que uma delegação contornou os controles de aprovação normais mostra por quê: uma etapa de aprovação que um segundo caminho consegue pular não protege nada. Verifique como os serviços que criam, aprovam e assinam transações autenticam cada requisição, e o que verificam antes de agir:

• O serviço de assinatura verifica qual serviço enviou a requisição e se ela passou pela aprovação?

• Uma transferência grande ou incomum precisa de uma segunda aprovação, independente?

• Existem limites de valor, limites de frequência e tempos de espera que um operador só pode alterar em um sistema separado?

As falhas aqui são de controle de autorização inadequado e fraquezas de lógica de negócio, e scanners automatizados raramente as encontram. Nossos pentesters testam esses fluxos no PTaaS: eles tentam movimentar dinheiro com o acesso que um funcionário comprometido teria.

5. Infraestrutura como código

Se os seus repositórios definem infraestrutura em Terraform, manifestos do Kubernetes ou arquivos do Docker Compose, uma falha de configuração também é uma falha de código. Um contêiner que roda com privilégios excessivos, um cluster role que qualquer pod pode usar ou uma regra de rede que deixa estações de trabalho alcançarem serviços de produção facilitam o segundo passo do atacante. Um pull request que altera um role binding ou uma regra de firewall merece a mesma revisão que uma mudança no código de pagamentos. O teste estático de segurança de aplicações (SAST) verifica esses arquivos junto com o resto do código, antes que cheguem à produção.

Quais controles dependem da operação, e não do código?

O ataque hacker à Binance começou com o acesso que uma pessoa tinha aos sistemas de produção. O código das aplicações não resolve isso, então esse acesso precisa de uma revisão periódica própria. Valide o acesso do seu time técnico à produção:

• Liste quem tem acesso à produção e confirme que cada pessoa ainda precisa dele.

• Conceda acesso por tempo limitado e após aprovação, em vez de acesso permanente.

• Exija autenticação multifator em todo acesso à produção, de preferência com um método que o phishing não consiga capturar, como uma chave de segurança física. Mantenha as sessões curtas: no roubo à Bybit, o atacante reutilizou um token de sessão da AWS que já tinha passado pelo MFA.

• Garanta que ninguém consiga chegar a contêineres ou serviços de produção diretamente de um notebook de trabalho. Use um caminho de acesso controlado, como um bastion host ou um broker de acesso, que registre cada sessão.

• Registre cada acesso e cada ação sensível, e envie alertas quando a atividade for incomum, como uma rajada de saques em um horário fora do padrão.

A configuração da nuvem faz parte dessa revisão. O gerenciamento da postura de segurança em nuvem (CSPM) verifica continuamente as configurações de identidade e acesso nas suas contas de nuvem em relação a requisitos de segurança.

Perguntas frequentes

Uma chave privada da Binance foi roubada?

A Binance disse que não encontrou evidência de vazamento de nenhuma chave privada de wallet. A declaração preliminar diz que o atacante enviou transações de saque não autorizadas por meio de um contêiner de serviço. Isso sugere que o atacante usou sistemas em que a infraestrutura de assinatura da Binance confiava, e não chaves roubadas. O postmortem vai confirmar ou corrigir isso.

O EIP-7702 é uma vulnerabilidade?

Não. O EIP-7702 é um recurso padrão do Ethereum que permite que uma conta delegue suas ações a código de um contrato inteligente. Os relatos públicos não descrevem uma falha no EIP-7702 em si. Eles descrevem autorizações que os próprios sistemas da Binance assinaram e que pularam os controles de aprovação habituais. O ponto fraco foi quais requisições a infraestrutura de assinatura aceitava.

Um scanner de código consegue detectar um ataque como este?

O primeiro passo, não. Um notebook comprometido é um problema de segurança de endpoints, e uma varredura do seu código não vai mostrá-lo. Scanners e revisão de código encontram as falhas que facilitam os passos seguintes, como segredos expostos, dependências vulneráveis e verificações de autorização ausentes. A lógica de negócio dos fluxos que movimentam dinheiro exige pentesting manual.

Teste os fluxos que movimentam dinheiro antes de um atacante

A lição prática do ataque hacker à Binance: liste cada fluxo dos seus sistemas que pode movimentar dinheiro e cada pessoa e serviço que pode iniciá-lo, e teste o que um atacante consegue fazer com cada uma dessas identidades. Comece pelos fluxos com os limites mais altos e o menor número de aprovações. Esta tabela relaciona cada elo à técnica da Fluid Attacks que o testa:

Se os seus times de fraude e de engenharia acompanham esses riscos separadamente, nosso post sobre risco de segurança e fraude mostra como uni-los. Você pode experimentar nossas ferramentas com um teste gratuito de 21 dias ou falar com a gente para planejar um teste dos seus fluxos de transações.