Ataque à Binance: o que se sabe do incidente de 6,3 mil milhões de dólares e as lições para a segurança digital

Na noite de 29 de outubro de 2026, a Binance, a maior plataforma de criptomoedas do mundo, confirmou um incidente de segurança com um impacto estimado em cerca de 6,3 mil milhões de dólares. Não é um rumor das redes sociais: a confirmação consta de um comunicado oficial da própria Binance e foi noticiada pela Reuters, pela Bloomberg, pela BBC, pela CNBC, pela CoinDesk, pela The Block e pela BleepingComputer. Se os valores se confirmarem, será o maior roubo de criptoativos de que há registo, cerca de quatro vezes o do Bybit, em fevereiro de 2025.

Continua por confirmar muita coisa: a causa exata, o responsável e quanto dinheiro será recuperado. Este artigo separa o que a Binance e as fontes independentes confirmam do que são estimativas, atribuições de empresas de análise e especulação, e tira daí lições para quem gere servidores e aplicações. A informação reflete o ponto de situação de 30 de outubro de 2026.

O que aconteceu à Binance?

As horas abaixo são UTC, que coincide com a hora legal em Portugal continental a 30 de outubro.

28 de outubro. Segundo a TRM Labs, empresa de análise de blockchain, a carteira do atacante recebeu pequenas quantias do Tornado Cash, um serviço que esconde a origem dos fundos. A preparação terá começado pelo menos 36 horas antes do roubo.
29 de outubro, a partir das 20:05. Segundo a TRM, começaram as saídas de fundos de carteiras da Binance. Em cerca de 20 minutos, a maior parte foi transferida, em dez blockchains. A TRM estima o total em 6,36 mil milhões de dólares.
21:15 e 21:29. Changpeng Zhao (CZ), fundador da Binance, escreveu no X que «it does look like a hack on Binance» e que já não gere a Binance.com (publicação). A Binance disse estar a investigar um «potencial problema de segurança» (publicação).
30 de outubro, 00:04 a 00:52. A co-fundadora Yi He afirmou que a Binance cobriria todas as perdas e que depósitos e levantamentos estavam suspensos. A Binance indicou cerca de 3 mil milhões de dólares congelados (atualização).
02:24. O comunicado «Security Incident Update» avançou a primeira hipótese sobre a causa (publicação).
04:36. Os depósitos funcionam normalmente. Os levantamentos continuam em pausa durante uma revisão de segurança, com retoma esperada em 48 horas (atualização).

A Binance.US, plataforma separada, disse não ter sido afetada, segundo a BBC e a The Block.

Confirmado, estimado e não confirmado

Confirmado pela Binance: houve um incidente de segurança, os levantamentos foram suspensos e a empresa diz que cobrirá as perdas.
Estimativas: 6,3 mil milhões de dólares (Binance), 6,36 mil milhões (TRM) e pelo menos 5,9 mil milhões (Chainalysis, na primeira avaliação). Os congelados são cerca de 3 mil milhões para a Binance e 2,7 mil milhões para a TRM.
Não confirmado pela Binance: a autoria norte-coreana, a causa exata e a recuperação dos fundos.

Como terá ocorrido o ataque?

A Binance ainda não publicou uma explicação técnica completa e prometeu um relatório pós-incidente quando os factos estiverem verificados. Para já, há a hipótese da empresa e a análise externa da blockchain.

A hipótese da Binance

No comunicado, a Binance escreve que a investigação inicial «sugere que o incidente pode envolver o portátil comprometido de um engenheiro DevOps, o que permitiu a um atacante aceder a um contentor de serviço e submeter transações de levantamento não autorizadas». Diz também que não encontrou provas de fuga de chaves privadas. A palavra «pode» importa: é uma hipótese preliminar. Segundo a CyberInsider e a BlockTempo, uma atualização posterior fala em «múltiplos fatores», mas não conseguimos abri-la na fonte primária.

O que mostram os dados da blockchain

A análise da TRM Labs é de terceiros e não uma confirmação da Binance. Descreve o seguinte:

Na Ethereum, o atacante usou o EIP-7702, que permite a uma carteira normal delegar o seu comportamento num contrato inteligente através de uma autorização assinada. Foram submetidas 50 autorizações assinadas por uma carteira quente da Binance, todas a apontar para um contrato do atacante. Como a carteira processa levantamentos sem parar, ter assinaturas para 50 valores consecutivos do contador de transações garantiu que uma seria válida.
Nas outras nove blockchains, as carteiras enviaram fundos ao atacante através de transferências assinadas normais, sem delegação.
Como redes com tipos de chave diferentes produziram assinaturas válidas para o atacante em cerca de meia hora, a TRM considera mais provável o comprometimento da infraestrutura de assinatura das carteiras quentes do que o roubo de autorizações por phishing.

Mark Karpeles, antigo responsável da Mt. Gox, disse à Reuters que o atacante provavelmente encontrou a chave privada usada por esses endereços, o que contradiz a afirmação da Binance sobre as chaves. Só o relatório técnico o poderá esclarecer.

Quem foi?

A TRM Labs atribui o ataque, com «grau de confiança elevado», ao TraderTraitor, unidade de elite de pirataria da Coreia do Norte ligada ao grupo Lazarus. A Chainalysis chegou à mesma conclusão. A CNBC recorda que o FBI atribuiu ao mesmo grupo o roubo do Bybit. A Binance não respondeu diretamente à BBC sobre esta ligação. Não encontrámos nenhuma atribuição oficial de uma autoridade. É uma avaliação de empresas privadas.

O papel da segurança DevOps e dos contentores

A Binance não revelou que tecnologia de contentores usa, que permissões tinha o serviço nem como o portátil foi infetado, e ir além do comunicado seria especulação. Mas o cenário que a empresa descreve é uma cadeia clássica: a máquina de um administrador, um serviço em contentor e uma função crítica (levantamentos) acessível a partir dele. Cada elo ensina algo, como lição geral e não como diagnóstico da Binance:

O portátil do engenheiro concentra sessões, tokens, chaves SSH e credenciais de cloud. Se for comprometido, o atacante herda tudo.
Credenciais de longa duração, guardadas em ficheiros de configuração ou variáveis de ambiente, facilitam a passagem do portátil para o servidor.
Permissões excessivas: um contentor que corre como root ou que pode ordenar movimentos de dinheiro transforma um acesso limitado numa perda enorme.
CI/CD: quem altera o pipeline altera, muitas vezes, o que corre em produção.

Já escrevemos sobre a rapidez com que chaves expostas se tornam incidentes em «Outubro negro na segurança» e sobre servidores desatualizados em «Vghost: a falha de quase nove anos no kernel Linux».

Os utilizadores da Binance estão em risco?

A Binance diz que os fundos dos utilizadores estão seguros e que cobrirá as perdas com o fundo SAFU e com fundos da empresa. É uma promessa, não uma confirmação independente.
Os depósitos funcionam. Os levantamentos estão suspensos, com retoma esperada por volta de 1 de novembro. É uma estimativa, não uma garantia.
Um analista da Fundstrat disse à CNBC que, para já, não parece haver risco significativo de solvência. É uma opinião, não um facto.

O risco mais imediato é a fraude oportunista: falsos «reembolsos», falsos sites de «levantamento de emergência» e pedidos da frase-semente. A Binance avisou para não confiar em ligações, mensagens e pedidos de dados não oficiais. Aceda sempre pela aplicação oficial ou escrevendo o endereço, nunca dê a frase-semente ou códigos de verificação, ignore quem prometa recuperar fundos mediante pagamento e ative a autenticação em dois passos, de preferência com passkey (veja «Chaves de acesso (passkeys)»). Este texto é informativo e não é aconselhamento financeiro.

Como proteger servidores e aplicações web?

A cadeia descrita pela Binance existe em qualquer organização com administradores, servidores e pipelines. As medidas com mais efeito:

MFA e controlo de acessos. Exija MFA resistente a phishing (FIDO2, passkeys) em contas de administração, código-fonte, cloud e CI. Aplique o menor privilégio, use acessos temporários a produção e reveja contas de serviço todos os trimestres.
Gestão de segredos. Guarde-os num cofre, não em ficheiros .env partilhados ou no repositório. Use credenciais de curta duração, rode-as com regularidade e ative a deteção de segredos no repositório e no CI.
Isolamento de contentores. Não corra como root nem em modo privilegiado, não monte o socket do Docker, limite capacidades, use sistemas de ficheiros só de leitura e políticas de rede restritivas.
Atualização de dependências. Mantenha sistema, runtime, imagens base e dependências atualizados, fixe versões e analise imagens em cada build.
Monitorização e auditoria. Centralize registos de acesso, de CI e de APIs sensíveis, e alerte para horas ou origens fora do normal. Em operações de grande valor, exija aprovação dupla e limites.
Backups e resposta a incidentes. Tenha cópias testadas e fora do ambiente principal («Cópias de segurança: como saber se o site volta») e um plano escrito para isolar sistemas e rodar segredos. Se já for tarde, siga «O site foi pirateado: o que fazer nas primeiras horas».

Para saber onde está o seu site hoje, a auditoria gratuita da MarcaWeb analisa-o por fora, sem registo, em menos de um minuto.

O que acontece a seguir?

O relatório técnico da Binance dirá como o portátil foi comprometido, que acesso o contentor tinha e se houve exposição de chaves.
A retoma dos levantamentos, e se as saídas são ordenadas, e a Prova de Reservas atualizada que a Binance prometeu.
A recuperação. Congelar não é recuperar. Ari Redbord, da TRM, explicou à CNBC que a recuperação exige um processo legal e que as stablecoins são as mais recuperáveis porque o emissor controla o contrato. Bitcoin e ether não podem ser congelados por um emissor, e a TRM calcula que o atacante ainda controla cerca de 2,4 mil milhões de dólares nesses ativos. A Chainalysis avisa que pode demorar meses ou anos.
A atribuição oficial. Só uma autoridade a poderá confirmar.

Perguntas frequentes

A Binance foi mesmo atacada?

Sim. A Binance confirmou, em comunicado oficial, um incidente de segurança com impacto estimado em cerca de 6,3 mil milhões de dólares. A causa exata continua em investigação.

Perdi dinheiro se tenho fundos na Binance?

A Binance diz que os fundos dos utilizadores estão seguros e que cobrirá todas as perdas. Os levantamentos estão suspensos, com retoma esperada em 48 horas. É uma promessa da empresa, a acompanhar nos canais oficiais.

Como aconteceu o ataque?

A Binance aponta, como hipótese preliminar, o portátil comprometido de um engenheiro DevOps que deu acesso a um contentor de serviço. A TRM Labs defende que foi comprometida a infraestrutura de assinatura. O relatório técnico ainda não saiu.

Quem está por trás do ataque?

A TRM Labs e a Chainalysis atribuem-no, com confiança elevada, ao grupo norte-coreano TraderTraitor. A Binance não o confirmou e não há atribuição oficial de uma autoridade.

O que devo fazer enquanto os levantamentos estão suspensos?

Siga apenas os canais oficiais, ative a autenticação em dois passos e desconfie de quem prometa reembolsos ou peça dados de acesso.

Se a sua empresa precisa de rever acessos, segredos e servidores, escreva para info@marcaweb.pt ou ligue para o +351 920 260 897.

Fontes: Binance, Security Incident Update; Binance no X; CZ no X; TRM Labs; Reuters; Bloomberg; BBC; CNBC; The Block; BleepingComputer; CyberInsider; BlockTempo. Consultadas a 30-10-2026.